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). > > 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 -mike
Attachment:
signature.asc
Description: This is a digitally signed message part.
