|
From: | L. A. Walsh |
Subject: | Re: Command substitution with null bytes generates warning |
Date: | Mon, 19 Sep 2016 13:10:56 -0700 |
User-agent: | Thunderbird |
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.
Hmm.... 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.
[Prev in Thread] | Current Thread | [Next in Thread] |