Path: csiph.com!xmission!news.snarked.org!news.linkpendium.com!news.linkpendium.com!panix!usenet.stanford.edu!not-for-mail
From: Clint Hepner <clint.hepner@gmail.com>
Newsgroups: gnu.bash.bug
Subject: Re: read and inconsistent handling of trailing null field?
Date: Wed, 29 Jan 2020 10:46:00 -0500
Lines: 68
Approved: bug-bash@gnu.org
Message-ID: <mailman.38.1580312750.2384.bug-bash@gnu.org>
References: <122693AD-B562-43A5-BE64-58B02C72B6EA@gmail.com> <f6382f38-add8-731a-6d47-77d292d013c8@case.edu> <A1A301FD-7C11-4F0F-84D1-299CCF10F8D3@gmail.com>
NNTP-Posting-Host: lists.gnu.org
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\))
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Cc: "bash.bug list" <bug-bash@gnu.org>
To: chet.ramey@case.edu
Envelope-to: bug-bash@gnu.org
In-Reply-To: <f6382f38-add8-731a-6d47-77d292d013c8@case.edu>
Precedence: list
Xref: csiph.com gnu.bash.bug:15841



> On 2020 Jan 29 , at 10:30 a, Chet Ramey <chet.ramey@case.edu> wrote:
>=20
> On 1/29/20 10:19 AM, Clint Hepner wrote:
>=20
>> Bash Version: 5.0
>> Patch Level: 11
>> Release Status: release
>>=20
>> Description:
>>=20
>> read seems to incorrectly drop a null field when performing =
word-splitting and more fields than variables.
>>=20
>> All the examples below use
>>=20
>>    IFS=3D=3D read -r n v
>>=20
>> for some input of the form ``name=3Dvar...``
>>=20
>>=20
>> The relative bit of the POSIX spec concerns how to set the variables =
when there are fewer arguments
>> to read than there are fields.
>=20
> There are exactly two variables and two (split) arguments.
>=20
> "The shell shall treat each character of the IFS as a delimiter and =
use the
> delimiters as field terminators to split..."
>=20
> =
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#=
tag_18_06_05
>=20
>=20

Ah, OK. So if I have

    IFS=3D, 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=3Db
  2. then the delimiter following "b": v=3Db,
  3. The remaining fields and their delimiters: first v=3Db,c then =
v=3Db,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=3D, 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)

--=20
Clint=