Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > gnu.bash.bug > #14239

Re: When reading less than wanted characters, "read" does not detect NUL bytes

Show key headers only | View raw

On Fri, 15 Jun 2018 09:07:46 -0400, Greg Wooledge <wooledg@eeg.ccf.org>
wrote:

> On Fri, Jun 15, 2018 at 03:03:21PM +0200, Davide Brini wrote:
> > $ printf 'a\x00\x00bc' | { while IFS= read -d '' -n 2 var; do echo
> > "read: $var, length: ${#var}"; done; } read: a, length: 1
> > read: , length: 0
> > read: bc, length: 2
> > 
> > I would expect there to be another read of length 0 between the "a" and
> > the "bc".  
> 
> Seems correct to me.  You asked it to stop reading when it finds a NUL
> or when it has read 2 characters.  The first time, they both happen at
> the same time, and you end up with "a", and two bytes have been consumed.
> 
> The second time, it happens after reading the NUL byte, so you get "" and
> a total of three bytes have been consumed.
> 
> The third time, you read "bc", and all the bytes have been consumed.

Oh I see, I was misled by the -n1 behavior and thought the delimiter somehow
would be "put back" for the next read, but your explanation makes sense.

So it looks like the only "reliable" way to detect NULs in the input is to
read one character at a time.

Thanks!

-- 
D.

Back to gnu.bash.bug | Previous | Next | Find similar | Unroll thread

Thread

Re: When reading less than wanted characters, "read" does not detect NUL bytes Davide Brini <dave_br@gmx.com> - 2018-06-15 15:15 +0200

csiph-web