[austin-group] Re: clarification on $*/$@

[austin-group] Re: clarification on $*/$@

[Bart Schaefer]

Extensive quoting for context.

On Wed, 22 Oct 2014, Chet Ramey wrote:

> On 10/20/14, 5:54 PM, Stephane Chazelas wrote:
>
> > In the Bourne shell, $@ and $* were the same and were variables
> > whose content was the concatenation of the positional
> > parameters.
> >
> > The only thing special was "$@" ($@ quoted) in list contexts
> > (like in arguments to simple commands or in for i in "$@").
> >
> > So in:
> >
> > set a b@c
> > IFS=:,@
> > printf '<%s>\n' $*
> >
> > $* expands to "a:b@c" and undergoes word splitting.
>
> Not really, if you meant how the historical Bourne shell behaved.  The
> Bourne shell expands it to "a b@c" and performs word  splitting, resulting
> in
>
> <a b><c>

Hmm, zsh in sh-emulation behaves as Stephane describes:

$ set a b@c
$ IFS=:,@
$ printf '<%s>\n' $*
<a>
<b>
<c>
$ printf '<%s>\n' "$*"
<a:b@c>

> > set a b@c
> > IFS=
> > printf '<%s>\n' $@
> >
> > $@ expands to one argument only: "a b@c"
>
> Yes, this is what the Bourne shell did/does.

Hmm again, zsh:

$ IFS=
$ printf '<%s>\n' $@
<a>
<b@c>
$ unset IFS
$ printf '<%s>\n' $@
<a>
<b@c>

> > ksh introduced the joining on the joining on the first character
> > of IFS instead of a space character and arrays. $* and $@ still
> > seem to contain the concatenation of the positional parameters
> > with the first character of IFS except that in list contexts,
> > unquoted $* and $@ are also split on the positional parameters
> >
> > set a b
> > IFS=
> > a=$@
> >
> > assigns "ab" to $a, but
>
> That's not true: sh, ksh, bash, and so on assign "a b".  If you meant to
> use $*, you're correct.  Only $* is specified to use the first character
> of $IFS.

Zsh joins all arrays on the first character of IFS in this context.  Note
that assignment is one of the few contexts in which an array is joined
into a scalar.  [[ ]] is another.

$ set a b
$ IFS=
$ a=$@
$ print $a
ab
$ b=(b a)
$ a=${b[@]}
$ print $a
ba
$ [[ $@ = ab ]] && echo joined on IFS
joined on IFS

> If this is central to your argument, you might want to reframe it.

Is this an incompatibility that we should consider fixing?

> > set a b
> > IFS=
> > printf '<%s>\n' $@
> >
> > expands to 2 arguments "a" and "b".
>
> Yes, ksh/mksh and bash do this.  The historical Bourne shell expands it to
> one argument: "a b".

Zsh is as ksh here:

$ set a b
$ IFS=
$ printf '<%s>\n' $@
<a>
<b>

> > So:
> >
> > IFS=
> > set a b
> > printf '<%s>\n' $@
> >
> > would expand to one "ab" argument as you'd expect (as a logical
> > continuation of the Bourne shell and to be consistent with
> > a=$@ and from a shell that doesn't support arrays).
>
> One wouldn't.  Only dash does this.

Command-line arguments are not a context in which arrays are joined in
zsh, either.  Dash surprises me.

> > bash behaviour is rather odd. In some places $@ and $* seem to
> > be the concatenation of arguments with the first character of
> > IFS, sometimes with space.
> >
> > $ bash -c 'set a b; IFS=; a="$@"; echo "$a"'
> > a b
> > $ bash -c 'set a b; IFS=; a=$*; echo "$a"'
> > ab
> > $ bash -c 'set a b; IFS=; a="a bc"; echo ${a#$*}'
> > c
>
> Yes, the third case is a problem.  The other two cases are consistent with
> ksh93, mksh, and other Posix shells except dash.

Zsh gives:

% ARGV0=sh zsh -fc 'set a b; IFS=; a="$@"; echo "$a"'
ab
% ARGV0=sh zsh -fc 'set a b; IFS=; a=$*; echo "$a"'
ab
% ARGV0=sh zsh -fc 'set a b; IFS=; a="a bc"; echo ${a#$*}'
a bc

Re: [austin-group] Re: clarification on $*/$@

[Stephane Chazelas]

Hi Bart,

the discussion is at
http://thread.gmane.org/gmane.comp.standards.posix.austin.general/9972
where there have been more said about zsh

I'm not sure it's very productive to have a separate discussion
here, but the austin group list is a subscribers only list, so I
suppose CCing zsh-workers wouldn't work well.

In any case, my understanding is that zsh (in sh emulation) is
POSIX compliant by all interpretations of it (as it's quite
unclear) and is the most consistent implementation, so I don't
think zsh should change anything in that regard.

Cheers,
Stephane