Date: Sun, 12 Jan 2025 16:55:05 -0500
From: Greg Wooledge <g...@wooledge.org>
Message-ID: <20250112215505.gb27...@wooledge.org>
| Right. You explained why it works the way it does. But from a user's
| point of view, it's just unexpected behavior.
It is unexpected, because users believe (from other experience)
that the delimiters separate fields, but in sh they don't, they
terminate fields. The only slight oddity is that the end of
record counts as a terminating delimiter for the final field if
the terminating delimiter that should have been there is missing
(but if the delimiter is there, followed immediately by the end
of the record, which is kind of how it is expected to be, then
that's OK too, and does not make extra fields).
While I'm here I'll make a minor correction to one thing Chet
said earlier (slightly sloppy wording rather than his not knowing
what the rule really is)
chet.ra...@case.edu said:
| Which basically means that the last variable gets everything else on the
| line, including non-whitespace IFS characters.
Whitespace IFS characters are included as well, just not leading, or trailing
IFS whitespace, any other IFS whitespace is included in that last var which
is accumulating the remaining data.
So, if the IFS=$' ,' (similar to what has been used in these examples,
but with some whitespace included for this example to make sense) and we
do
printf %s\\n 'a, b, c ' | read -r a b
then read will assign 'a' to var a, and 'b, c' to var b, the space before
b is gone, as is the one after c, but the one in the middle remains (as would
any others there, with or without the ',' after "b").
kre
ps: I know the above example is useless, as generally the a and b vars
would be in the subshell created for the pipe commands, which vanishes
as soon as the read is finished, but since there is nothing in this example
which wants to use the values, that's OK.
