Re: read Built-in Parameter Behavior -- Null Byte Delimiter

[Stephane Chazelas]

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