On 9/19/16 12:28 PM, L. A. Walsh wrote: > > > 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.
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)?" -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet/
