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