Re: Command substitution with null bytes generates warning

[Chet Ramey]

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    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/