Date:        Fri, 10 Aug 2018 09:02:47 +0100
    From:        Geoff Clare <g...@opengroup.org>
    Message-ID:  <20180810080247.GA20183@lt2.masqnet>

  | The paragraph should be deleted.

Unfortunately, that is not good enough.    There needs to be text somewhere
allowing empty fields to be removed (aside from when $@ and $* are expanded
from 2.5.2 which is something of a special case, as those are producing new
fields, and the question is how many new ones ought to be created ...
When $# == 0   I don't think there is any question but that $@ and $* 
(unqouted) must produce nothing at all (the field is deleted).

That is, with

        set --; A=;  for x in a $A b $* c; do printf "[%s]\n" "$x"; done

needs to produce

        [a]
        [b]
        [c]

and not (or some other variation of)

        [a]
        []
        [b]
        []
        [c]

which would be the result from:
        set --; A=;  for x in a "$A" b "$*" c; do printf "[%s]\n" "$x"; done

That cannot happen in 2.6.2 (and would also need to be in 2.6.3) as those 
describe a single parameter expansion, and we want the field removed
in cases like

        A=; B=; for x in a $A$B b; do printf "[%s]\n" "$x"; done

as well.     There needs to be wording somwhere to handle this.

One possibility might be read the original text more pedantically,
(and then add wording to make it clear) so that:

        If the complete expansion appropriate for a word
        results in an empty field,

is read as "results in a single empty field" - that is, if two fields are 
produced, one of which is empty, we do not have "an" empty field
from the "complete expansion" of a word, but multiple fields, some
of which might be empty.

I think that deals with the apparent 2.5.2 conflict, and the field splitting
making an empty field conflict that you just descrbed.

Note that we cannot just eliminate step 3 from the "producing an empty
field" as while empty fields from field splitting are generally retained
(given that 2.6.5 allows parts of the word to simply be ignored, rather
than to produce a field which is then deleted) we do need to deal with

        A="   ";  for x in a $A a; do printf "[%s]\n" "$x"; done

which also results in the $A word being deleted, and here,
the word expansion does not result in nothing, it results in a
sequence of spaces (or a tab, or a combination, even including
newlines) and field splitting deletes that (and it doesn't matter
whether IFS has its default value (or is unset) or whether it
has some other value, as long as $A contains just IFS whitespace
characters and nothing else.

Note that while 2.6.5 can "ignore" characters from word, and can
simply not create new fields, there's nothing in it that allows the
input word to be removed completely, that is what the paragraph
that you planned on deleting is for.

So, perhaps back to something more like the proposed text for
this paragraph in note 4071, but changed from "an empty"
to "a single empty" (field) and that would work?


Hmm, even that is not right, as as
        A=: ; IFS=: ;   for x in a $A b; do printf "[%s]\n" "$x"; done
needs to produce
        [a]
        []
        [b]
and in that case field splitting did produce a single empty
field...   Sigh... (see the postscript below!)


There is one more problem (conflict) while we are here ...

2.5.2 says (of field splitting)  (lines 74850-2, page 2350)

  Field splitting as described in Section 2.6.5 would be performed if
  the expansion were not within double-quotes (regardless of
  whether field splitting would have any effect; for example, if IFS is null).

where the "for example" is the important part ... that is, this implies
that a null IFS does not prevent field splitting being performed, rather
that would simply be treated as a case like IFS=%  and there are no
'%' characters in the word, so the field splitting has no effect.

But in the 4 step procedure of 2.6 (step 2) it says ...   (lines 75002-3
page 2353)

  Field splitting (see Section 2.6.5) shall be performed on the portions
  of the fields generated by step 1, unless IFS is null.

which is quite clear that field splitting does not happen when IFS is
null, which is backed up by section 2.6.5, step 2 (line 75273, page 2359)

   If the value of IFS is null, no field splitting shall be performed.

nb: not "has no effect" or similar, but "no field splitting shall be
performed".

I think this one also needs fixing, and rather than change 2.5.2
I suspect it is simply better to drop the "unless IFS is null" from
line 75003, and change line 75273 to say

   If the value of IFS is null, field splitting has no effect

(or perhaps "makes no change" instead of "has no effect")

in order to make it clear that IFS being null does not stop
field splitting being attempted, and does not avoid the context
being one where "field splitting would be performed" (which is
relevant other places too I think) but simply results in field
spliiting being a no-op (equivalent to not being performed,
without the side effects of that.)

Lastly (and trivially), in your new proposed resolution, that is,
in note 4082, the first reference to a change in line 74998 should
be line 74992  (the second reference to line  74998 is correct).

kre

ps: once again, I wonder if perhaps just scrapping 2.6 (and I
mean just 2.6, not the various 2.6.n) and starting again, rather
than trying to find ways to bend the wording might not be a
better idea...



Reply via email to