Date:        Mon, 6 Aug 2018 16:48:29 +0100
    From:        Geoff Clare <[email protected]>
    Message-ID:  <[email protected]>

  | For step 1 this would conflict with 2.5.2 which says that empty fields
  | resulting from expanding @ and * _may_ be discarded.  Your suggestion
  | would require them to be discarded instead of it being optional.

Is that any different from what it currently says...

        If the complete expansion appropriate for a word results in an empty 
field,
        that empty field shall be deleted from the list of fields that form the 
completely
        expanded command, unless the ...

(where the "unless the..." part is what really needs fixing  - and I was just 
looking for the best way to accomplish that)..

Aside from that, are there really any current shells that don't discard empty
fields from $@ or $* (it obviously can't happen if those are quoted) ?  I
suppose the tricky case would be ""$@ (or $*"" or similar).

  | This is already covered by the second sentence of 2.6, "Not all expansions
  | are performed on every word, as explained in the following sections."

Ah, should have read back to the beginning ... but it would still perhaps be 
better to add that little extra clarity, as it really isn't just "the 
following sections" which limit which expansions happen, but anywhere
else in the standard where it says "do X Y and Z... (as desribed in 2.6)"

The "as explained" bit seems to suggest more that it is referring to
field splitting not happening if IFS is null, or filename espansion not
happening when -f is set.   But when expanding a case pattern, we
don't do either of those regardless of IFS or -f.

In the original issue I suggested that perhaps the whole of 2.6 simply
needed rewriting, rather than patching.   Perhaps that is true.

kre

ps: for those watching, I edited note 4070 one more time, this time to add in
the missing " charaters that got dropped from the end of 2 lines in the "loop 
like this..."   The original was one big long line, with ';'s etc, easier to 
cut & paste, I manually reformatted it to look nicer while composing the note,
(including deleting the long list of shells) and botched it, and then only 
recently
noticed.   I also didn't manually construct the list in sorted order by sh 
name, the output went through "sort" 
...


Reply via email to