Re: document that read built-in can't return zero-length string in the middle of input

[Ángel]

On 2024-01-11 at 09:29 -0500, Chet Ramey wrote:
> On 1/11/24 2:37 AM, ilya Basin wrote:
> > Dear.
> > I needed to read 16 bytes from a binary file and tried to replace a
> hexdump call with read built-in. I expected that with "-N1" if a NUL
> character is encountered bash would assign an empty string, however
> there's no indication that a NUL character was there and it simply
> assigns the next non-NUL character to the variable.
> 
> The read builtin skips over NUL characters because you can't store them
> as part of the value of a shell variable. That seems obvious.

While doing  read -N 16 from a file bigger than 16 bytes and ending up
with less than that (e.g. only 10 bytes because the other 6 turned out
to be NULs) would be surprising, the assumption of the OP that when
using -N1 a NUL byte would become an empty string doesn't seem far-
fetched.



> What would you like to see documented? That NUL characters don't
> count towards the number of characters read to satisfy -N? Doesn't
> that follow from the above?

Not eccessarily. The phrase "reading exactly nchars characters" depends
on (a) what you consider to be reading, as you are read(2)ing more
bytes than stated with -N; and (b) what you consider to be a character.

One might say "reading exactly nchars characters into the name", but
given that there's no mention that the NULs are never stored in
variables, I would tend to add a line below saying e.g. "NUL characters
cannot be stored in bash variables and are always ignored by read".


Regards