bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bash 4.4 null byte warning!!


From: Greg Wooledge
Subject: Re: bash 4.4 null byte warning!!
Date: Thu, 6 Apr 2017 10:45:24 -0400
User-agent: Mutt/1.4.2.3i

On Thu, Apr 06, 2017 at 07:47:35AM +0000, emlyn.jose@wipro.com wrote:
> FIND_RPM=`find /opt/RPM/components -type d -name enum-1.1.6 -print0`
> It throws a warning as below:
> 
> bash: warning: command substitution: ignored null byte in input

Your command is broken, and bash is warning you of this.  Why do you want
to silence the warning instead of fixing the command?

If your find returns a single result, you get a filename followed by NUL,
and the NUL is discarded, leaving you a filename inside the command
substitution (and therefore the variable).  You could achieve the EXACT
same result by dropping the -print0.  Then, if you get a single result
from find, you get the filename followed by newline, and the command
substitution discards the trailing newline, leaving you just the filename
in the command substitution and therefore the variable.

On the other hand, if your find command returns MULTIPLE results, then
you have file1\000file2\000 and the command substitution drops the NUL
bytes, leaving you with file1file2 in your variable.  At least if you
dropped the -print0 you would have file1\nfile2 in your variable, which
is still wrong, but not as wrong as file1file2.

> Is there any patch available for this or is there any way to make bash 
> silently drop this warning(which has been the behavior on the lower versions 
> of bash)??

If you REALLY want to continue to run a broken command, you can explicitly
use tr to remove the NULs before the command substitution ever sees
them.

var=$(find ... -print0 | tr -d '\0')

That will prevent the warning and allow you to continue running a broken
script without letting your coworkers catch on to the bugs (or whatever
your issue with the warning is).

If you actually want to FIX the script, the results of find should be
read into an array, since there can be more than one.  Every place you
use your variable currently, you'd have to rewrite that to handle an
array with potentially multiple elements.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]