bug-bash
[Top][All Lists]
Advanced

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

Re: Problem with echo -e in bash 3.2


From: Jochen Roderburg
Subject: Re: Problem with echo -e in bash 3.2
Date: Sun, 22 Oct 2006 11:18:18 +0200
User-agent: Internet Messaging Program (IMP) 3.2.6

Zitat von Chet Ramey <chet.ramey@case.edu>:

> Jochen Roderburg wrote:

> > 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.
>

Thanks for clarification.

> 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
>

Indeed there it is. Actually, I did not suspect a changelog in a directory named
CWRU and had not looked 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?

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  ;-)

Best Regards,
Jochen Roderburg





reply via email to

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