Re: IFS whitespace definition

[Chet Ramey]

On 10/21/24 10:13 AM, Robert Elz wrote:

>    | The word splitting section wasn't quite
>    | as rigorous as the current version's, but it referenced this definition.
>
> Actually, it didn't, which was one of that section's many problems.
>
> What it said was
>
>         The term ``IFS white space'' is used to mean any sequence (zero or
>         more instances) of white-space characters that are in the IFS value
>
> There's no reference to anything in XBD, and the term it uses is
> "white-space" not "white space" which the definitions define.   And
> yes, that hyphen really makes a difference in things like this.

Sure. Still, a lot of people, including the folks in the austin group,
made that logical jump.

>    | However, the conformance suite tests for this.
>
> That has tested for what its developers thought the standard said,
> rather than what it actually says, before, and probably will again.

Sure. And you still couldn't get certification without passing the test
suite, so it's the de facto standard. At least the current version has
this clarified.

>    | The comment in locale_setblanks explains this: some systems, like macOS,
>    | return true from isspace() for characters between 0x80 and 0xff even
>    | though they introduce multibyte characters (every locale besides "C"
>    | in macOS uses UTF-8 encoding).
>
> I assume that the macos people assume that if you're fetching multi-byte
> characters you should be fetching the whole character before testing what
> kind of object it is.

Yes, that's what bash does, and it allows multibyte characters in $IFS.

But Greg was asking about the code that sets the `blank' status of
bytes between 0 and CHAR_MAX, and I explained why bash does what it does.

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/

OpenPGP_signature.asc
Description: OpenPGP digital signature