Re: Problem with echo -e in bash 3.2

[Chet Ramey]

Jochen Roderburg wrote:


> Indeed there it is. Actually, I did not suspect a changelog in a directory 
> named
> CWRU and had not looked there ;-)

Sorry.  It's always been there.

> Let's see, if I understood it correct now: To adhere to the above mentioned
> standards you no longer allow octal digits without leading zero in bash's 
> echo.
> And you expect other applications which have problems with this change to
> correct them at their end?

Actually, I am discouraged that applications were not written to use the
portable `printf'.  Use of `echo' in portable applications has been
deprecated for years.

It's hindsight, of course, but had mc been written (or modified later)
to use printf, it would not need the shell-specific code it apparently
now contains.

> Btw, funny thing in my observed case (Midnight Commander) is that according to
> the comments around the code where it is used this form is explicitly choosen
> for the bash case, because older bash versions could *not* handle the variant
> with leading zeroes  ;-)

The standards evolve, and bash evolves with them.  Previous editions of
POSIX moved from "nothing, but if the first argument is -n, the results
are implementation defined" to "no options, but the interpretation of
backslash characters in the arguments is implementation defined", to "no
options, and you have to interpret this set of backslash escapes for XSI
conformance".  The final (current) set of conditions is what the POSIX
conformance test looks for.

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/