Eric Blake wrote:
On 09/19/2016 11:58 AM, Greg Wooledge wrote:
wooledg@wooledg:~$ x=$(< /proc/$$/cmdline)
bash-4.4: warning: command substitution: ignored null byte in input
wooledg@wooledg:~$ x=$(< /proc/$$/cmdline 2>/dev/null)
wooledg@wooledg:~$

Or:

$ x=$(< /proc/$$/cmdline tr -d \\0)
Admittedly better, as it doesn't suppress valid messages, but still
requires tracking down source code mods on multiple machines and making
changes for something that wasn't a problem.  Why should people who
didn't expect them to make any difference (the valid behavior) be penalized
because others didn't know.

How about, w/r/t the new warning -- I complain because the null bytes
are missing after bash knowingly detected them and illegally modified
the input.  Putting out a warning about null bytes, doesn't mean it's
"ok" to drop them.  Now it's just compounded with an anti-unix (silence
is golden) warning message.

^^ see, you can still complain about the null bytes regardless of the
warning.  The warning is just adding salt to the wound -- like "nyaa nyaa,
I know about the null bytes, and am still refusing to return them to you!!!"

What's the purpose in making emit warnings about everything
that doesn't work?  Could just fix it and use the C++ definition
of Strings that have a builtin count and can handle nulls in the middle
of the data... ;^/




Reply via email to