Date: Fri, 10 Aug 2018 13:30:28 +0100
From: Geoff Clare <g...@opengroup.org>
Message-ID: <20180810123028.GA23963@lt2.masqnet>
| Actually, I think the existing description of Field Splitting handles
| it correctly.
I disagree, but not for the reason that I think you believe...
| It may be easier to see if you consider:
Yes, I know how that works, and I know how 2.6.7 results in
a "nothing" from the modified example that you gave.
| (The $* isn't an issue because parameter expansion produces "one field
| for each positional parameter that is set". There are no positional
| parameters set, so there are no fields.)
And this one is (as things are currently worded) the same issue
(that I have). Again, I agree that 2.5.2 is saying the correct thing,
just not 2.6
| So I think just deleting that paragraph, as bugnote 4082 currently has
| it, is the right thing to do.
I don't. Though there are other changes that could be made which
would allow that tto be done - but we'd also need the additional changes.
Here I will intersperse a short reply to your subsequest message ...
g...@opengroup.org said:
| The best way forward might be for someone familiar with the source of ksh93
| or bash (or another popular shell) to look at how the shell actually decides
| whether the complete expansion produces nothing or a single empty field.
I don'r know what bash or ksh93 do, though I do know the NetBSD and FreeBSD
sh approach (though these days they are dine differently) - and while neither
of those might qualify as a "popular" shell, I'd expect that dash is probably
quite similar to one of them.
In the *BSD shells, the parser has produced a list of words (several actually,
one for command words/args, one for var assigns, and one for redirects),
and the shell just goes through each list (at the appropriate point) producing
a replacement list (we can change the nomenclature from words to fields at
this point, but that doesn't make any substantive difference to the
implementation).
For each new field that is produced from any of the expansions, a new entry is
made on the output list (appended to it). If an expansion produces no fields,
then nothing new appears on the output list. As each word is processed from
the input list (in order) it is removed. Eventually the input list is empty,
and the output list is what is left. (nb: this is a conceptual description,
the "list" is actually an array of pointers, and nothing is actually removed
until it is all done, the array index just advances.)
The primary difference between the NetBSD and FreeBSD shells, as I
understand the latter anyway, is that the FreeBSD shell applies the 4
steps to each word as it is processed, whereas the NetBSD shell
tends to do step 1 for all words, then step 2, ... This difference seems
to be more related to how easy it is (believed to be) to get the code
correct, and perhaps to some degree, shell effieiency, rather than to
any expected difference in results.
OK, back from that to the issue at hand...
The problem I see with simply deleting the paragraph in question
is that nowhere (else) is there (in the standard) any allowance for an
input word not producing an output field. In the cases explicitly called
out there is the possibility for an input field to produce multiple output
fields, but never zero.
Now I guess that it is possible to read "multiple" as any multiple of 1,
which incudes 0*1 1*2 2*1 ... and so no fields could be interpreted as
one of the possible multiple fields results - but I don't think most people
would read it that way, and as pathname expansion is one of the
places where producing multiple fields is permitted,, and we really
do not want anyone assuming that pathname expansion is permitted
to produce nothing (or people would expect that might be the logical
result from a pattern that matches nothing.)
But given the way that the text is written (lines 74994-5):
It is only field splitting or pathname expansion that can create
multiple
fields from a single word. The single exception...
it is really had to read it as "0 is permitted", rather it looks (at least to
me) as if it means one in, one (and in the two cases, plus the exception, "or
more") out.
The proposed text in 1193, while different, leads to the same colclusion
(to me anyway) ...
The shell shall create multiple fields from a single word only as a
result of field splitting, pathname expansion, or the following cases
again, to me, that means one in, one (or more when permitted) out.
Assuming my reading is (at least) plausible, from where, apart from in the
relevant paragraph, does the shell obtain its authority to delete words
(not include them in the final list of fields).
Again here, at least for this issue, I do not believe there is any dispute
at all about what is supposed to happen - the question is just how the
words are written so that it is obvious what happens to people who do
not "already know" how the shell works.
kre
