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: Paul Eggert
Subject: Re: echo "enhancement" leads to confused legacy script tools...
Date: Sun, 19 Mar 2006 12:57:50 -0800
User-agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux)

Linda W <squid-user@tlinx.org> writes:

> I believe bash is broken in regards to using "any" number after
> "\" as an octal value.  The shell specifications require the leading
> zero for an octal constant

I'm afraid this is backwards.  This POSIX+XSI requirement constrains
applications, not implementations.

POSIX requires that if an application wants an octal escape for (say)
the character with octal code 123, it must execute "echo '\0123'".  If
an application executes "echo '\123'" (without the "0"), POSIX says
that the results are implementation-defined.  Hence Bash can interpret
\123 as an octal escape as well, if it so chooses, and still conform
to POSIX+XSI.  A similar analysis applies to \x escapes.

For details, please see <http://www.opengroup.org/susv3xcu/echo.html>.

Autoconf deals with shells that do not conform to XSI, and where the
results are implementation-defined if there's a backslash anywhere in
the string, so to some extent this point is moot for Autoconf (though
it's undeniably a portability problem, one that is documented in the
Autoconf manual under "Limitations of Builtins").




reply via email to

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