Re: Problem with echo -e in bash 3.2

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

[Adding bug-coreutils to CC]

According to Chet Ramey on 10/21/2006 11:52 AM:
> Jochen Roderburg wrote:
>>
>> I finally tracked this down to a changed behaviour of the builtin echo 
>> command.
>>
>> Namely, the form    echo -e '\nnn'   with a 3-digit octal number does not 
>> work
>> any longer, only the variant  echo -e '\0nnn' with a leading zero.
>>
>> Don't know it this is a bug or feature  ;-)
> 
> It's intentional.  The xpg_echo and `echo -e' code should be identical,
> and the xpg_echo code is required by POSIX/XSI to interpret octal constants
> only with the leading `0'.  There are lots of ways to indicate that
> backslash escapes should be interpreted -- maybe too many -- but when
> they are, they should behave consistently.
> 
> 
>> The 'program' echo from current GNU coreutils interprets the \nnn form
>> (correctly?).
> 
> I don't think the coreutils echo wants echo -e to be POSIX-conformant
> the way bash is (it's an implementation choice -- POSIX doesn't specify
> echo -e).

It looks like it is time for coreutils to revisit how /bin/echo should
behave, with or without the presence of POSIXLY_CORRECT.  It would be good
for coreutils 6.4 to match bash 3.2 in what escape sequences it understands.

- --
Life is short - so eat dessert first!

Eric Blake             ebb9@byu.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFOnd784KuGfSFAYARAoLdAKC4J8DeOj8uM3lZdIYVs49eKj6IowCeJCha
zTvb+RYcQNONY04YvE9Fhf8=
=NhIR
-----END PGP SIGNATURE-----