how to store a command in a variable
 

Hiiiiiiiii,

Well, everybody knows the output of
Again the command can be stored in a variable and then executed. Like
The above two codes are the same.

The problem occurs when we try to pipeline it. Consider the following problem:
works fine...but when we try to store it in a variable and run the command there is an error.
So can anybody tell how to store this kind of commands in a variable????

EDIT: The following is NOT what you're looking for:



. . . of the top of my head. ;)

but then var actually stores the result of
I want var to store the command.

Single quotes, not backtics...

With backtics you get the complete output from running the command.

And then to execute it:

And to use literal asterisks escape them using a backslash, e.g.

Gah!

Eval is a common misspelling of "evil". Don't use it if you don't know what you are doing, and even then it's probably a sign that you're Doing Something Wrong.

This topic has been covered by BashFAQ in depth:
http://mywiki.wooledge.org/BashFAQ/050

Also, what is it you're really trying to do? I really can't seriously think that it's an ls+grep, but if it is, you shouldn't try to do anything with the output of ls. Parsing ls is *extremely* error-prone.

Honestly that's quite exaggerated. Eval is not that dangerous if you really know how eval and word splitting in variables works, and when to place arguments inside double quotes when already needed. Variable testers like [[ -n ... ]] and [[ -z ... ]] in complicated situations might also be helpful.

Not really. Slip up just a little bit and you've got a vulnerability, and there's lots of hidden gotchas in using eval. Word splitting is only the beginning of how things can go badly. Every time I need to write an eval, I triple-check, and then check it 3 more times while I'm sleeping every night. Almost every time you think about reaching for eval, seriously consider if you need to change your approach.
http://mywiki.wooledge.org/BashFAQ/048

eval can't be worse than the shell itself: you wouldn't want an outsider in your shell, just as you wouldn't want to eval a line with a variable containing an outsider's text. Other than that, the main vulnerability is the possibility of using special characters where only text was intended, but you wouldn't use eval in that case. Additionally, the same vulnerabilities can be said for a line like this, but people don't rant about the vulnerabilities of ``:Kevin Barry

The reason for the ranting about eval is because of how much is now "outsider's text". With $(), it's easy to see what you're executing and there's no possibility of any strange results. With eval, depending on how paranoidly it's constructed, you can easily cause the one who used eval to run something they didn't expect by perhaps creating a file with an interesting filename in /tmp.

Using eval safely requires extreme levels of paranoia, and if you're that paranoid, you're going to just avoid it entirely because you can't be paranoid enough to completely guarantee bad things from happening.

No I don't think so. It's just as simple as re-evaluating a string for a command so no I don't think you need to be paranoid for that. Just common sense.

Edit: Applying a sed command with variables inside double quotes could prove even more complicated (although still simple) or more delicate than using eval.