Discrepancy in IFS handling (zsh is *not* POSIX compliant)

[Felipe Contreras <felipe.contreras@gmail.com>]

On Thu, Mar 30, 2023 at 6:05 AM Lawrence Velázquez <larryv@zsh.org> wrote:
>
> On Mar 30, 2023, at 7:13 AM, Felipe Contreras <felipe.contreras@gmail.com> wrote:
>
> However, this is what POSIX says:
>
>    3.b. 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.
>
> We ignore all the white space stuff (since we are not using white
> spaces), and thus:
>
>    Each occurrence in the input of an IFS character shall delimit a field.
>
> In zsh each occurrence of a comma does delimit a field (4 commas, 5
> fields), which to me is what POSIX says should happen.
>
> So in this particular case it seems zsh is complying with POSIX (even
> in zsh mode), and all other shells are not.
>
>
> Before the excerpt you quoted, XCU 2.6.5 says: “The shell shall treat each character of the IFS as a delimiter and use the delimiters as field terminators to split the results of parameter expansion, command substitution, and arithmetic expansion into fields.”
>
> The bash/dash/ksh behavior is not unreasonable if the phrase “field terminators” is interpreted strictly.
>
> In any case, I believe the standard intends to describe the ksh behavior:

Yes, I was about to click send to point that out.

So if IFS contains terminators, and not separators, this should
generate 5 fields:

    IFS=';'
    str='foo;bar;;roo;;'
    printf '"%s"\n' $str

For: 'foo;' 'bar;' ';' 'roo;' ';'

In which case bash is correct, zsh generates 6 fields, so it's not.

Seems weird that a variable called Internal Field Separator is not a
*separator*, but a terminator.

I'm changing the subject to reflect that.

Cheers.

-- 
Felipe Contreras