eval and exec are both built in commands of bash(1) that execute commands.

I also see exec has a few options but is that the only difference? What happens to their context?


5 Answers 5


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.


$ bash -c 'echo $$ ; ls -l /proc/self ; echo foo'
lrwxrwxrwx 1 root root 0 Jun 30 16:49 /proc/self -> 7219


$ bash -c 'echo $$ ; exec ls -l /proc/self ; echo foo'
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"

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.

  • More details about usage of eval can be found here: stackoverflow.com/a/46944004/2079103
    – clearlight
    Commented Nov 14, 2017 at 15:06
  • 1
    @clearlight, well, that reminds me to add the usual disclaimer about not using eval in the first place to this answer too. Stuff like indirectly modifying variables can be done in many shells through declare/typeset/nameref and expansions like ${!var}, so I would use those instead of eval unless I really had to avoid it.
    – ilkkachu
    Commented Nov 14, 2017 at 18:02
  • +1 for the good explanation with focus about some important points. Thank you!
    – bitfox
    Commented Mar 20, 2020 at 19:27
  • is this question the same as: what is the difference between eval and $(...)? Commented Jun 8, 2022 at 14:16
  • 1
    @CharlieParker, no, the command substitution $(...) is a yet another thing, different from eval and exec. Of course that one, also, runs a command...
    – ilkkachu
    Commented Jun 8, 2022 at 15:04

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!)


ksh% bash
bash-4.2$ exec /bin/echo hello

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.

  • umm on the face dropped back into ksh b/c process was replaced by echo doesnt make that much sense?
    – user282164
    Commented May 31, 2019 at 3:35
  • is this question the same as: what is the difference between eval and $(...)? Commented Jun 8, 2022 at 14:16


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


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

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. */
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
$ exec x=42
bash: exec: x=42: not found
  • @ctrl-alt-delor I've edited that part, thanks, though arguably it does spawn a new process, the PID merely remains the same as of current shell. In future consider editing answers, instead of leaving a comment and downvote , especially where such minor thing as 7-word phrase is in question; it's far less time consuming to edit and correct an answer, and it's far more helpful. Commented May 5, 2019 at 17:02
creating a new child process, run the arguments and returning the exit status.

Uh what? The whole point of eval is that it does not in any way create a child process. If I do

eval "cd /tmp"

in a shell, then afterwards the current shell will have changed directory. Neither does exec create a new child process, instead it changes the current executable (namely the shell) for the given one; the process id (and open files and other stuff) stay the same. As opposed to eval, an exec will not return to the calling shell unless the exec itself fails due to being unable to find or load the executable or die to argument expansion problems.

eval basically interprets its argument(s) as a string after concatenation, namely it will do an extra layer of wildcard expansion and argument splitting. exec doesn't do anything like that.

  • 1
    The original question read "eval and exec are both builtin commands of Bash (1) and executes commands, creating a new child process, run the arguments and returning the exit status"; I've edited out the false presumption. Commented Jul 20, 2016 at 15:22


These work:

$ echo hi

$ eval "echo hi"

$ exec echo hi

However, these do not:

$ exec "echo hi"
bash: exec: echo hi: not found

$ "echo hi"
bash: echo hi: command not found

Process image replacement

This example demonstrates how exec replaces the image of its calling process:

# Get PID of current shell
sh$ echo $$

# Enter a subshell with PID 5678
sh$ sh

# Check PID of subshell
sh-subshell$ echo $$

# Run exec
sh-subshell$ exec echo $$

# We are back in our original shell!
sh$ echo $$

Notice that exec echo $$ ran with the PID of the subshell! Furthermore, after it was complete, we were back in our original sh$ shell.

On the other hand, eval does not replace the process image. Rather, it runs the given command as you would normally within the shell itself. (Of course, if you run a command that requires a process to be spawned... it does just that!)

sh$ echo $$

sh$ sh

sh-subshell$ echo $$

sh-subshell$ eval echo $$

# We are still in the subshell!
sh-subshell$ echo $$
  • I posted this answer because the other examples didn't really illustrate this in a sufficiently comprehensible way for feeble minds such as I. Commented Jul 29, 2019 at 3:58
  • Poor choice of words: Process substitution is an existing concept that seems to be unrelated to whatever you're illustrating here.
    – muru
    Commented Jul 29, 2019 at 4:33
  • @muru Is "process replacement" better? I'm not sure what the correct terminology is. The manpage seems to call it "replacing the process image". Commented Jul 29, 2019 at 4:38
  • Hmm, dunno. (But when I hear "replacing the process image", I think: exec)
    – muru
    Commented Jul 29, 2019 at 5:04

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .