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

[Felipe Contreras <felipe.contreras@xxxxxxxxx>]

On Thu, Mar 30, 2023 at 8:58 AM Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
>
> This has been discussed before, e.g. workers/48498 about 2 years ago.
> There are even xfail tests in E03posix.ztst making note of it, added
> in workers/48560.

OK. But I don't see much of a conclusion.

Do you believe POSIX says these should be two fields? IFS=: str="a:b:"

POSIX does say the delimiter shall be considered a field terminator,
but str="a" has no field terminator, does that mean there's no valid
field? I understand from the point of view of processing strings in a
language like C it makes sense to consider an unterminated field
valid, but that's an assumption, POSIX doesn't specify that. It could
be considered that "return 0" is not a valid field (if it doesn't end
in a semicolon).

Or, one could assume POSIX meant in the case of str="a" the end of
string shall be considered an implicit terminator, but in that case
"a:b:" would have three fields, therefore making the terminators
identical to separators. In which case zsh is actually compatible with
POSIX.

So the options are:

1. zsh is compatible with POSIX
2. bash and other shells are compatible with POSIX
3. All are compatible since POSIX isn't clear

If POSIX isn't clear, then there's not much reason to implement
behavior just because other shells do it. But if you believe POSIX is
clear that the behavior of other shells is the correct one, then it
might make sense to implement it in sh mode.

Cheers.

-- 
Felipe Contreras