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: read and inconsistent handling of trailing null field?
Date: Wed, 29 Jan 2020 10:19:55 -0500
Lines: 71
Approved: bug-bash@gnu.org
Message-ID: <mailman.33.1580311181.2384.bug-bash@gnu.org>
References: <122693AD-B562-43A5-BE64-58B02C72B6EA@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=utf-8
Content-Transfer-Encoding: quoted-printable
To: "bash.bug list" <bug-bash@gnu.org>
Envelope-to: bug-bash@gnu.org
Precedence: list
Xref: csiph.com gnu.bash.bug:15838

Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: darwin19.2.0
Compiler: gcc
Compilation CFLAGS: -g -O2 -Wno-parentheses -Wno-format-security
uname output: Darwin hemma.local 19.2.0 Darwin Kernel Version 19.2.0: =
Sat Nov  9 03:47:04 PST 2019; root:xnu-6153.61.1~20/RELEASE_X86_64 =
x86_64
Machine Type: x86_64-apple-darwin19.2.0

Bash Version: 5.0
Patch Level: 11
Release Status: release

Description:
       =20
read seems to incorrectly drop a null field when performing =
word-splitting and more fields than variables.

All the examples below use

    IFS=3D=3D read -r n v

for some input of the form ``name=3Dvar...``


The relative bit of the POSIX spec concerns how to set the variables =
when there are fewer arguments
to read than there are fields.

	=E2=80=A2 The field that corresponds to the last var in the =
normal assignment sequence described above

	=E2=80=A2 The delimiter(s) that follow the field corresponding =
to the last var

	=E2=80=A2 The remaining fields and their delimiters, with =
trailing IFS white space ignored

Repeat-By:


    % ./bash
    bash-5.0$ echo $BASH_VERSION
    5.0.11(5)-release
    bash-5.0$ IFS=3D=3D read -r n v <<< "name=3Dvar=3D"
    bash-5.0$ echo "$v"
    var

I would expect "var=3D" as the output, as the string is split into 3 =
fields (the last being empty).
(ksh and dash also drop the final null field, which is what makes me =
suspect I am missing a subtlety
of the POSIX spec. zsh seems to preserve the final =3D, though I did not =
dig into which options
I have set that might affect the result.)

Same result using here-document, so I don't think this is a here-string =
issue.

If the trailing null field is not the one to put the field count over =
the argument count, it
works as expected.

    bash-5.0$ IFS=3D=3D read -r n v <<< "name=3Dvar=3Df=3D"
    bash-5.0$ echo "$v"
    var=3Df=3D
    bash-5.0$ IFS=3D=3D read -r n v <<< "name=3Dvar=3D=3D"
    bash-5.0$ echo "$value"
    var=3D=3D=