Shell Programming and Scripting

On my Debian system under bash the following command returns 24 files.

Code:

 find /root/bin/ -name '*'

while the following returns none

Code:

 FIND="-name '*'"; find /root/bin/ $FIND

Asking on the Debian Users list I've been shown work arounds but not explanations. I'm hoping someone here can explain 'why' $FIND is not being interpreted by find as I expected. Thanks, Mike McClain

If you enable tracing with "set -x", bash will print each command after it's done all the expansions and substitutions. You'll probably be able to see where things diverge.

As the shell's parser consumes the command line, it treats all text within unescaped single quotes literally. In this case, the asterisk in your first command is never expanded and remains an asterisk. When the shell is done parsing the command line, it removes those quotes (quote removal is the final step in sh parsing) and passes the literal asterisk as one of the arguments to the find command.

In the second version, using $FIND, the quotes contained in $FIND's value are NOT part of the command line, so they are not special. They do not appear until after the shell has done parameter expansion on $FIND. So, since those single quotes are not part of the initial command line, they do not protect the asterisk from being treated as a pathname expansion wildcard. The penultimate step during sh parsing, just before quote removal, is this pathname expansion step. The shell, having already done paremeter expansion at this point, is seeing '*', those single quotes are not special, and it will try to match that pattern against pathnames. Unless you have files/directories in the current directory whose names begin and end with a single quote, there will be no match. When a pathname expansion pattern does not match anything, the shell leaves it alone. So, when the find command runs, it will run with an argument of single quote, asterisk, single quote (assuming no match).

You may be wondering, "well, if the single quotes aren't special, why is the asterisk?". Quoted strings are identified before parameter expansion occurs; the pathname expansion step happens afterwards.

It'll probably work as you intend if you use eval, although there are important caveats if that route is chosen (mostly security related):

Code:

eval find /root/bin/ $FIND

Regards,
Alister

Code:

set -x; FIND='-name "*"';find /root/bin $FIND; echo $FIND

+ set -x + FIND=-name "*" + find /root/bin -name '"*"' + echo -name '"*"' -name "*"

Code:

 touch '/root/bin/"foo"'

+ touch '/root/bin/"foo"'

Code:

set -x; FIND='-name "*"';find /root/bin $FIND; echo $FIND

+ set -x + FIND=-name "*" + find /root/bin -name '"*"' /root/bin/"foo" + echo -name '"*"' -name "*" You'll note the file with quotes in the name. Looks to me that bash puts an extra set of quotes around the quoted term in the variable upon expansion. I can't think why that would be. I don't think this is going to display properly, sorry. Thanks for your help, Mike

The trace output is correct. It adds those quotes because that's the proper equivalent of the command it's executing (after all expansions and substitutions) had it been typed at the terminal.