Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > gnu.bash.bug > #15841

Re: read and inconsistent handling of trailing null field?

Show key headers only | View raw

> 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

Back to gnu.bash.bug | Previous | Next | Find similar | Unroll thread

Thread

Re: read and inconsistent handling of trailing null field? Clint Hepner <clint.hepner@gmail.com> - 2020-01-29 10:46 -0500

csiph-web