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


Groups > gnu.bash.bug > #15838

read and inconsistent handling of trailing null field?

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> (permalink)
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
X-Trace usenet.stanford.edu 1580311181 12409 209.51.188.17 (29 Jan 2020 15:19:41 GMT)
X-Complaints-To action@cs.stanford.edu
To "bash.bug list" <bug-bash@gnu.org>
Envelope-to bug-bash@gnu.org
DKIM-Signature v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=ZibP6ZvAXBWXW1zM6hMF4PjwFfb4rEAsv538IDpXv9c=; b=RpkCqR7l4D4rER2f+iRB07trDk6//Yydp5VqXfRIGROz1N7RQ5ef+D2cJpHja6VtNp Rh1TrQBw4xAZTbhRtrWcDdUVgIXpj8n/tTRsvch7QombzTzHspzDdCuSiep55exyVHvP QIv4UMbVXnCHdwt0tSWpK8d4p7IemP/hUfO19M4XVBmKtJwUfLq+hPfBXhns6wE5D+mv Z1Lfeyse62Nh+ap2c3mb3XR32xMNWcCy8hLjpvVkUGz8yK/JpcMmqRIQ6QP6C7p1hAqj wfSC4dsfaCwZaiNgWZ7X/6+MSEwk09uVE0li9Qp1PWf5JBENf1zfArLfynNZlXFJnY2p 4RaA==
X-Google-DKIM-Signature v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=ZibP6ZvAXBWXW1zM6hMF4PjwFfb4rEAsv538IDpXv9c=; b=IJHnWMj9FbRfT/n3lKJzS9vnHg9iGXUqEV1ILgbRQ7rxVEkQEqGbEdjstbBFzqWHV+ TswLU9JUM7Ofj75pbdCOVV82XKqgVbfmABD/9mrA+u55+pUGRNCuNdeQ1tTNPwCGc95O 9tXmgyfwyoHCVc8FuK50YYTp8Vc/l4Z6YhjCwdPmQktVrp8NxX+9W3dsDF1pG2zJj1zP vrSK4hUunpeiP7HKfJOomXwTRKbYC5XWwMp0y765DoIBOk8L8nkGnNrkX77AbVSVT3Ye vuK0NHOwKErn4huqyAJAzYoHduuVbQvE1Yv2n9Z/TYLhKZxVk6fQw6jDydOs4y3wG51F +VbA==
X-Gm-Message-State APjAAAV4HyTzgBg/p7+pg2eBugft/2AIhcvGncZsMN2Ogeg0dfLeTWNC ID+JBlgt9yeEW3g5q4+Un1oB/2AY
X-Google-Smtp-Source APXvYqyWKvFquwKJ0VGFGWerTV6OIUKFL5kLe68Tgg0i0aKTssk7FBQi/wbFf4rGAVi3wYTMV30RoQ==
X-Received by 2002:a25:5f41:: with SMTP id h1mr8811ybm.62.1580311177216; Wed, 29 Jan 2020 07:19:37 -0800 (PST)
X-Mailer Apple Mail (2.3608.40.2.2.4)
X-detected-operating-system by eggs.gnu.org: Genre and OS details not recognized.
X-Received-From 2607:f8b0:4864:20::b2a
X-BeenThere bug-bash@gnu.org
X-Mailman-Version 2.1.23
Precedence list
List-Id Bug reports for the GNU Bourne Again SHell <bug-bash.gnu.org>
List-Unsubscribe <https://lists.gnu.org/mailman/options/bug-bash>, <mailto:bug-bash-request@gnu.org?subject=unsubscribe>
List-Archive <https://lists.gnu.org/archive/html/bug-bash>
List-Post <mailto:bug-bash@gnu.org>
List-Help <mailto:bug-bash-request@gnu.org?subject=help>
List-Subscribe <https://lists.gnu.org/mailman/listinfo/bug-bash>, <mailto:bug-bash-request@gnu.org?subject=subscribe>
X-Mailman-Original-Message-ID <122693AD-B562-43A5-BE64-58B02C72B6EA@gmail.com>
Xref csiph.com gnu.bash.bug:15838

Show key headers only | View raw


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:
        
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.

	• The field that corresponds to the last var in the normal assignment sequence described above

	• The delimiter(s) that follow the field corresponding to the last var

	• 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== read -r n v <<< "name=var="
    bash-5.0$ echo "$v"
    var

I would expect "var=" 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 =, 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== read -r n v <<< "name=var=f="
    bash-5.0$ echo "$v"
    var=f=
    bash-5.0$ IFS== read -r n v <<< "name=var=="
    bash-5.0$ echo "$value"
    var==

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


Thread

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

csiph-web