On Nov 23, 2011, at 4:47 PM, Chet Ramey wrote: > On 11/23/11 9:03 AM, Matthew Story wrote: >> Bash Version: GNU bash, version 4.1.7(1)-release (amd64-portbld-freebsd8.0) >> OS: FreeBSD 8.0 >> Hardware: amd64 >> Environment: jail >> Description: read terminates reading all records at first null-byte ( chr(0) >> ) in a stream, null-bytes are valid ascii characters and should not cause >> read to stop reading >> a line this behavior is not reproducible using bourne shell. > > Bash doesn't stop reading at the NUL; it reads it and the rest of the line > up to a newline. Since bash treats the line read as a C string, the NUL > terminates the value assigned to `foo'.
it seems to terminate all assignment of the current line at the first `\0', not merely the value assigned to `foo': [bash ~]$ printf '%s\0 %s\n%s\n' foo bar baz | while read foo bar; do echo "$foo" "$bar"; done | od -a 0000000 f o o sp nl b a z sp nl 0000012 it's clear from this example (and from what you've said above) that read does not halt entirely here as it processes the next line correctly, and ` bar' is not left in the buffer after first read. What I find confusing about this comment and Greg's comment (copied in below) ... > [Greg Wooledge <wool...@eeg.ccf.org>] > What happens here is bash reads until the newline, but only the "foo" > part is visible in the variable, because the NUL effective ends the > string. ... is that if the line were fully assigned along the lines of my understanding of read, foo should be `foo', up to the null-bye which effectively terminates the string, and then bar should be `bar'. > Bash doesn't drop NULs like the > FreeBSD (not the Bourne) shell. FreeBSD sh indeed, apologies for the misstatement. > > Chet > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, ITS, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet/ >
