Re: IFS field splitting doesn't conform with POSIX

[Greg Wooledge]

On Thu, Mar 30, 2023 at 05:12:46AM -0600, Felipe Contreras wrote:
>     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,

... which is correct according to POSIX (but not sensible).

> 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].

You seem to have misinterpreted whatever you read.

https://mywiki.wooledge.org/BashPitfalls#pf47

    Unbelievable as it may seem, POSIX requires the treatment of IFS as
    a field terminator, rather than a field separator. What this means
    in our example is that if there's an empty field at the end of the
    input line, it will be discarded:

    $ IFS=, read -ra fields <<< "a,b,"
    $ declare -p fields
    declare -a fields='([0]="a" [1]="b")'

    Where did the empty field go? It was eaten for historical reasons
    ("because it's always been that way"). This behavior is not unique
    to bash; all conformant shells do it.