From: Mike Frysinger <vapier@gentoo.org>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: dash@vger.kernel.org
Subject: Re: [PATCH] echo: fix octal escaping with \1...\7
Date: Mon, 31 Oct 2011 00:23:44 -0400 [thread overview]
Message-ID: <201110310023.45138.vapier@gentoo.org> (raw)
In-Reply-To: <20111031034146.GA19477@gondor.apana.org.au>
[-- Attachment #1: Type: Text/Plain, Size: 1975 bytes --]
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 #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2011-10-31 4:23 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-25 21:58 [PATCH] echo: fix octal escaping with \1...\7 Mike Frysinger
2011-10-26 7:59 ` Stephane CHAZELAS
2011-10-31 3:41 ` Herbert Xu
2011-10-31 4:23 ` Mike Frysinger [this message]
2011-10-31 13:12 ` Eric Blake
2011-10-31 13:35 ` Paul Gilmartin
2011-10-31 14:03 ` Eric Blake
2011-10-31 14:56 ` Stephane CHAZELAS
2011-10-31 18:07 ` Harald van Dijk
2011-10-31 18:39 ` Mike Frysinger
2011-10-31 18:48 ` Harald van Dijk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201110310023.45138.vapier@gentoo.org \
--to=vapier@gentoo.org \
--cc=dash@vger.kernel.org \
--cc=herbert@gondor.apana.org.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox