Re: Command substitution with null bytes generates warning

[L. A. Walsh]

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 read
such 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 bother
reading 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 to
shut them up. 


> Chet
>