[adding bug-libtool]
On 10/30/2011 10:23 PM, Mike Frysinger wrote:
On Sunday 30 October 2011 23:41:58 Herbert Xu wrote:
Mike Frysinger wrote:
POSIX states that octal escape sequences should take the form \0num
when using echo. dash however additionally treats \num as an octal
sequence. This breaks some packages (like libtool) who attempt to
use strings with these escape sequences via variables to execute sed
(since sed ends up getting passed a byte instead of a literal \1).
That's a bug in libtool for using "echo '\1'" and expecting sane
behavior. Can you provide more details on this libtool bug, so we can
get it fixed in libtool? Or perhaps it has already been fixed in modern
libtool, and you are just encountering it in an older version?
OK this is a bit of problem. From our conversation I had the
impression that you were referring to the lack of support of
escape codes, rather than unwanted support.
If it was the former I could easily add it if POSIX said so,
however, as this is an existing feature there may well be scripts
out there that depend on it. So removing it is not an option
unless it is explicitly forbidden by POSIX.
i'm not seeing how this jives with dash's goal. if it intends to be a
fast/small POSIX compliant shell while punting (almost) all the rest, then why
carry additional functionality that POSIX doesn't even mention in passing ?
this isn't "documented but optional extended functionality", but rather the
realm of "anything goes". otherwise we approach the same realm that dash was
created to avoid -- carrying lots of cruft that slow things down because
scripts use it rather than POSIX mandating it.
as a comparison, bash/ksh/tcsh/zsh/busybox[ash] all behave the way my patch
updates dash to operate ... i would test more shells, but these tend to be the
standards that everyone compares against. i can't see people writing scripts
that only work under dash either.
In any case, scripts that rely on escape codes like this are
simply broken and should either be fixed to use printf or just
run with #!/bin/bash.
they're relying on these escape codes not being interpreted as escape codes
(which every other shell appears to do), not the other way around
Scripts that rely on a certain interpretation of "echo '\1'" are broken
regardless of how dash behaves; but that said, since POSIX doesn't
require dash's current behavior, and since the proposed patch makes dash
both smaller and more like other shells in treating it as an extension
that means a literal 1 rather than an octal escape, I would be in favor
of making the change in dash.
--
Eric Blake eblake@xxxxxxxxxx +1-801-349-2682
Libvirt virtualization library http://libvirt.org
--
To unsubscribe from this list: send the line "unsubscribe dash" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
