|
From: | Linda Walsh |
Subject: | Re: Command substitution with null bytes generates warning |
Date: | Mon, 19 Sep 2016 11:30:56 -0700 |
User-agent: | Thunderbird |
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... ;^/
[Prev in Thread] | Current Thread | [Next in Thread] |