bug#9916: [PATCH] echo: fix octal escaping with \1...\7

[Mike Frysinger]

On Monday 31 October 2011 09:12:43 Eric Blake wrote:
> 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?

i plan on digging through the relevant packages and posting patches where 
applicable.  i might be wrong about the libtool side, but do know of at least 
one ax m4 file using it (which is what started this rat hole in the first 
place).  but i consider that a parallel issue :).

> >> 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;

sure, i'm not arguing that logic

> 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.

right, that's what i'm going for
-mike

signature.asc
Description: This is a digitally signed message part.