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

Groups > gnu.bash.bug > #14239 > unrolled thread

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

Back to article view | Back to gnu.bash.bug

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  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

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

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.

[toc] | [standalone]

Back to top | Article view | gnu.bash.bug

csiph-web