Re: Command substitution with null bytes generates warning

[L. A. Walsh]

Chet Ramey wrote:
> Don't assume that every use of something like this has to do with /proc.
> Here's a representative report:
>
> "I was wondering what would happen if I'd do something like that:
> $ foo="$(cat file_containing_ascii_null_byte)"
> or faster
> $ foo="$(<file_containing_ascii_null_byte)"
>
> I checked it out and had to realize that the ASCII char \0 had
> been filtered out of the file before it was assigned to foo.
> Unfortunately a web search and a quick look at
> http://www.gnu.org/software/bash/manual/bash.html#Command-Substitution
> didn't help me.
>
> Is this behaviour intended? Is there any possibility to fix that
> (if it's no feature)?"
>   
----
I asked the same question and wanted the same resolution -- some way to
accomplish what I intended.  I never asked for a WARNING... that's literally
putting salt in the wound.  I can see it wouldn't be easy to implement given
other constraints, but that doesn't mean I wouldn't like the feature if it
was able to be implemented.    But giving a warning that you can't globally
turn off?  Just because people *want* a feature doesn't mean you should
~flaunt~ (hyperbole) Bash's lack of the feature with warnings that can't
be disabled. _If_ I didn't know better, I'd say it was malicious checks
to ensure no one would expect it.  Whereas I would counter with: is it
documented under the read function?

If it wasn't documented, what would you expect people to "expect" or "ask
about"?  So what happens if I read in invalid UTF8, or if I read in a file
from disk that has no "\n" at the end of the file -- do you add one?  Do you
throw away the line?  Various pieces of software feel a need to change 
previous
behavior (nothing special was done and usually you had a partial line at 
the end
of the file), by either ignoring the last line (rare, usually accident) or
appending one for you (which corrupts text files that are size-checked as a
means for determining validity).

Now bash emits warnings for what has been *normal* behavior.  So anyone with
working code/scripts that expect the normal behavior will now be penalized
with a new warning that can't be globally turned off -- only by editing
all the instances.  That's not a good way to deal with this -- especially if
all these borderline cases aren't documented in the manpage.

-l