On this issue, I have also finally realised the answer to another thing
that had perplexed me for ages (not about the standard, well, perhaos
a fix is required, but not all that significant) and certainly not about
what the shells should, or do, produce, which is clear, but about how
people speak about one issue.

That is, when there is discussion of expanding (unquoted) $* or $@
(and sometimes even perhaps "$@" though never "$*") some people
speak (or write) as if $* (or $@) produces a word, which is then field
split, to produce one field for each arg (or each non-null arg).

I never understood how anyone could approach it that way, when
2.5.2 is quite clear ...

        Expands to the positional parameters, starting from one, initially
        producing one field for each positional parameter that is set.

(lines 74866-7 for $* or lines 74845-6 for $@ (same text for each) all
on page 2350).

That is, multiple fields are produced (each of which can then be subject to
field splitting) not one field that is split subsequently to make many.

But now I have realised that the words in 2.6 contradict this ...

(lines 74993-7 page 2353)

        Tilde expansions, parameter expansions, command substitutions,
        arithmetic expansions, and quote removals that occur within a single
        word expand to a single field. It is only field splitting or pathname
        expansion that can create multiple fields from a single word. The single
        exception to this rule is the expansion of the special parameter '@'
        within double-quotes, as described in Section 2.5.2.

I think it clear (and obvious) that 2.5.2 is both correct, and the best way to
interpret this, and that that paragraph from 2.6 is wrong (is there anything
in 2.6 that is not wrong?).

That is, $* and $@ are just shorthand ways to write

        $1 $2 $3 $4 .....

for as many args as are set (including 0), and when quoted, "$@" is just

        "$1" "$2" "$3" ...

again for as many args as are set (including 0), and the only slightly
odd case is quoted "$*" which is

        "$1 $2 $3 $4..."

(again for as many args as are set, including 0) but here, we actually need
a character to appear where the spaces are shown, whereas in the previous
cases we do not - the spaces there are simply e-mail notation to separate the
fields, tokenisation has already happened, and redundant white space has
been removed.   In this last case (and that one only) the spaces represent
whatever is the first char of the expansion of $IFS if it is set (including 
nothing
wnen IFS has an empty value), and as usual, an actual space if IFS is unset.

That is, when IFS=: we do not expand $* to be $1:$2:$3:... and then later field
split it, IFS is only relevant (at this stage) if $* is quoted.   This is 
important as otherwise the wrong result would be generated when IFS is 
null (and 2.5.2 is very clear what the right result is here).

For this, I'd suggest rewriting the offending paragraph of 2.6 to be:

        Tilde expansions, parameter expansions, command substitutions,
        arithmetic expansions, and quote removals that occur within a single
        word expand to a single field. It is only field splitting or pathname
        expansion that can create multiple fields from a single word. The single
        exception to this rule is the expansion of the special parameters $* 
        and $@ as described in Section 2.5.2.

That is, forget about "within double quotes" (2.5.2 already describes the rules
for that) and include $* (that "$*" only ever produces one field need not be
called out here, nothing in this requires multiple fields to be produced, field
splitting very often only produces 1 field (every time nothing from IFS appears
in the expansion...) as does pathname expansion (every time there are no
glob magic chars in the field) as do $@ and $* (and "$@" and "$*") when
$#==1 (and $1 != '')

I do note that the (curently) proposed resolution of issue 1193 also contains
a similar change, in the context of also allowing brace expansion (if it is
supported) to also add more fields, but consideration of that issue won't
occur for a long time yet, and would not be affected by including this change
now, so I'd suggest making it as part of the resolution of 1123, and then 1193
(if it is not abandoned or rejected) can further modify it.

kre

Reply via email to