On Sun, Jan 12, 2025 at 16:26:04 -0500, Chet Ramey wrote:
> > In this case, we get the "expected" result:
>
> You just restated the original example while ignoring the part of my
> message about looking for additional input after you find a delimiter.
Right. You explained why it works the way it does. But from a user's
point of view, it's just unexpected behavior.
I'm not asking for anything to be changed, because I know that's not an
option. All I can do at this point is try to make sure people are
aware that the read command has this behavior, and that they should
plan around it.
If one is reading a CSV file, then there are approprate tools that can
be used. This part has been covered.
However, a common reason someone uses "IFS=: read -r var1 rest"
is because they're reading a text file/stream in which each line has
a delimited field, followed by a delimiter, followed by a bunch of
unpredictable free text. Maybe it's a filename, or a description, or
something a user typed.
If one wants everything after the delimiter to be stored in the "rest"
variable *without modification*, the read command shown above won't
do the job. It modifies the line in a very specific edge case, which
one's testing probably won't encounter.
That's the pitfall.
As a workaround, one may append an extra delimiter to the line, then
do the read, then strip the added delimiter. That's on the wiki page.
Or, one may read the entire line without field splitting it at all,
and then use ${line%%:*} and ${line#*:} to split it.
