Re: Problem with echo -e in bash 3.2

[Chet Ramey]

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    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/