Re: read and inconsistent handling of trailing null field?

[Clint Hepner]

> On 2020 Jan 29 , at 10:30 a, Chet Ramey <chet.ramey@case.edu> wrote:
> 
> On 1/29/20 10:19 AM, Clint Hepner wrote:
> 
>> Bash Version: 5.0
>> Patch Level: 11
>> Release Status: release
>> 
>> Description:
>> 
>> read seems to incorrectly drop a null field when performing word-splitting 
>> and more fields than variables.
>> 
>> All the examples below use
>> 
>>    IFS== read -r n v
>> 
>> for some input of the form ``name=var...``
>> 
>> 
>> The relative bit of the POSIX spec concerns how to set the variables when 
>> there are fewer arguments
>> to read than there are fields.
> 
> There are exactly two variables and two (split) arguments.
> 
> "The shell shall treat each character of the IFS as a delimiter and use the
> delimiters as field terminators to split..."
> 
> https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_05
> 
> 

Ah, OK. So if I have

    IFS=, read -r n v <<< "a,b,c,"

there are two variables and 3 split arguments: "a", "b", and "c". Then 
according to the
specification for read, "a" is assigned to n, and we assign to v as follows:

  1. first add the second field "b": v=b
  2. then the delimiter following "b": v=b,
  3. The remaining fields and their delimiters: first v=b,c then v=b,c,

So the final "," in the value of v isn't separating c and a mythical null 
field, but
is terminating the final field c.

Then

    IFS=, read -r n v <<< "a,b,,"

has fields "a", "b", and "", and again v is assigned "b", ",", "", ",".

Thanks Chet and Greg (for pointing out 
https://mywiki.wooledge.org/BashPitfalls#pf47)

-- 
Clint