Robert Elz <k...@munnari.oz.au> wrote, on 27 Feb 2019:
>
> The question is what the expression
> "${X+$@}"
> is expected to produce when $# = 0 (ie: there are no positional params).
> This is when this is evaluated as a word which is an arg to a command,
> so we are in a place where field splitting would apply, if the word
> were not quoted.
>
> When X is not set, it is clear, the result is "" (a null string).
>
> When X is set, my first impression (when I first saw this example on
> another list) is that this is one of the unspecified cases for $@ expansions,
> but upon a close reading of the current (ie: after issue 888) text I cannot
> see why that would be the case.
>
> If it is not unspecified, then I think the result has to be nothing.
> That is, no fields are produced (when X is set and $# = 0).
>
> That is troublesome, as almost no shells produce that. Until today
> (or perhaps tomorrow, or the day after) only (of shells I can test)
> the NetBSD sh, bosh, yash, and an old version of pdksh produce nothing
> for this (ksh88 is not in my test list). The "until today" for the NetBSD
> shell, is because this happens in the NetBSD sh as a result of code which
> produces bugs in other (much clearer) cases, and so is very likely to be
> altered (fairly soon.)
>
> All other shells I tested (bash, dash, the FreeBSD sh, ksh93, mksh, zsh)
> produce a single null field (ie: the same result regardless of whether
> X is set or unset). That's what the NetBSD sh will do (most likely) after
> I install the bug fixes for other bugs (to fix the other bugs, and not
> change this, would, at least from current inspection, require some truly
> ugly hackery).
I agree with your conclusion that the standard currently requires the
result to be no fields, and this is what ksh88 does (tested with
/usr/xpg4/bin/sh on Solaris 11 and /usr/bin/sh on HP-UX 11).
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.
I have made further comments below, but they are all to do with the
nitty-gritty of how to interpret the current text, so can safely be
skipped by those who aren't interested in that.
>
> My reasoning for my conclusions on the current state of the text are ...
>
> (Quoting from XCU 2.5.2, with the extracted parts from lines 74845 to 74865)
>
> @ Expands to the positional parameters, starting from one,
> initially producing one field for each positional parameter
> that is set.
>
> There are no positional parameters set, hence we initially have no fields
>
> When the expansion occurs in a context where field splitting
> will be performed,
>
> We are inside a double quoted string, hence this does not apply, and
> we can ignore what it says happens (which would be to produce nothing
> if somehow it could be interpreted to apply, so the same result as we
> will eventually reach anyway...)
>
> When the expansion occurs within double-quotes,
>
> It does.
>
> the behavior is unspecified unless one of the following is true:
>
> ยท Field splitting as described in Section 2.6.5 would be
> performed if the expansion were not within double-quotes
>
> It would be here, so "one of the following" is true (and we don't need
> to look at the alternative, which would not apply here) and do this
> is not an unspecified expansion for this reason (there are more possibilities
> coming.)
>
> If one of these conditions is true,
>
> It is.
>
> the initial fields shall be retained as separate fields,
>
> which will be 0 fields (from above)
>
> except that if the parameter being expanded was embedded within
> a word,
>
> Well, that's a question, we need to know what "embedded within a word"
> means here (precisely) (for why, see below).
I don't think we do need to know that (for why, see below).
[snip]
> Why this is important is what comes next:
>
> In all other contexts the results of the expansion are
> unspecified.
>
> This is our next possibility for making the expansion cause an
> unspecified result.
>
> It is somewhat problematic, as different people read the "all other
> contexts" as applying to a different earlier test. That is, we need
> to discover apart from which contexts the "all other" is meant to apply.
The use of "other contexts" here links back to "context" in the second
sentence ("When the expansion occurs in a context where field splitting
will be performed ...") and this is indeed what you (eventually) concluded
is the correct interpretation (making what "embedded within a word" means
irrelevant) ...
[snip]
> The next previous conditional is "When the expansion occurs within
> double quotes", which follows "When the expansion occurs in a context
> where field splitting will be performed," which looks likely, as
> those are two contexts, so it is entirely reasonable to have "all other
> contexts" as the third possibility. The paragraph formatting is ugly
> if that is the case - it is really hard to associate the conditions
> correctly - but this one is the one I think must be correct.
The entire '@' description is intended to be a single paragraph, but I can
see that the presence of the bullet list can make it seem like "If one
of these conditions ..." starts a new paragraph. This is a drawback of
using a paragraph style that doesn't indent the first line.
I agree with the rest of your analysis of how the text applies in this
case.
--
Geoff Clare <g.cl...@opengroup.org>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
