2016-01-18 11:16:06 -0500, Chet Ramey:
[...]
> > But it's
> > an incredibly useful feature, and has been used in countless real
> > life scripts. At this point, while it is still undocumented, it is
> > nevertheless a feature whose omission would be considered a regression.
>
> It's not a special case that needs to be documented as such. It's a
> straightforward application of the rules for assigning the delimiter
> and reading it. You do have to understand how C strings work and how
> they are used when passing arguments to commands for it to make sense.
[...]
You should not have to understand C strings to be able to use a
shell.
C strings are *encoded* with a NUL delimiter. Stricktly
speaking, that NUL is not part of the line's content. "read -d
something" sets the delimited to the first character of
"something", with read -d "", there's no character in that
string.
I think there's no way anyone that has no notion of C could
guess that
read -d '' var
reads until the first NUL character.
A more intuitive reading of that would be that it disables
delimiters altogether (reads until end of file).
I'd agree it should be documented and that it's a useful feature.
An I see the same feature is coming to readarray/mapfile in 4.4
which is welcome as well.
Also, we see people doing:
read -d $'\0' var
That is actually doing what it seems to be saying on the can
(read until a $'\0'), except that what it says on the can is
wrong, since
read -d $'\0' var
actually calls "read" with ("read", "-d", "", "var") arguments.
It may be worth mentioning that command line arguments, here
documents and variables in bash don't support the NUL character
(and how it behaves in various contexts).
--
Stephane
