Jochen Roderburg wrote: > I found a problem under Linux with the 'Midnight Commander' (v 4.5.55) and the > new bash 3.2. > Chdirs in subshells do not work with the effects: > 1) On every directory change in mc you get a warning 'Could not change > directory > ...' > mostly corrupting the mc program window. > 2) It is not possible to execute programs on files in subdirectories. > > 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. echo is crazy enough without more differing interpretations of backslash escapes. Any application wanting to use a standard utility for output should use printf. > I do not find this mentioned in any changelog, only hidden in the builtin > help: It was not in my summary of changes between 3.1 and 3.2 (an oversight), but it certainly appears in the changelog (CWRU/changelog): lib/sh/strtrans.c - add code to echo -e and echo with xpg_echo enabled to require a leading 0 to specify octal constants > 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). Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Live Strong. No day but today. Chet Ramey, ITS, CWRU [EMAIL PROTECTED] http://cnswww.cns.cwru.edu/~chet/ _______________________________________________ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash