Chet Ramey wrote:
On 9/19/16 2:41 PM, Greg Wooledge wrote:
Bash has only three choices that I can think of: it can silently drop the
NUL bytes (4.3 behavior), it can drop ALL of the bytes and return an
error, or it can drop the NUL bytes with a warning (4.4 behavior).
There is a fourth choice: terminate the string read from the command
substitution at the first NUL. Pretty sure nobody wants that, even
though that's what would happen if bash didn't drop the NULs.
Does seems like it might be reasonable to allow 'null' in the list
of field separators to allow read to read such lines into separate
vars, as well as allowing it in the line-separator field to allow
such data to be read into arrays.
Does readarray allow specifying the nulls as line-terminators?
I'm generally against issuing warnings for "normal" or "default"
behavior, as it is likely to trigger spurious messages. Where are
the posts of people complaining about normal behavior? Was there any
discussion from the peanut...err, mailing list when this issue came
up? I can't believe I missed the large number of complaints about
the standard behavior.
In the same vein, is the idea of issuing warnings for improper characters
when reading in UTF-8 mode, as that will also result in data corruption or
loss of data. Do you really want to start bash being responsible to issue
warnings for any input that might not get stored correctly? That
sounds like another nasty can of worms.