Date: Thu, 17 Oct 2024 18:44:59 -0400
From: Greg Wooledge <g...@wooledge.org>
Message-ID: <zxgta0jhalvzh...@wooledge.org>
| Between bash 4.4 and 5.0, the definition of "IFS whitespace" has apparently
| been expanded:
Not going to comment on bash, or its manual, specifically, but the
standard allows anything that the locale defines as in the space
category of the current locale to be IFS whitespace, if present in IFS ...
but requires that space, tab, and newline (again, if present in IFS) be
IFS whitespace, whatever the locale specifies.
Which (of any) character other than space, tab, and newline (which are in
the locale's space class) count as IFS whitespace is up to the implementation.
Personally, I don't add any, it makes for unpredictable script behaviour
(how things are processed depends upon what locale the user running the
script happens to have chosen), but implementations can certainly alter
that if they want (including to be just 1 byte and isspace() is true).
And to add one other complication (aside from the required 3) it is
unspecified whether the implementation decides what IFS white space
is present in IFS when IFS is assigned a value (using the locale then
current) or when IFS is used to split something (using perhaps a different
locale set at that point). Again, implementations can do it either way.
All this adds up to the strong recommendation that applications add nothing
to IFS which might be considered white space (or "space" class) in any locale
(except space, tab, & newline) unless the application simply doesn't care
whether they're considered IFS whitespace or not (simply using IFS as a
way to "edit out" characters that aren't wanted).
kre
