bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Davide Brini
Subject: Re: When reading less than wanted characters, "read" does not detect NUL bytes
Date: Fri, 15 Jun 2018 15:15:23 +0200

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]