[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Command substitution with null bytes generates warning

From: L. A. Walsh
Subject: Re: Command substitution with null bytes generates warning
Date: Tue, 20 Sep 2016 10:35:40 -0700
User-agent: Thunderbird

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
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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]