On Fri, 2022-04-22 at 12:03 +0100, Geoff Clare via austin-group-l at
The Open Group wrote:
>
> I like this suggestion, although "any character of the characters"
> is a bit strange. I'll go with "any of the characters".
Yes, that makes sense.
> > 3) You introduce bytes/byte sequences vs. characters.
> >
> > I don't understand why you need that at all?
>
> The current wording in terms of characters implies that the word
> being
> subjected to field splitting can be treated as a character string.
> I wanted to ensure that there is no possible way to infer that as
> being allowed by the new text.
Okay. Fair enough.
Do you think that similar explanations would be needed for the other
expansions/substitutions?
> > => But there is one thing that's IMO lost on the way:
> > The old:
> > " any sequence of <space>, <tab>, or <newline> characters at the
> > beginning or end of the input shall be ignored and any sequence of
> > those
> > characters within the input shall delimit a field"
> >
> > "sequence of those characters" indicated that a sequence of 1-n IFS
> > characters were still regarded as one single field splitter.
> >
> > With the new:
> > "ignored and any sequence of such bytes"
> > that's IMO a bit lost... sequence of bytes is rather considered
> > like ONE
> > "multi-byte" character.
>
> Each of the bytes in question encodes a single-byte character, so
> it's
> impossible for them to combine to form one multi-byte character.
Ah... ok... I had arbitrary (multi-byte) characters for IFS in mind,
but point (1) on page 2325 is only about the specific characters
<space>, <tab> and <newline>.
But still, this (i.e. that these characters are per POSIX always one
byte) is quite "special knowledge", so why not - similar to your change
below - add a "(zero or more instances)" for the 1st case?
At least I'd say it should be "zero or more", cause for for the
beginning/end if there are no such IFS characters, they'd also be
ignored and no further field would result.
> > You don't have that problem with the 4th change, where you
> > explicitly say:
> > "any sequence (zero or more instances) of the byte sequences that
> > comprise
> > white-space characters"
>
> I'll insert "(one or more instances)".
Your addition of "(one or more instances)" for the 2nd case is IMO
quite good, as with "any" it's not always clear if it would also
include the "empty element" (as it does in principle for the 1st
case)... and here it clearly means "at least one".
Btw: Doesn't it need to say "any sequence of <space>, <tab>, AND
<newline>" instead of "... or ..."?
In my understanding... the "any of" gives one the arbitrary choice of
elements/order of the "set" described afterwards.
If that "set" is "<space>, <tab>, OR <newline>" than I'd rather read it
as "either of them"... so it would be "any seq. of space OR any seq. of
tab OR any seq. of newline"?
On Fri, 2022-04-22 at 12:13 +0100, Geoff Clare via austin-group-l at
The Open Group wrote:
> Geoff Clare wrote, on 22 Apr 2022:
> >
> > I'll insert "(one or more instances)".
>
> And having done so, the use of "zero or more instances" in the
> paragraph about IFS white space now seems wrong to me. I think it
> should be one or more as well.
Uhm... let me see...
For (3a): "IFS white space shall be ignored at the beginning and end of
the input."
0-n would IMO still be ok, because zero IFS whitespace at the
beginning/end is of course also ignored.
For (3b): "Each occurrence in the input of an IFS character that is
not IFS white space, along with any adjacent IFS white space,
shall delimit a field, as described previously."
For "an IFS character that is not IFS white space", 0-n would IMO be
ok.
For "along with any adjacent IFS white space", 0-n would IMO work...
the 0-n because it's "along" any non-whitespace-IFS-character... so
whether you have 0 or more, doesn't matter.
BUT... 1-n may not work, because and assuming that "any" be interpreted
to not contain the "empty element"... that would mean, that such
delimiter would need to look like any of:
- <non-whitespace-IFS-character><at least
1 whitespace-IFS-character>
- <at least 1 whitespace-IFS-character><non-whitespace-IFS-character>
- <at least 1 whitespace-IFS-character><non-whitespace-IFS-character><at least
1 whitespace-IFS-character>
For (3c): "Non-zero-length IFS white space shall delimit a field."
0-n would IMO be ok, as it specifically says "non-zero-length" ...
which might be obsolete with your change.
So I think, that it needs to stay "zero or more"... or "any" needs to
be clarified... or the text for (3b) changed somehow.
Cheers,
Chris.
