1

The command:

( echo 1 )

works fine when I input it in the command line but if I store it as a variable and call it, it gives the error:

(echo: command not found

Code:

input="( echo 1 )"
$input

Why doesn't it evaluate the parentheses the same way and put it into a subshell when I call it this way?

gniourf_gniourf
  • 44,650
  • 9
  • 93
  • 104
Tony Nelson
  • 11
  • 2
  • 1
    See [BashFAQ #50](http://mywiki.wooledge.org/BashFAQ/050). An unquoted expansion only goes through two stages of parsing (field-splitting and glob expansion); this is true for very good reasons (it would be much harder to write secure code in bash otherwise). The linked FAQ goes into substantial detail, including discussion of best-practices for cases where you might otherwise want to store code in a variable. – Charles Duffy Sep 14 '16 at 17:05
  • 4
    You can't put such commands in a variable. In fact, putting commands in variables is prone to failure. Variables hold _data_, not _commands!_ if you want to store commands somewhere for future use, use a _function._ – gniourf_gniourf Sep 14 '16 at 17:06
  • 2
    BTW, your code and your error don't line up. You'd be getting `(: command not found` if you used the exact code given here. Do be sure to actually copy/paste the code in your question *exactly as asked* to avoid such situations in the future, in cases where those differences might actually matter. – Charles Duffy Sep 14 '16 at 17:08

2 Answers2

2

This is discussed in full detail in BashFAQ #50.

An unquoted expansion goes through only two stages of shell parsing: Field-splitting, and glob expansion. Thus, ( echo 1 ) is first split into fields: (, echo, 1, and ); each is expanded as a glob (moot, as none of them are glob expansions); and then they're run as a command: ( is invoked, with the first argument echo, the second argument 1, and the third argument ).

The Right Way to store code is in a function:

# best-practices approach
input() ( echo 1; )
input

...or, if you want to make it more explicit to a human reader that you really want a subshell and weren't using parens rather than braces by error or habit:

# same, but more explicit about intent
input() { (echo 1); }
input

...if not possible, one can use eval (but be wary of the caveats given in BashFAQ #48):

# avoid this approach if at all possible
input="( echo 1 )"
eval "$input"

If the real reason you're building a command in a string is to parameterize its contents, use an array instead:

input_args=( 1 )                    # define an array
input() ( echo "${input_args[@]}" ) # use that array in a function (if needed)

# add things according to conditional logic as appropriate
if (( 2 > 1 )); then
  input_args+=( "possible argument here" )
fi

# call the function, or just use the array directly, such as: (echo "$(input_args[@]}" )
input
Charles Duffy
  • 280,126
  • 43
  • 390
  • 441
0

The parentheses are shell syntax.

To reflect syntax which is stored in variable back into the shell for processing, you must use the eval command.

Merely interpolating the value of the variable into a command line doesn't trigger eval evaluation of the syntax. That would be an unwanted intrusion of eval, which would cause all sorts of problems.

For instance, consider this:

arg="(parenthesized)"
somecommand $arg

We just want somecommand to be invoked with the character string (parenthesized) as its argument; we don't want to run a subshell. That sort of implicit eval would turn harmless data into live code, creating a security hole, not to mention a coding nightmare to try to avoid it.

The rules for how $arg is treated are independent of position; the expansion happens the same way even if $arg is the first element in the command line:

$arg foo

Parameter substitution turns $arg into the text (parenthesized) and then that is tried as a command, not as a shell syntax.

To execute the piece of shell script stored in input, use:

eval "$input"

You could also do it like this:

input="echo 1"       # no parentheses

/bin/sh -c "$input"  # run in subshell explicitly

Of course, the subshell approach feeds the code fragment to the same shell which is executing the surrounding script, whereas here we chose the /bin/sh which could be different from the invoking shell, or have a different behavior even if it is a symlink to the same shell.

Kaz
  • 55,781
  • 9
  • 100
  • 149