[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IFS field splitting doesn't conform with POSIX

From: Chet Ramey
Subject: Re: IFS field splitting doesn't conform with POSIX
Date: Fri, 31 Mar 2023 14:10:10 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.8.0

On 3/30/23 7:12 AM, Felipe Contreras wrote:

Consider this example:

     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:


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.

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]