What's the difference between eval and exec?
eval and exec are completely different beasts. (Apart from the fact that both will run commands, but so does everything you do in a shell.)
$ help exec
exec: exec [-cl] [-a name] [command [arguments ...]] [redirection ...]
Replace the shell with the given command.
What exec cmd does, is exactly the same as just running cmd, except that the current shell is replaced with the command, instead of a separate process being run. Internally, running say /bin/ls will call fork() to create a child process, and then exec() in the child to execute /bin/ls. exec /bin/ls on the other hand will not fork, but just replaces the shell.
Compare:
$ bash -c 'echo $$ ; ls -l /proc/self ; echo foo'
7218
lrwxrwxrwx 1 root root 0 Jun 30 16:49 /proc/self -> 7219
foo
with
$ bash -c 'echo $$ ; exec ls -l /proc/self ; echo foo'
7217
lrwxrwxrwx 1 root root 0 Jun 30 16:49 /proc/self -> 7217
echo $$ prints the PID of the shell I started, and listing /proc/self gives us the PID of the ls that was ran from the shell. Usually, the process IDs are different, but with exec the shell and ls have the same process ID. Also, the command following exec didn't run, since the shell was replaced.
On the other hand:
$ help eval
eval: eval [arg ...]
Execute arguments as a shell command.
eval will run the arguments as a command in the current shell. In other words eval foo bar is the same as just foo bar. But variables will be expanded before executing, so we can execute commands saved in shell variables:
$ unset bar
$ cmd="bar=foo"
$ eval "$cmd"
$ echo "$bar"
foo
It will not create a child process, so the variable is set in the current shell. (Of course eval /bin/ls will create a child process, the same way a plain old /bin/ls would.)
Or we could have a command that outputs shell commands. Running ssh-agent starts the agent in the background, and outputs a bunch of variable assignments, which could be set in the current shell and used by child processes (the ssh commands you would run). Hence ssh-agent can be started with:
eval $(ssh-agent)
And the current shell will get the variables for other commands to inherit.
Of course, if the variable cmd happened to contain something like rm -rf $HOME, then running eval "$cmd" would not be something you'd want to do. Even things like command substitutions inside the string would be processed, so one should really be sure that the input to eval is safe before using it.
Often, it's possible to avoid eval and avoid even accidentally mixing code and data in the wrong way.
exec does not create a new process. It replaces the current process with the new command. If you did this on the command line then it will effectively end your shell session (and maybe log you out or close the terminal window!)
e.g.
ksh% bash
bash-4.2$ exec /bin/echo hello
hello
ksh%
Here I'm in ksh (my normal shell). I start bash and then inside bash I exec /bin/echo. We can see that I've been dropped back into ksh afterwards because the bash process was replace by /bin/echo.
TL;DR
exec is used to replace current shell process with new and handle stream redirection/file descriptors if no command has been specified. eval is used to evaluate strings as commands. Both may be used to built up and execute a command with arguments known at run-time, but exec replaces process of the current shell in addition to executing commands.
exec buil-in
Syntax:
exec [-cl] [-a name] [command [arguments]]
According to the manual if there is command specified this built-in
...replaces the shell. No new process is created. The arguments become the arguments to command.
In other words, if you were running bash with PID 1234 and if you were to run exec top -u root within that shell, the top command will then have PID 1234 and replace your shell process.
Where is this useful ? In something known as wrapper scripts. Such scripts build up sets of arguments or make certain decisions about what variables to pass into environment, and then use exec to replace itself with whatever command is specified, and of course providing those same arguments that the wrapper script has built up along the way.
What the manual also states is that:
If command is not specified, any redirections take effect in the current shell
This allows us to redirect anything from current shells output streams into a file. This may be useful for logging or filtering purposes, where you don't want to see stdout of commands but only stderr. For instance, like so:
bash-4.3$ exec 3>&1
bash-4.3$ exec > test_redirect.txt
bash-4.3$ date
bash-4.3$ echo "HELLO WORLD"
bash-4.3$ exec >&3
bash-4.3$ cat test_redirect.txt
2017年 05月 20日 星期六 05:01:51 MDT
HELLO WORLD
This behavior makes it handy for logging in shell scripts, redirecting streams to separate files or processes, and other fun stuff with file descriptors.
On the source code level at least for bash version 4.3, the exec built in is defined in builtins/exec.def. It parses the received commands, and if there are any, it passes things on to shell_execve() function defined in execute_cmd.c file.
Long story short, there exists a family of exec commands in C programming language, and shell_execve() is basically a wrapper function of execve:
/* Call execve (), handling interpreting shell scripts, and handling
exec failures. */
int
shell_execve (command, args, env)
char *command;
char **args, **env;
{
eval built-in
The bash 4.3 manual states(emphasis added by me):
The args are read and concatenated together into a single command. This command is then read and executed by the shell, and its exit status is returned as the value of eval.
Note that there is no process replacement occurring. Unlike exec where the goal is to simulate execve() functionality, the eval built in only serves to "evaluate" arguments, just as if the user has typed them on the command line. As such, new processes are created.
Where this might be useful ? As Gilles pointed out in this answer , "...eval is not used very often. In some shells, the most common use is to obtain the value of a variable whose name is not known until runtime". Personally, I've used it in couple of scripts on Ubuntu where it was necessary to execute/evaluate a command based on the specific workspace that the user was currently using.
On the source code level, it is defined in builtins/eval.def and passes the parsed input string to evalstring() function.
Among other things, eval can assign variables which remain in current shell execution environment, while exec cannot:
$ eval x=42
$ echo $x
42
$ exec x=42
bash: exec: x=42: not found