bug-bash
[Top][All Lists]
Advanced

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

Re: echo "enhancement" leads to confused legacy script tools...


From: Chet Ramey
Subject: Re: echo "enhancement" leads to confused legacy script tools...
Date: Fri, 31 Mar 2006 13:28:37 -0500

>       I'm willing to try the CVS versions of autoconf later on, but
> can't promise when I'll get to it.  I can confirm, though, that
> the bug I'm running into only happened when I rebuilt bash and
> specified the --enable_xpg_default option.

You would have seen the same results had you specified the `-e' option
to echo.  The behavior is consistent, and will remain so.

> It might be "late" to change the requirement to "\0" is required as
> the leading for all numeric constants, but as has been stated here, no
> application should be relying on "\1" being interpreted as "^A" if it
> is desired that it be portable.

I don't believe it's "too late", considering that you had to compile bash
with a non-default set of configuration options to encounter the problem.
However, I like consistency, and I believe that it's important to have
-e and the xpg_echo option produce identical output.

I don't favor being deliberately incompatible, though, unless there's a
compelling reason.  This doesn't seem to measure up to that standard.

The remaining consideration is whether or not there's a significant
body of scripts out there that rely on the current behavior.  If there
isn't, I would strongly consider the change to require a leading `0'
in octal constants.  I don't think that \x introducing hex constants
is as big a problem (it may not be a problem at all). 

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
( ``Discere est Dolere'' -- chet )
                                       Live Strong.  No day but today.
Chet Ramey, ITS, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/




reply via email to

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