Re: Problem with echo -e in bash 3.2
Zitat von Chet Ramey <[EMAIL PROTECTED]>: > Jochen Roderburg wrote: > > Namely, the formecho -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 ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Problem with echo -e in bash 3.2
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 formecho -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
Re: Problem with echo -e in bash 3.2
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[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/ ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
