RE: Fix testsuite errors due to shell quoted parameter expansion issue.

[John Lumby <johnlumby@xxxxxxxxxxx>]

Re the statement

    since "$e" is quoted, it must not be elided

I don't think that is correct.   In fact "$e" *must* be elided  -  because you juxtaposed it with the next token.    eliding and quoting are orthogonal.

What you appear to be be expecting is that the effect of quoting one token should somehow have some effect on interpretation of a special character (blank) in a subsequent unquoted token.   I don't think that is expected behaviour.      The quoting of $e has the effect of quoting any special characters inside *it*, of which there are none.     your blank is unquoted.    Then word-spilling proceeds.

What I find interesting is this

bash -c 'declare -i length; f=" val" e=;concat="$e"$f; length=${#concat}; echo "length= $length"'
4

John Lumby

> Date: Tue, 3 Aug 2010 23:21:02 +0200
> From: mikachu@xxxxxxxxx
> To: eblake@xxxxxxxxxx
> CC: zsh-workers@xxxxxxx; Autoconf@xxxxxxx; libtool-patches@xxxxxxx
> Subject: Re: Fix testsuite errors due to shell quoted parameter expansion 	issue.
> 
> On 3 August 2010 22:55, Eric Blake <eblake@xxxxxxxxxx> wrote:
> > [adding autoconf to document some shell bugs]
> >
> > On 08/03/2010 02:32 PM, Ralf Wildenhues wrote:
> >> Interesting shell unportability:
> >>
> >> $ bash -c 'f=" val" e=; echo "$e"$f'
> >> val
> >> $ ksh -c 'f=" val" e=; echo "$e"$f'
> >>  val
> >>
> >> ksh93, dash, zsh all do it like ksh.  Is that a bug in bash?
> >
> > Yes; adding bug-bash accordingly.  According to POSIX:
> >
> > http://www.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_05
> >
> > "After parameter expansion ( Parameter Expansion ), command substitution
> > ( Command Substitution ), and arithmetic expansion ( Arithmetic
> > Expansion  ), the shell shall scan the results of expansions and
> > substitutions that did not occur in double-quotes for field splitting
> > and multiple fields can result."
> >
> > Since $f is not quoted, its expansion must undergo field splitting.  But
> > since "$e" is quoted, it must not be elided even though empty.  The
> > result must be _two_ fields, as if you had done "echo '' 'val'".
> >
> > But it is _also_ a bug in zsh; adding zsh-workers accordingly.
> >
> > $ zsh -cvx 'f=" val" e=; echo "$e"$f'
> > +zsh:1> f=' val' e=''
> > +zsh:1> echo ' val'
> >  val
> >
> > Oops - zsh only passed one argument to echo, with a leading space,
> > instead of passing an empty argument and letting echo supply the space.
> >  ksh93, pdksh, and dash get it right (although dash doesn't use quotes
> > in -vx output, hence my use of n() to force things to tell; n() is
> > another way to expose the bash and zsh bugs).
> 
> zsh doesn't do word splitting by default, you can enable it with the = modifier:
> % zsh -fcvx 'f=" val" e=; echo "$e"$=f'
> +zsh:1> f=' val' e=''
> +zsh:1> echo '' val
>  val
> 
> does what you want
> 
> Alternatively you can make zsh try to be closer to sh by setting
> argv[0] to sh when executing it, or running 'emulate sh' as the first
> command (and possibly other ways I don't know about):
> % zsh -fcvx 'emulate sh;f=" val" e=; echo "$e"$f'
> +zsh:1> emulate sh
> +zsh:1> f=' val' e=''
> +zsh:1> echo '' val
>  val
> 
> There's also --shwordsplit for this specific case:
> % zsh --shwordsplit -fcvx 'f=" val" e=; echo "$e"$f'
> +zsh:1> f=' val' e=''
> +zsh:1> echo '' val
>  val
> 
> (the -f above only avoids loading my .zshenv which would spam my output)
> 
> -- 
> Mikael Magnusson
> 
> _______________________________________________
> Autoconf mailing list
> Autoconf@xxxxxxx
> http://lists.gnu.org/mailman/listinfo/autoconf