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