It always seemed to me that these utils are siblings.
All they do are that substitute values for variables, rearrange the parameters, and confuse the input with the output. 
I tried to display their main signature in table together. To show their similarities
Shell evaluation is done automatically, by the shell, before a command is run. None of these except eval do shell evaluation; eval can do so because it's actually part of the shell!
By the same ticket, ls abc* is not a feature of ls. abc* gets evaluated by the shell before ls is executed.
I'm not sure what your >stdin stdin> are about. eval does not use stdin or stdout especially, unless the command it's evaluating does. It has no limits at all. That's what makes it dangerous.
One unique feature of xargs is that it parses single and double quotes. Usually this is considered an annoyance and worked around, but this can be used to your advantage, i.e. to split strings containing quotes without resorting to eval.
1 Like
Thanks @Corona688,
stdin> this is the shell stdin
I was hoping that it would be clear from the context that the stdin> is the entrance to the shell. I guess I need to work on the design of the presentation.
It seemed to me funny, for example, "echo" and "eval" commands. Both commands take parameters and do the same work. Only the first returns a string of them to the stdout and the second command to the stdin (shell stdin).
I'v added the feature of Xargs, above noted to my notes.
Sorry, but this is based on a misconception of what eval does. eval has no output at all, not even to the input of the current shell.
When the shell reads an input line (that might be a commandline entered by the user or a line of code from a script being executed) it starts to interpret (or "decode") this line in a process of several fixed stages. One of these steps is - for example - the replacement of wildcard-expressions by a list of filenames fitting that wildcard-expression, another step is the replacement of variable names by their respective content.
The process goes like this: you enter i.e.
ls file*
and let us say there are three files which filenames start with "file". So the shell, when doing the respective stage, replaces the wildcard with the respective filelist:
ls fileA fileB fileC
Note that nothing is exeuted yet, the shell was just "cooking" the command line. Only now the result of this "cooking" is presented to the ls command. For ls there is no noticeable difference between these two forms of commands. For the same reason this is a scripting error:
if [ -r file* ] ; then
Because the command (here the test -command or its equivalent [ ) will never see "file*" but only the list the shell creates from that and obviously in
if [ -r fileA fileB fileC ] ; then
after the workable "-r fileA" (is fileA readable?) there are two filenames test simply doesn't know what to do with.
Now, after this, what does eval do? It restarts the process of evaluating the command line so that the already done stages are done a second time. Where would one need that? For instance, when replacing variables with their content you can do:
var1="one"
var2="two"
x="1"
echo $var1
but you cannot do:
echo $var$x
because all variables are replaced at the same time and you would need to first replace "$x" with "1" and only then replace the resulting "$var1" with "one". You can do this with eval , though, because this way you get two stages of "variable replacement" and you can (with the help of escaping) put them in the necessary order:
eval echo \$var$x
The shell will do the following: the first "\$var" will not be expanded, because the escaped "$" will make it a ordinary character and hence "$var" is simply a string, not a variable. The "$x" is expanded, though, and replaced by a "1":
eval echo $var1
Now the "eval" makes the shell interpret it again and in the next variable replacement stage it will recognise the "$var1" as a now legal variable name and this time expand it:
echo one
I hope this helps.
bakunin
2 Likes