Eric Blake <[EMAIL PROTECTED]> wrote: > 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.
These days, people should be using printf in new scripts, and changing echo -e might break legacy scripts. I don't see that much to gain by staying in sync with bash, when e.g., zsh still works the other way. Maybe they're about to change, too? That said, if you can make a good case and want to do the work, I'll consider a patch. _______________________________________________ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
