|
From: | L. A. Walsh |
Subject: | Re: Command substitution with null bytes generates warning |
Date: | Mon, 19 Sep 2016 09:28:53 -0700 |
User-agent: | Thunderbird |
Chet Ramey wrote:
On 9/16/16 1:51 AM, Eric Pruitt wrote:Bash Version: 4.4 Patch Level: 0 Release Status: release Description: I have a script that execute `if [[ "$(<"/proc/$1/cmdline")" = tmux* ]];`. All /proc/*/cmdline include null bytes, and as of Bash 4.4, this results in a warning being spewed on stderr which did not happen in Bash 4.3.Other users have expectations that differ from yours. I received messages reporting the the bash-4.3 behavior (the longtime bash behavior) as a bug. Warning the user that bash discards some characters from the command substitution output seemed like the course that would let everyone know what's happening regardless of their expectations.
--- If users were relying on this behavior (I know I have scripts that read things from proc -- a text interface that uses \0 to display values similar to MS's multi-string Values in the Windows registry. Perhaps worse, not sure, but cygwin has a /proc/registry to allow programs/scripts to read values from the registry. I have several that readsuch values. Of course, I know they are dropped -- I've complained about the fact that they are dropped in the past and wanted a way to read them, but that's
not this problem. The "other users" you are talking about, are ones who don't botherreading documentation or understanding the technology. Changing working features to throw diag-messages is dumbing down bash to the lowest common
denominator. Could you change it back or provide a way to suppress "kiddy-scripter" seatbelts? Just because people who don't know anything about how strings are handled on unix, doesn't mean you should dump to change something toshut them up.
Chet
[Prev in Thread] | Current Thread | [Next in Thread] |