find command works on prompt, not in bash script - pass multiple arguments by variable

If you want to store a list of arguments and expand it later, the correct form to do that with is an array, not a string:

includeArgs=( -wholename './public_html/*' -o -wholename './config/*' )
find . '(' "${includeArgs[@]}" ')' -type f -mtime -7 -print

This is covered in detail in BashFAQ #50.

^{Note: As Etan points out in a comment, the better solution in this case may be to reformulate the find command, but passing multiple arguments via variable(s) is a technique worth exploring in general.}

tl;dr:

The problem is not specific to find, but to how the shell parses command lines.

• Quote characters embedded in variable values are treated as literals: They are neither recognized as argument-boundary delimiters nor are they removed after parsing, so you cannot use a string variable with embedded quoting to pass multiple arguments simply by directly using it as part of a command.

• To robustly pass multiple arguments stored in a variable,

  • use array variables in shells that support them (bash, ksh, zsh) - see below.
  • otherwise, for POSIX compliance, use xargs - see below.

Robust solutions:

Note: The solutions assume presence of the following script, let's call it echoArgs, which prints the arguments passed to it in diagnostic form:

#!/usr/bin/env bash
for arg; do     # loop over all arguments
  echo "[$arg]" # print each argument enclosed in [] so as to see its boundaries
done

Further, assume that the equivalent of the following command is to be executed:

echoArgs one 'two three' '*' last  # note the *literal* '*' - no globbing

with all arguments but the last passed by variable.

Thus, the expected outcome is:

[one]
[two three]
[*]
[last]

• Using an array variable (bash, ksh, zsh):

# Assign the arguments to *individual elements* of *array* args.
# The resulting array looks like this: [0]="one" [1]="two three" [2]="*"
args=( one 'two three' '*' )

# Safely pass these arguments - note the need to *double-quote* the array reference:
echoArgs "${args[@]}" last

• Using xargs - a POSIX-compliant alternative:

POSIX utility xargs, unlike the shell itself, is capable of recognized quoted strings embedded in a string:

# Store the arguments as *single string* with *embedded quoting*.
args="one 'two three' '*'"

# Let *xargs* parse the embedded quoted strings correctly.
# Note the need to double-quote $args.
echo "$args" | xargs -J {} echoArgs {} last

Note that {} is a freely chosen placeholder that allows you to control where in the resulting command line the arguments provided by xargs go.
If all xarg-provided arguments go last, there is no need to use -J at all.

^{For the sake of completeness: eval can also be used to parse quoted strings embedded in another string, but eval is a security risk: arbitrary commands could end up getting executed; given the safe solutions discussed above, there is no need to use eval.}

^{Finally, Charles Duffy mentions another safe alternative in a comment, which, however, requires more coding: encapsulate the command to invoke in a shell function, pass the variable arguments as separate arguments to the function, then manipulate the all-arguments array $@ inside the function to supplement the fixed arguments (using set), and invoke the command with "$@".}

Explanation of the shell's string-handling issues involved:

• When you assign a string to a variable, embedded quote characters become part of the string:

  var='one "two three" *' 
  

• $var now literally contains one "two three" *, i.e., the following 4 - instead of the intended 3 - words, separated by a space each:

  • one
  • "two-- " is part of the word itself!
  • three"-- " is part of the word itself!
  • *

• When you use $var unquoted as part of an argument list, the above breakdown into 4 words is exactly what the shell does initially - a process called word splitting. ^{Note that if you were to double-quote the variable reference ("$var"), the entire string would always become a single argument.}

  • Because $var is expanded to its value, one of the so-called parameter expansions, the shell does NOT attempt to recognize embedded quotes inside that value as marking argument boundaries - this only works with quote characters specified literally, as a direct part of the command line (assuming these quote characters aren't themselves quoted).
  • Similarly, only such directly specified quote characters are removed by the shell before passing the enclosed string to the command being invoked - a process called quote removal.

• However, the shell additionally applies pathname expansion (globbing) to the resulting 4 words, so any of the words that happen to match filenames will expand to the matching filenames.

• In short: the quote characters in $var's value are neither recognized as argument-boundary delimiters nor are they removed after parsing. Additionally, the words in $var's value are subject to pathname expansion.

• This means that the only way to pass multiple arguments is to leave them unquoted inside the variable value (and also leave the reference to that variable unquoted), which:

  • won't work with values with embedded spaces or shell metacharacters
  • invariably subjects the values to pathname expansion