[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Problem with echo -e in bash 3.2

From: Eric Blake
Subject: Re: Problem with echo -e in bash 3.2
Date: Sat, 21 Oct 2006 13:39:39 -0600
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20060909 Thunderbird/ Mnenhy/

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             address@hidden
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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]