Re: IFS field splitting doesn't conform with POSIX

[Chet Ramey]

On 3/30/23 7:12 AM, Felipe Contreras wrote:
> Hi,
>
> Consider this example:
>
>      IFS=,
>      str='foo,bar,,roo,'
>      printf '"%s"\n' $str
>
> There is a discrepancy between how this is interpreted between bash
> and zsh: in bash the last comma doesn't generate a field and is
> ignored, in zsh a last empty field is generated. Initially I was going
> to report the bug in zsh, until I read what the POSIX specification
> says about field splitting [1].

Yes, the current wording is sort of a mess. It's one of those places in
the standard where everyone "knows" what is supposed to happen, even if
it's not spelled out explicitly.

This issue came up to the POSIX group three times: 1995, 1998, and most
recently in 2005.

The 1995 interpretation confirms that a trailing IFS character does not
delimit an empty field:

https://www.open-std.org/jtc1/sc22/WG15/docs/rr/9945-2/9945-2-98.html

The 2005 discussion accepted that a trailing IFS character does not
generate a final empty field, since that reflected existing practice back
to the Bourne shell, and primarily concentrated on how word splitting and
`read' interact.

My guess is the intent is that the text about "non-zero-length IFS
whitespace shall delimit a field" is supposed to cover this case, but it
requires a creative reading of the text to get there.

kre filed an interpretation request to get the language cleaned up.

Chet
--
``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/