All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jilles Tjoelker <jilles@stack.nl>
To: dash@vger.kernel.org
Subject: Re: unexpected parameter expansion
Date: Thu, 20 May 2010 00:01:10 +0200	[thread overview]
Message-ID: <20100519220109.GA81407@stack.nl> (raw)
In-Reply-To: <20100519191928.28202.qmail@10218569f54974.315fe32.mid.smarden.org>

On Wed, May 19, 2010 at 07:19:28PM +0000, Gerrit Pape wrote:
> Hi, I get unexpected output with dash doing parameter expansions with }
> within quotes involved, e.g.

> $ dash -c 'foo=; echo ${foo:-"{a}bar"}'
> {abar}
> $ 

> I expected:
> {a}bar

Just for clarification, the open brace is inconsequential here. It does
not pair with a close brace (only ${ does). Certain versions of bash and
ksh implemented it that way, but it has since been corrected.

> http://www.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_02

When reading this, make sure to consider the recent discussion on the
Austin Group.

Except for single-quotes inside double-quoted #% substitutions, there
appears to be consensus about the change in note #399 in
http://austingroupbugs.net/view.php?id=221

This post of mine is particularly interesting for dash:
http://permalink.gmane.org/gmane.comp.standards.posix.austin.general/1924

> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=581428

That one does
  foo="${foo:-"{a}bar"}"
(note the extra double-quotes) which can only result in {abar}, an error
or an incomplete command with dash's approach. The inner quotes have no
effect whatsoever on dash's parser.c state and only generate
CTLQUOTEMARK bytes for expand.c. This is not so bad as these nested
double-quotes with +-=? substitutions result in unspecified behaviour,
and shells differ in what it means.

Dash is not the only shell that doesn't do what the parole people
expect. FreeBSD sh (pretty much all versions, including with my reworked
substitutions in 9-CURRENT, although I could change it fairly easily)
and the System V sh (from Heirloom Toolchest) also assign {abar} (but
accept it as a complete command).

I recommend splitting up the command. Although
  foo=${foo:-{a\}bar}
will work, some shells keep the backslash in
  foo="${foo:-{a\}bar}"
and some people are tempted to add double-quotes everywhere, even where
they are not needed and silent breakage would result.

> Sorry, I don't have a patch to suggest.

I think this part needs a testsuite before any further changes :)

You could start from the posh or FreeBSD sh testsuites and what's in the
commit messages. Or if you have little programmer time but lots of CPU
time, rebuild all packages in the debian archive :)

-- 
Jilles Tjoelker

  reply	other threads:[~2010-05-19 22:01 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-19 19:19 unexpected parameter expansion Gerrit Pape
2010-05-19 22:01 ` Jilles Tjoelker [this message]
2010-05-27 11:41   ` Herbert Xu

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=20100519220109.GA81407@stack.nl \
    --to=jilles@stack.nl \
    --cc=dash@vger.kernel.org \
    /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.