Hello, I am making a script which looks for a field in a text file and assigns it to a variable, for example:
1:23:34:45:45:banner "hola" | write userx pts/x
As you can see, the sixth field corresponds to the command I want to execute. I use the following command for the assingment:

command=`awk -F: '{print $6} file'`

As a result the variable command is correctly assigned the value:
banner "hola" | write userx pts/x
I try to execute it on the script with the following instruction:
$command
But the shell only executes the banner command, wich takes as an argument the rest of the value of command variable, printing a banner with the string " hola | write userx pts/x ", instead of passing the ouput of the banner "hola" command to the command write userx pts/x, to send it to userx. I have tried using "$command", but it doesn´t work either. If the command doesn´t have pipes, it works ok.
I am using Red Hat Linux.
Thanks for the help.

Shell meta characters are not interpreted inside quotes when executed directly. Try:

Thanks for your help. It worked fine.

This isn't quite correct. Redirection and pipes are done before parameter expansion, but file name expansion is still performed:

As you can see, the shell did not perform pathname expansion inside the single quotes, but it did perform parameter expansion, and then file name expansion (wildcarding) and then command execution.

The important point here is knowing the order of command line expansion.

Zsh doesn't do that:

edit:
In zsh, you would do it like so:

I'm not sure what point you are making. I was making a point about expansion order of bash command lines.

My point was just that I don't know about expansion of bash command lines since I don't use it, thus your statement:

is incomplete since it is shell dependent (and you did not specify a particular shell).

I think we can assume standard defaults unless otherwise indicated. zsh is pretty fringe.

I don't see your point. I'm simply pointing out that bash's behaviour is not universal, as was your implication.

This is silly. I've made my point clear: "The important point here is knowing the order of command line expansion."

But the order is not relevent for the OPs problem. I see your point that wildcards are not expanded upon assignment, only when the parameter is dereferenced, but that does not affect the pipe character, since it is not related to expansion. In order for the | to be handled properly within quotes, one must use eval.

I also don't follow this, all expansion must be done before any pipeline/redirection.

I'll try to make clear.

You said: "Shell meta characters are not interpreted inside quotes when executed directly."
I say: This is not correct - some meta chars ARE interpreted inside (double) quotes when executed directly.

No, I'm saying the shell parses a command line for pipes and redirection symbols *before* any other type of expansion. The command line is then expanded next. This is why pipe and redirection is not subject to parameter expansion, while file name expansion is.

Sorry, I was a bit sleep deprived the other day (I should probably refrain from posting when I haven't slept for 24+ hours), I think I went off on a bit of a tangent. I'd forgotten that most shells do filename globbing in parameter expansion (as mentioned, zsh doesn't do this by default, though there's an option to enable it).

Ah, parsing, I'm with you now (I was a bit confused when you said 'order of expansion', since pipes/redirections are not related to expansion). You mean the shell parses the command line and builds the syntax tree, registering any redirections along the way, then it traverses the syntax tree, performing any expansion/substitution. Gotcha.

Thus, e.g.

parses as a single "word", hence no redirection is indicated in the syntax tree. And since the shell performs filename matching in parameter expansion, it expands the '*' when you dereference the variable, but the '>' is not treated specially at the execution stage.