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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.