Robert Elz <k...@munnari.oz.au> wrote, on 28 Feb 2019:
>
> | However, given that the most widely used modern shells produce a null
> | field, I believe we should make this unspecified rather than forcing
> | them to change.
>
> Then the question becomes just how we do that.
[snip]
> The problem is a tendency to go off on tangents filling in details, to
> try and get everything just right - but in the middle of what should be
> a fairly simple sentence (or sentences) - leading to something that is
> much too long, and where the original premise and final conclusion are
> separated by reams of text which are only barely related to the issue
> at hand.
>
> This can generally be solved by a rewrite which keeps all of the
> content (or the important parts anyway) but rearranges the order so
> the logical flow makes sense and anyone can follow.
The reason the '@' description is structured the way it is is because
when I drafted what became the current text, I started from the '*'
description and added in the extra quirks that '@' has. If '@' is
rearranged too much it will destroy the neat correspondence between
the two descriptions.
> Here there are 3 situations where $@ can be used, two of them have (or
> can have) specified results, the third is "anything else" and does not.
> What we need to do is get that set out at the beginning. What the specified
> result is for the two cases (contexts) where we have such a thing, and the
> extra requirements on the second one can be specified later.
>
> This would be helped if we weren't slightly mixed up about what it means
> to be a "context where field splitting will be performed" - we already got
> rid of the assumption that when IFS='' we no longer have such a context,
> we also need to get rid of the assumption that when a word is quoted we
> are not in a context where field splitting will be performed.
>
> Just as in the IFS='' case, quoting prevents any field splitting actually
> happening, it does not avoid us being in a context where field splitting
> could happen. The contexts where field splitting happens are exactly
> those where the standard says it happens.
That may be how it works in your mind, but it's not what the standard
says. The description of field splitting explicitly says it is only
performed for expansions that are not in double quotes ("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").
In any case, I think it is worth keeping the clarification in the
descriptions of '@' and '*' that field splitting is applied to each of
the positional-parameter-derived initial fields individually.
[snip]
> This is where we should get to the part about:
>
> Expands to the positional parameters, starting from one, initially
> producing one field for each positional parameter that is set.
>
> except that at that point, I'd add this:
>
> If there are no positional parameters, the expansion of '@' shall
> generate zero fields, even when '@' is within double-quotes;
>
> which currently occurs later, except I would write it as
>
> If there are no positional parameters, the expansion of '@' shall
> produce nothing.
>
> (We still need to deal with "$@" ... that's coming later).
>
> That's what we want, double quotes or no double quotes, and embedded
> within a word or not. The "embedded within" shouldn't be connected to
> the case where there are no positional params, but to the case where
> there are, something like:
>
> If there are positional parameters, then any text preceding
> the $@ in the word being expanded shall be placed before, and
> joined to, the expansion of the first positional parameter, and
> any text following the $@ in the word being expanded shall be placed
> after, and joined to, the expansion of the final positional parameter.
> One field shall be generated for each positional parameter, that is,
> $# fields. If the '@' being expanded occurred within double quotes,
> then the expansion of each positional parameter is placed within
> double quotes in the fields generated. These double quotes are
> treated as copies of the original pair, and are later deleted by
> quote removal.
>
> Where there are no positional parameters, the $@ shall be
> deleted from the word, and whatever remains shall be the
> result. In the special case where the word expanded was
> exactly "$@", the double quotes are also deleted, leaving nothing
> - the expansion of the word shall produce no fields.
>
> In other cases where the $@ occurred within double quotes,
> and other expansions within the same pair of double quotes
> as contain the $@ also produced no output text, and no other
> text is present, it is unspecified whether the empty double
> quoted string remains as a null string, or is deleted, producing
> nothing.
I don't like this rearrangement because it is a completely different
structure from the one for '*'.
It also has numerous problems, which I started to write up but decided
weren't worth the effort given it is already wrong in a big way because
of your misconception about field splitting.
I think the way forward is for you to look at the description of '*'
and decide if you think it needs to change. Once we have text for '*'
that we are both happy with, we can think about how to describe '@' in
a way that maintains the correspondence between the two descriptions.
> ps: the results from the field splitting/FOO/printf/$* test should be:
>
> [jinx]{2}$ IFS=: ; unset FOO ; set -- a b c
> [jinx]{2}$ printf %s\\n $*
> a
> b
> c
> [jinx]{2}$ printf %s\\n "$*"
> a:b:c
> [jinx]{2}$ printf %s\\n ${FOO:=$*}
> a
> b
> c
> [jinx]{2}$ printf %s\\n ${FOO}
> a
> b
> c
> [jinx]{2}$ printf %s\\n "${FOO}"
> a:b:c
As far as I can see this agrees with the examples in XRAT C.2.5.2.
--
Geoff Clare <g.cl...@opengroup.org>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
