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