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

Groups > gnu.bash.bug > #15838 > unrolled thread

read and inconsistent handling of trailing null field?

Back to article view | Back to gnu.bash.bug

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

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

#15838 — read and inconsistent handling of trailing null field?

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==

[toc] | [standalone]

Back to top | Article view | gnu.bash.bug

csiph-web