[Top][All Lists]

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

Re: read and inconsistent handling of trailing null field?

From: Clint Hepner
Subject: Re: read and inconsistent handling of trailing null field?
Date: Wed, 29 Jan 2020 10:46:00 -0500

> On 2020 Jan 29 , at 10:30 a, Chet Ramey <address@hidden> 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.


    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 


reply via email to

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