What does an “exec” command do?
I don't understand the bash command exec
. I have seen it used inside scripts to redirect all output to a file (as seen in this). But I don't understand how it works or what it does in general. I have read the man pages but I don't understand them.
bash
|
show 2 more comments
I don't understand the bash command exec
. I have seen it used inside scripts to redirect all output to a file (as seen in this). But I don't understand how it works or what it does in general. I have read the man pages but I don't understand them.
bash
Are you familiar with whar a process is?
– fkraiem
Sep 18 '14 at 21:18
1
@fkraiem what do you mean?
– becko
Sep 18 '14 at 21:28
Sorry I meant "what". :p But the answer seems to be no.
– fkraiem
Sep 18 '14 at 21:47
But actually your script usesexec
in a special way which can be explained much more simply, I will write an answer.
– fkraiem
Sep 18 '14 at 21:51
1
Related: unix.stackexchange.com/q/296838/85039
– Sergiy Kolodyazhnyy
Jul 7 '17 at 6:31
|
show 2 more comments
I don't understand the bash command exec
. I have seen it used inside scripts to redirect all output to a file (as seen in this). But I don't understand how it works or what it does in general. I have read the man pages but I don't understand them.
bash
I don't understand the bash command exec
. I have seen it used inside scripts to redirect all output to a file (as seen in this). But I don't understand how it works or what it does in general. I have read the man pages but I don't understand them.
bash
bash
edited Aug 31 '16 at 11:54
AzkerM
7,98242146
7,98242146
asked Sep 18 '14 at 21:12
beckobecko
3,365144179
3,365144179
Are you familiar with whar a process is?
– fkraiem
Sep 18 '14 at 21:18
1
@fkraiem what do you mean?
– becko
Sep 18 '14 at 21:28
Sorry I meant "what". :p But the answer seems to be no.
– fkraiem
Sep 18 '14 at 21:47
But actually your script usesexec
in a special way which can be explained much more simply, I will write an answer.
– fkraiem
Sep 18 '14 at 21:51
1
Related: unix.stackexchange.com/q/296838/85039
– Sergiy Kolodyazhnyy
Jul 7 '17 at 6:31
|
show 2 more comments
Are you familiar with whar a process is?
– fkraiem
Sep 18 '14 at 21:18
1
@fkraiem what do you mean?
– becko
Sep 18 '14 at 21:28
Sorry I meant "what". :p But the answer seems to be no.
– fkraiem
Sep 18 '14 at 21:47
But actually your script usesexec
in a special way which can be explained much more simply, I will write an answer.
– fkraiem
Sep 18 '14 at 21:51
1
Related: unix.stackexchange.com/q/296838/85039
– Sergiy Kolodyazhnyy
Jul 7 '17 at 6:31
Are you familiar with whar a process is?
– fkraiem
Sep 18 '14 at 21:18
Are you familiar with whar a process is?
– fkraiem
Sep 18 '14 at 21:18
1
1
@fkraiem what do you mean?
– becko
Sep 18 '14 at 21:28
@fkraiem what do you mean?
– becko
Sep 18 '14 at 21:28
Sorry I meant "what". :p But the answer seems to be no.
– fkraiem
Sep 18 '14 at 21:47
Sorry I meant "what". :p But the answer seems to be no.
– fkraiem
Sep 18 '14 at 21:47
But actually your script uses
exec
in a special way which can be explained much more simply, I will write an answer.– fkraiem
Sep 18 '14 at 21:51
But actually your script uses
exec
in a special way which can be explained much more simply, I will write an answer.– fkraiem
Sep 18 '14 at 21:51
1
1
Related: unix.stackexchange.com/q/296838/85039
– Sergiy Kolodyazhnyy
Jul 7 '17 at 6:31
Related: unix.stackexchange.com/q/296838/85039
– Sergiy Kolodyazhnyy
Jul 7 '17 at 6:31
|
show 2 more comments
4 Answers
4
active
oldest
votes
man bash
says:
exec [-cl] [-a name] [command [arguments]]
If command is specified, it replaces the shell. No new process
is created. The arguments become the arguments to command. If
the -l option is supplied, the shell places a dash at the
beginning of the zeroth argument passed to command. This is
what login(1) does. The -c option causes command to be executed
with an empty environment. If -a is supplied, the shell passes
name as the zeroth argument to the executed command. If command
cannot be executed for some reason, a non-interactive shell
exits, unless the execfail shell option is enabled. In that
case, it returns failure. An interactive shell returns failure
if the file cannot be executed. If command is not specified,
any redirections take effect in the current shell, and the
return status is 0. If there is a redirection error, the return
status is 1.
The last two lines are what is important: If you run exec
by itself, without a command, it will simply make the redirections apply to the current shell. You probably know that when you run command > file
, the output of command
is written to file
instead of to your terminal (this is called a redirection). If you run exec > file
instead, then the redirection applies to the entire shell: Any output produced by the shell is written to file
instead of to your terminal. For example here
bash-3.2$ bash
bash-3.2$ exec > file
bash-3.2$ date
bash-3.2$ exit
bash-3.2$ cat file
Thu 18 Sep 2014 23:56:25 CEST
I first start a new bash
shell. Then, in this new shell I run exec > file
, so that all output is redirected to file
. Indeed, after that I run date
but I get no output, because the output is redirected to file
. Then I exit my shell (so that the redirection no longer applies) and I see that file
indeed contains the output of the date
command I ran earlier.
32
This is only partial explanation.exec
serves to also replace current shell process with a command, so that parent goes a way and child owns pid. This is not only for redirection. Please add this info
– Sergiy Kolodyazhnyy
Aug 31 '16 at 13:23
1
Following up on @SergiyKolodyazhnyy's comment, the example I've just encountered which led me to this page is a docker-entrypoint.sh, where after performing various actions on the nginx config, the final line of the script isexec nginx <various nginx arguments>
. This means that nginx takes over the pid of the bash script and now nginx is the main running process of the container, not the script. I assume this is just for cleanliness, unless someone else knows a more concrete reason for it?
– Luke Griffiths
Nov 21 '18 at 19:56
1
@Luke This is called "wrapper script". Example of that is alsognome-terminal
, which at least on 14.04 had a wrapper script to set up arguments. And that's their only purpose, really - set arts and environment. Another case would be to clean up - kill previous instance of a process first and launch new one
– Sergiy Kolodyazhnyy
Nov 21 '18 at 20:18
anotherexec
example similar to thenginx
example given by @LukeGriffiths is the~/.vnc/xstartup
script whichvncserver
uses to configure a VNC server process and thenexec gnome-session
orexec startkde
and so on.
– Trevor Boyd Smith
Jan 22 at 13:57
@LukeGriffiths, the main reason forexec
in a container startup script is that the PID 1, the container's ENTRYPOINT, has a special significance in Docker. It is a main process that receives signals, and when it exists, the container exits too.exec
just a way to takesh
out of this chain of command, and make the daemon the main process of the container.
– kkm
Feb 13 at 22:39
add a comment |
exec
is a command with two very distinct behaviors, depending on whether at least one argument is used with it, or no argument is used at all.
If at least one argument is passed, the first one is taken as a command name and
exec
try to execute it as a command passing the remaining arguments, if any, to that command and managing the redirections, if any.If the command passed as first argument doesn't exist, the current shell, not only the exec command, exits in error.
If the command exists and is executable, it replaces the current shell. That means that if
exec
appears in a script, the instructions following the exec call will never be executed (unlessexec
is itself in a subshell).exec
never returns. Shell traps like "EXIT" won't get triggered either.If no argument is passed,
exec
is only used to redefine the current shell file descriptors. The shell continue after theexec
, unlike with the previous case, but the standard input, output, error or whatever file descriptor has been redirected take effect.If some of the redirections uses
/dev/null
, any input from it will return EOF and any output to it will be discarded.You can close file descriptors by using
-
as source or destination, e.g.exec <&-
. Subsequent read or writes will then fail.
Here are two examples:
echo foo > /tmp/bar
exec < /tmp/bar # exec has no arguments, will only affect current shell descriptors, here stdin
cat # simple command that read stdin and write it to stdout
This script will output "foo" as the cat command, instead of waiting for user input as it would have done in the usual case will take its input from the /tmp/bar file which contains foo.
echo foo > /tmp/bar
exec wc -c < /tmp/bar # exec has two arguments, the control flow will switch to the wc command
cat
This script will display 4
(the number of bytes in /tmp/bar) and immediately ends. The cat
command won't be executed.
4
`Some old posts never really get old ... +1.
– Cbhihe
Mar 23 '17 at 11:33
3
If some of the redirections uses /dev/null, the associated file descriptor is closed. No, it really does redirect to/from/dev/null
, so writes still succeed and reads return EOF.close(2)
on an fd would cause read/write system calls to return errors, and you do that withexec 2>&-
for example.
– Peter Cordes
Jul 7 '17 at 2:59
2
Try it yourself:exec 3</dev/null;
ls -l /proc/self/fd
: note that fd 3 will be open read-only on /dev/null. Then close it again withexec 3<&-
, and you can see (withls -l /proc/$$/fd
again) that your shell process has no fd 3 anymore. (closing stdin withexec <&-
can be useful in scripts, but interactively it's a logout.)
– Peter Cordes
Jul 7 '17 at 3:01
@PeterCordes You are absolutely right. Answer updated. Thanks!
– jlliagre
Jul 7 '17 at 5:43
1
This answer is great because it explains the two use-cases ofexec
the current most-upvoted answer only talks about the one use-case and the other answer by g_p only talks about the other use-case. And this answer is nice and concise/readable for such a complex subject matter.
– Trevor Boyd Smith
Jan 22 at 14:09
|
show 1 more comment
To understand exec
you need to first understand fork
. I am trying to keep it short.
When you come to a fork in the road you generally have two options. Linux programs reach this fork in the road when they hit a
fork()
system call.Normal programs are system commands that exist in a compiled form on
your system. When such a program is executed, a new process is
created. This child process has the same environment as its parent,
only the process ID number is different. This procedure is called
forking.- Forking provides a way for an existing process to start a new one. However,
there may be situations where a child process is not the part of the same
program as parent process. In this caseexec
is used.exec
will replace the contents of the currently running process with the
information from a program binary. - After the forking process, the address space of the child process is
overwritten with the new process data. This is done through an exec
call to the system.
3
can you explain whyexec
can redirect a script output, as in the link I posted?
– becko
Sep 18 '14 at 21:45
I found this unclear "However, there may be situations where a child process is not the part of the same program as parent process"
– cdosborn
Oct 15 '18 at 22:34
add a comment |
In bash
, if you do help exec
:
$ help exec
exec: exec [-cl] [-a name] [command [arguments ...]] [redirection ...]
Replace the shell with the given command.
Execute COMMAND, replacing this shell with the specified program.
ARGUMENTS become the arguments to COMMAND. If COMMAND is not specified,
any redirections take effect in the current shell.
Options:
-a name pass NAME as the zeroth argument to COMMAND
-c execute COMMAND with an empty environment
-l place a dash in the zeroth argument to COMMAND
If the command cannot be executed, a non-interactive shell exits, unless
the shell option `execfail' is set.
Exit Status:
Returns success unless COMMAND is not found or a redirection error occurs.
The relevant bit:
If COMMAND is not specified, any redirections take effect in the current shell.
exec
is a shell builtin, which is the shell equivalent of the exec
family of system calls that G_P speaks of (and whose manpages you appear to have read). It just has the POSIX mandated functionality of affecting the current shell if no command is specified.
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "89"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f525767%2fwhat-does-an-exec-command-do%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
man bash
says:
exec [-cl] [-a name] [command [arguments]]
If command is specified, it replaces the shell. No new process
is created. The arguments become the arguments to command. If
the -l option is supplied, the shell places a dash at the
beginning of the zeroth argument passed to command. This is
what login(1) does. The -c option causes command to be executed
with an empty environment. If -a is supplied, the shell passes
name as the zeroth argument to the executed command. If command
cannot be executed for some reason, a non-interactive shell
exits, unless the execfail shell option is enabled. In that
case, it returns failure. An interactive shell returns failure
if the file cannot be executed. If command is not specified,
any redirections take effect in the current shell, and the
return status is 0. If there is a redirection error, the return
status is 1.
The last two lines are what is important: If you run exec
by itself, without a command, it will simply make the redirections apply to the current shell. You probably know that when you run command > file
, the output of command
is written to file
instead of to your terminal (this is called a redirection). If you run exec > file
instead, then the redirection applies to the entire shell: Any output produced by the shell is written to file
instead of to your terminal. For example here
bash-3.2$ bash
bash-3.2$ exec > file
bash-3.2$ date
bash-3.2$ exit
bash-3.2$ cat file
Thu 18 Sep 2014 23:56:25 CEST
I first start a new bash
shell. Then, in this new shell I run exec > file
, so that all output is redirected to file
. Indeed, after that I run date
but I get no output, because the output is redirected to file
. Then I exit my shell (so that the redirection no longer applies) and I see that file
indeed contains the output of the date
command I ran earlier.
32
This is only partial explanation.exec
serves to also replace current shell process with a command, so that parent goes a way and child owns pid. This is not only for redirection. Please add this info
– Sergiy Kolodyazhnyy
Aug 31 '16 at 13:23
1
Following up on @SergiyKolodyazhnyy's comment, the example I've just encountered which led me to this page is a docker-entrypoint.sh, where after performing various actions on the nginx config, the final line of the script isexec nginx <various nginx arguments>
. This means that nginx takes over the pid of the bash script and now nginx is the main running process of the container, not the script. I assume this is just for cleanliness, unless someone else knows a more concrete reason for it?
– Luke Griffiths
Nov 21 '18 at 19:56
1
@Luke This is called "wrapper script". Example of that is alsognome-terminal
, which at least on 14.04 had a wrapper script to set up arguments. And that's their only purpose, really - set arts and environment. Another case would be to clean up - kill previous instance of a process first and launch new one
– Sergiy Kolodyazhnyy
Nov 21 '18 at 20:18
anotherexec
example similar to thenginx
example given by @LukeGriffiths is the~/.vnc/xstartup
script whichvncserver
uses to configure a VNC server process and thenexec gnome-session
orexec startkde
and so on.
– Trevor Boyd Smith
Jan 22 at 13:57
@LukeGriffiths, the main reason forexec
in a container startup script is that the PID 1, the container's ENTRYPOINT, has a special significance in Docker. It is a main process that receives signals, and when it exists, the container exits too.exec
just a way to takesh
out of this chain of command, and make the daemon the main process of the container.
– kkm
Feb 13 at 22:39
add a comment |
man bash
says:
exec [-cl] [-a name] [command [arguments]]
If command is specified, it replaces the shell. No new process
is created. The arguments become the arguments to command. If
the -l option is supplied, the shell places a dash at the
beginning of the zeroth argument passed to command. This is
what login(1) does. The -c option causes command to be executed
with an empty environment. If -a is supplied, the shell passes
name as the zeroth argument to the executed command. If command
cannot be executed for some reason, a non-interactive shell
exits, unless the execfail shell option is enabled. In that
case, it returns failure. An interactive shell returns failure
if the file cannot be executed. If command is not specified,
any redirections take effect in the current shell, and the
return status is 0. If there is a redirection error, the return
status is 1.
The last two lines are what is important: If you run exec
by itself, without a command, it will simply make the redirections apply to the current shell. You probably know that when you run command > file
, the output of command
is written to file
instead of to your terminal (this is called a redirection). If you run exec > file
instead, then the redirection applies to the entire shell: Any output produced by the shell is written to file
instead of to your terminal. For example here
bash-3.2$ bash
bash-3.2$ exec > file
bash-3.2$ date
bash-3.2$ exit
bash-3.2$ cat file
Thu 18 Sep 2014 23:56:25 CEST
I first start a new bash
shell. Then, in this new shell I run exec > file
, so that all output is redirected to file
. Indeed, after that I run date
but I get no output, because the output is redirected to file
. Then I exit my shell (so that the redirection no longer applies) and I see that file
indeed contains the output of the date
command I ran earlier.
32
This is only partial explanation.exec
serves to also replace current shell process with a command, so that parent goes a way and child owns pid. This is not only for redirection. Please add this info
– Sergiy Kolodyazhnyy
Aug 31 '16 at 13:23
1
Following up on @SergiyKolodyazhnyy's comment, the example I've just encountered which led me to this page is a docker-entrypoint.sh, where after performing various actions on the nginx config, the final line of the script isexec nginx <various nginx arguments>
. This means that nginx takes over the pid of the bash script and now nginx is the main running process of the container, not the script. I assume this is just for cleanliness, unless someone else knows a more concrete reason for it?
– Luke Griffiths
Nov 21 '18 at 19:56
1
@Luke This is called "wrapper script". Example of that is alsognome-terminal
, which at least on 14.04 had a wrapper script to set up arguments. And that's their only purpose, really - set arts and environment. Another case would be to clean up - kill previous instance of a process first and launch new one
– Sergiy Kolodyazhnyy
Nov 21 '18 at 20:18
anotherexec
example similar to thenginx
example given by @LukeGriffiths is the~/.vnc/xstartup
script whichvncserver
uses to configure a VNC server process and thenexec gnome-session
orexec startkde
and so on.
– Trevor Boyd Smith
Jan 22 at 13:57
@LukeGriffiths, the main reason forexec
in a container startup script is that the PID 1, the container's ENTRYPOINT, has a special significance in Docker. It is a main process that receives signals, and when it exists, the container exits too.exec
just a way to takesh
out of this chain of command, and make the daemon the main process of the container.
– kkm
Feb 13 at 22:39
add a comment |
man bash
says:
exec [-cl] [-a name] [command [arguments]]
If command is specified, it replaces the shell. No new process
is created. The arguments become the arguments to command. If
the -l option is supplied, the shell places a dash at the
beginning of the zeroth argument passed to command. This is
what login(1) does. The -c option causes command to be executed
with an empty environment. If -a is supplied, the shell passes
name as the zeroth argument to the executed command. If command
cannot be executed for some reason, a non-interactive shell
exits, unless the execfail shell option is enabled. In that
case, it returns failure. An interactive shell returns failure
if the file cannot be executed. If command is not specified,
any redirections take effect in the current shell, and the
return status is 0. If there is a redirection error, the return
status is 1.
The last two lines are what is important: If you run exec
by itself, without a command, it will simply make the redirections apply to the current shell. You probably know that when you run command > file
, the output of command
is written to file
instead of to your terminal (this is called a redirection). If you run exec > file
instead, then the redirection applies to the entire shell: Any output produced by the shell is written to file
instead of to your terminal. For example here
bash-3.2$ bash
bash-3.2$ exec > file
bash-3.2$ date
bash-3.2$ exit
bash-3.2$ cat file
Thu 18 Sep 2014 23:56:25 CEST
I first start a new bash
shell. Then, in this new shell I run exec > file
, so that all output is redirected to file
. Indeed, after that I run date
but I get no output, because the output is redirected to file
. Then I exit my shell (so that the redirection no longer applies) and I see that file
indeed contains the output of the date
command I ran earlier.
man bash
says:
exec [-cl] [-a name] [command [arguments]]
If command is specified, it replaces the shell. No new process
is created. The arguments become the arguments to command. If
the -l option is supplied, the shell places a dash at the
beginning of the zeroth argument passed to command. This is
what login(1) does. The -c option causes command to be executed
with an empty environment. If -a is supplied, the shell passes
name as the zeroth argument to the executed command. If command
cannot be executed for some reason, a non-interactive shell
exits, unless the execfail shell option is enabled. In that
case, it returns failure. An interactive shell returns failure
if the file cannot be executed. If command is not specified,
any redirections take effect in the current shell, and the
return status is 0. If there is a redirection error, the return
status is 1.
The last two lines are what is important: If you run exec
by itself, without a command, it will simply make the redirections apply to the current shell. You probably know that when you run command > file
, the output of command
is written to file
instead of to your terminal (this is called a redirection). If you run exec > file
instead, then the redirection applies to the entire shell: Any output produced by the shell is written to file
instead of to your terminal. For example here
bash-3.2$ bash
bash-3.2$ exec > file
bash-3.2$ date
bash-3.2$ exit
bash-3.2$ cat file
Thu 18 Sep 2014 23:56:25 CEST
I first start a new bash
shell. Then, in this new shell I run exec > file
, so that all output is redirected to file
. Indeed, after that I run date
but I get no output, because the output is redirected to file
. Then I exit my shell (so that the redirection no longer applies) and I see that file
indeed contains the output of the date
command I ran earlier.
edited Nov 29 '16 at 3:02
muru
1
1
answered Sep 18 '14 at 21:59
fkraiemfkraiem
9,04932031
9,04932031
32
This is only partial explanation.exec
serves to also replace current shell process with a command, so that parent goes a way and child owns pid. This is not only for redirection. Please add this info
– Sergiy Kolodyazhnyy
Aug 31 '16 at 13:23
1
Following up on @SergiyKolodyazhnyy's comment, the example I've just encountered which led me to this page is a docker-entrypoint.sh, where after performing various actions on the nginx config, the final line of the script isexec nginx <various nginx arguments>
. This means that nginx takes over the pid of the bash script and now nginx is the main running process of the container, not the script. I assume this is just for cleanliness, unless someone else knows a more concrete reason for it?
– Luke Griffiths
Nov 21 '18 at 19:56
1
@Luke This is called "wrapper script". Example of that is alsognome-terminal
, which at least on 14.04 had a wrapper script to set up arguments. And that's their only purpose, really - set arts and environment. Another case would be to clean up - kill previous instance of a process first and launch new one
– Sergiy Kolodyazhnyy
Nov 21 '18 at 20:18
anotherexec
example similar to thenginx
example given by @LukeGriffiths is the~/.vnc/xstartup
script whichvncserver
uses to configure a VNC server process and thenexec gnome-session
orexec startkde
and so on.
– Trevor Boyd Smith
Jan 22 at 13:57
@LukeGriffiths, the main reason forexec
in a container startup script is that the PID 1, the container's ENTRYPOINT, has a special significance in Docker. It is a main process that receives signals, and when it exists, the container exits too.exec
just a way to takesh
out of this chain of command, and make the daemon the main process of the container.
– kkm
Feb 13 at 22:39
add a comment |
32
This is only partial explanation.exec
serves to also replace current shell process with a command, so that parent goes a way and child owns pid. This is not only for redirection. Please add this info
– Sergiy Kolodyazhnyy
Aug 31 '16 at 13:23
1
Following up on @SergiyKolodyazhnyy's comment, the example I've just encountered which led me to this page is a docker-entrypoint.sh, where after performing various actions on the nginx config, the final line of the script isexec nginx <various nginx arguments>
. This means that nginx takes over the pid of the bash script and now nginx is the main running process of the container, not the script. I assume this is just for cleanliness, unless someone else knows a more concrete reason for it?
– Luke Griffiths
Nov 21 '18 at 19:56
1
@Luke This is called "wrapper script". Example of that is alsognome-terminal
, which at least on 14.04 had a wrapper script to set up arguments. And that's their only purpose, really - set arts and environment. Another case would be to clean up - kill previous instance of a process first and launch new one
– Sergiy Kolodyazhnyy
Nov 21 '18 at 20:18
anotherexec
example similar to thenginx
example given by @LukeGriffiths is the~/.vnc/xstartup
script whichvncserver
uses to configure a VNC server process and thenexec gnome-session
orexec startkde
and so on.
– Trevor Boyd Smith
Jan 22 at 13:57
@LukeGriffiths, the main reason forexec
in a container startup script is that the PID 1, the container's ENTRYPOINT, has a special significance in Docker. It is a main process that receives signals, and when it exists, the container exits too.exec
just a way to takesh
out of this chain of command, and make the daemon the main process of the container.
– kkm
Feb 13 at 22:39
32
32
This is only partial explanation.
exec
serves to also replace current shell process with a command, so that parent goes a way and child owns pid. This is not only for redirection. Please add this info– Sergiy Kolodyazhnyy
Aug 31 '16 at 13:23
This is only partial explanation.
exec
serves to also replace current shell process with a command, so that parent goes a way and child owns pid. This is not only for redirection. Please add this info– Sergiy Kolodyazhnyy
Aug 31 '16 at 13:23
1
1
Following up on @SergiyKolodyazhnyy's comment, the example I've just encountered which led me to this page is a docker-entrypoint.sh, where after performing various actions on the nginx config, the final line of the script is
exec nginx <various nginx arguments>
. This means that nginx takes over the pid of the bash script and now nginx is the main running process of the container, not the script. I assume this is just for cleanliness, unless someone else knows a more concrete reason for it?– Luke Griffiths
Nov 21 '18 at 19:56
Following up on @SergiyKolodyazhnyy's comment, the example I've just encountered which led me to this page is a docker-entrypoint.sh, where after performing various actions on the nginx config, the final line of the script is
exec nginx <various nginx arguments>
. This means that nginx takes over the pid of the bash script and now nginx is the main running process of the container, not the script. I assume this is just for cleanliness, unless someone else knows a more concrete reason for it?– Luke Griffiths
Nov 21 '18 at 19:56
1
1
@Luke This is called "wrapper script". Example of that is also
gnome-terminal
, which at least on 14.04 had a wrapper script to set up arguments. And that's their only purpose, really - set arts and environment. Another case would be to clean up - kill previous instance of a process first and launch new one– Sergiy Kolodyazhnyy
Nov 21 '18 at 20:18
@Luke This is called "wrapper script". Example of that is also
gnome-terminal
, which at least on 14.04 had a wrapper script to set up arguments. And that's their only purpose, really - set arts and environment. Another case would be to clean up - kill previous instance of a process first and launch new one– Sergiy Kolodyazhnyy
Nov 21 '18 at 20:18
another
exec
example similar to the nginx
example given by @LukeGriffiths is the ~/.vnc/xstartup
script which vncserver
uses to configure a VNC server process and then exec gnome-session
or exec startkde
and so on.– Trevor Boyd Smith
Jan 22 at 13:57
another
exec
example similar to the nginx
example given by @LukeGriffiths is the ~/.vnc/xstartup
script which vncserver
uses to configure a VNC server process and then exec gnome-session
or exec startkde
and so on.– Trevor Boyd Smith
Jan 22 at 13:57
@LukeGriffiths, the main reason for
exec
in a container startup script is that the PID 1, the container's ENTRYPOINT, has a special significance in Docker. It is a main process that receives signals, and when it exists, the container exits too. exec
just a way to take sh
out of this chain of command, and make the daemon the main process of the container.– kkm
Feb 13 at 22:39
@LukeGriffiths, the main reason for
exec
in a container startup script is that the PID 1, the container's ENTRYPOINT, has a special significance in Docker. It is a main process that receives signals, and when it exists, the container exits too. exec
just a way to take sh
out of this chain of command, and make the daemon the main process of the container.– kkm
Feb 13 at 22:39
add a comment |
exec
is a command with two very distinct behaviors, depending on whether at least one argument is used with it, or no argument is used at all.
If at least one argument is passed, the first one is taken as a command name and
exec
try to execute it as a command passing the remaining arguments, if any, to that command and managing the redirections, if any.If the command passed as first argument doesn't exist, the current shell, not only the exec command, exits in error.
If the command exists and is executable, it replaces the current shell. That means that if
exec
appears in a script, the instructions following the exec call will never be executed (unlessexec
is itself in a subshell).exec
never returns. Shell traps like "EXIT" won't get triggered either.If no argument is passed,
exec
is only used to redefine the current shell file descriptors. The shell continue after theexec
, unlike with the previous case, but the standard input, output, error or whatever file descriptor has been redirected take effect.If some of the redirections uses
/dev/null
, any input from it will return EOF and any output to it will be discarded.You can close file descriptors by using
-
as source or destination, e.g.exec <&-
. Subsequent read or writes will then fail.
Here are two examples:
echo foo > /tmp/bar
exec < /tmp/bar # exec has no arguments, will only affect current shell descriptors, here stdin
cat # simple command that read stdin and write it to stdout
This script will output "foo" as the cat command, instead of waiting for user input as it would have done in the usual case will take its input from the /tmp/bar file which contains foo.
echo foo > /tmp/bar
exec wc -c < /tmp/bar # exec has two arguments, the control flow will switch to the wc command
cat
This script will display 4
(the number of bytes in /tmp/bar) and immediately ends. The cat
command won't be executed.
4
`Some old posts never really get old ... +1.
– Cbhihe
Mar 23 '17 at 11:33
3
If some of the redirections uses /dev/null, the associated file descriptor is closed. No, it really does redirect to/from/dev/null
, so writes still succeed and reads return EOF.close(2)
on an fd would cause read/write system calls to return errors, and you do that withexec 2>&-
for example.
– Peter Cordes
Jul 7 '17 at 2:59
2
Try it yourself:exec 3</dev/null;
ls -l /proc/self/fd
: note that fd 3 will be open read-only on /dev/null. Then close it again withexec 3<&-
, and you can see (withls -l /proc/$$/fd
again) that your shell process has no fd 3 anymore. (closing stdin withexec <&-
can be useful in scripts, but interactively it's a logout.)
– Peter Cordes
Jul 7 '17 at 3:01
@PeterCordes You are absolutely right. Answer updated. Thanks!
– jlliagre
Jul 7 '17 at 5:43
1
This answer is great because it explains the two use-cases ofexec
the current most-upvoted answer only talks about the one use-case and the other answer by g_p only talks about the other use-case. And this answer is nice and concise/readable for such a complex subject matter.
– Trevor Boyd Smith
Jan 22 at 14:09
|
show 1 more comment
exec
is a command with two very distinct behaviors, depending on whether at least one argument is used with it, or no argument is used at all.
If at least one argument is passed, the first one is taken as a command name and
exec
try to execute it as a command passing the remaining arguments, if any, to that command and managing the redirections, if any.If the command passed as first argument doesn't exist, the current shell, not only the exec command, exits in error.
If the command exists and is executable, it replaces the current shell. That means that if
exec
appears in a script, the instructions following the exec call will never be executed (unlessexec
is itself in a subshell).exec
never returns. Shell traps like "EXIT" won't get triggered either.If no argument is passed,
exec
is only used to redefine the current shell file descriptors. The shell continue after theexec
, unlike with the previous case, but the standard input, output, error or whatever file descriptor has been redirected take effect.If some of the redirections uses
/dev/null
, any input from it will return EOF and any output to it will be discarded.You can close file descriptors by using
-
as source or destination, e.g.exec <&-
. Subsequent read or writes will then fail.
Here are two examples:
echo foo > /tmp/bar
exec < /tmp/bar # exec has no arguments, will only affect current shell descriptors, here stdin
cat # simple command that read stdin and write it to stdout
This script will output "foo" as the cat command, instead of waiting for user input as it would have done in the usual case will take its input from the /tmp/bar file which contains foo.
echo foo > /tmp/bar
exec wc -c < /tmp/bar # exec has two arguments, the control flow will switch to the wc command
cat
This script will display 4
(the number of bytes in /tmp/bar) and immediately ends. The cat
command won't be executed.
4
`Some old posts never really get old ... +1.
– Cbhihe
Mar 23 '17 at 11:33
3
If some of the redirections uses /dev/null, the associated file descriptor is closed. No, it really does redirect to/from/dev/null
, so writes still succeed and reads return EOF.close(2)
on an fd would cause read/write system calls to return errors, and you do that withexec 2>&-
for example.
– Peter Cordes
Jul 7 '17 at 2:59
2
Try it yourself:exec 3</dev/null;
ls -l /proc/self/fd
: note that fd 3 will be open read-only on /dev/null. Then close it again withexec 3<&-
, and you can see (withls -l /proc/$$/fd
again) that your shell process has no fd 3 anymore. (closing stdin withexec <&-
can be useful in scripts, but interactively it's a logout.)
– Peter Cordes
Jul 7 '17 at 3:01
@PeterCordes You are absolutely right. Answer updated. Thanks!
– jlliagre
Jul 7 '17 at 5:43
1
This answer is great because it explains the two use-cases ofexec
the current most-upvoted answer only talks about the one use-case and the other answer by g_p only talks about the other use-case. And this answer is nice and concise/readable for such a complex subject matter.
– Trevor Boyd Smith
Jan 22 at 14:09
|
show 1 more comment
exec
is a command with two very distinct behaviors, depending on whether at least one argument is used with it, or no argument is used at all.
If at least one argument is passed, the first one is taken as a command name and
exec
try to execute it as a command passing the remaining arguments, if any, to that command and managing the redirections, if any.If the command passed as first argument doesn't exist, the current shell, not only the exec command, exits in error.
If the command exists and is executable, it replaces the current shell. That means that if
exec
appears in a script, the instructions following the exec call will never be executed (unlessexec
is itself in a subshell).exec
never returns. Shell traps like "EXIT" won't get triggered either.If no argument is passed,
exec
is only used to redefine the current shell file descriptors. The shell continue after theexec
, unlike with the previous case, but the standard input, output, error or whatever file descriptor has been redirected take effect.If some of the redirections uses
/dev/null
, any input from it will return EOF and any output to it will be discarded.You can close file descriptors by using
-
as source or destination, e.g.exec <&-
. Subsequent read or writes will then fail.
Here are two examples:
echo foo > /tmp/bar
exec < /tmp/bar # exec has no arguments, will only affect current shell descriptors, here stdin
cat # simple command that read stdin and write it to stdout
This script will output "foo" as the cat command, instead of waiting for user input as it would have done in the usual case will take its input from the /tmp/bar file which contains foo.
echo foo > /tmp/bar
exec wc -c < /tmp/bar # exec has two arguments, the control flow will switch to the wc command
cat
This script will display 4
(the number of bytes in /tmp/bar) and immediately ends. The cat
command won't be executed.
exec
is a command with two very distinct behaviors, depending on whether at least one argument is used with it, or no argument is used at all.
If at least one argument is passed, the first one is taken as a command name and
exec
try to execute it as a command passing the remaining arguments, if any, to that command and managing the redirections, if any.If the command passed as first argument doesn't exist, the current shell, not only the exec command, exits in error.
If the command exists and is executable, it replaces the current shell. That means that if
exec
appears in a script, the instructions following the exec call will never be executed (unlessexec
is itself in a subshell).exec
never returns. Shell traps like "EXIT" won't get triggered either.If no argument is passed,
exec
is only used to redefine the current shell file descriptors. The shell continue after theexec
, unlike with the previous case, but the standard input, output, error or whatever file descriptor has been redirected take effect.If some of the redirections uses
/dev/null
, any input from it will return EOF and any output to it will be discarded.You can close file descriptors by using
-
as source or destination, e.g.exec <&-
. Subsequent read or writes will then fail.
Here are two examples:
echo foo > /tmp/bar
exec < /tmp/bar # exec has no arguments, will only affect current shell descriptors, here stdin
cat # simple command that read stdin and write it to stdout
This script will output "foo" as the cat command, instead of waiting for user input as it would have done in the usual case will take its input from the /tmp/bar file which contains foo.
echo foo > /tmp/bar
exec wc -c < /tmp/bar # exec has two arguments, the control flow will switch to the wc command
cat
This script will display 4
(the number of bytes in /tmp/bar) and immediately ends. The cat
command won't be executed.
edited Jan 28 at 10:09
answered Sep 18 '14 at 22:02
jlliagrejlliagre
3,9051525
3,9051525
4
`Some old posts never really get old ... +1.
– Cbhihe
Mar 23 '17 at 11:33
3
If some of the redirections uses /dev/null, the associated file descriptor is closed. No, it really does redirect to/from/dev/null
, so writes still succeed and reads return EOF.close(2)
on an fd would cause read/write system calls to return errors, and you do that withexec 2>&-
for example.
– Peter Cordes
Jul 7 '17 at 2:59
2
Try it yourself:exec 3</dev/null;
ls -l /proc/self/fd
: note that fd 3 will be open read-only on /dev/null. Then close it again withexec 3<&-
, and you can see (withls -l /proc/$$/fd
again) that your shell process has no fd 3 anymore. (closing stdin withexec <&-
can be useful in scripts, but interactively it's a logout.)
– Peter Cordes
Jul 7 '17 at 3:01
@PeterCordes You are absolutely right. Answer updated. Thanks!
– jlliagre
Jul 7 '17 at 5:43
1
This answer is great because it explains the two use-cases ofexec
the current most-upvoted answer only talks about the one use-case and the other answer by g_p only talks about the other use-case. And this answer is nice and concise/readable for such a complex subject matter.
– Trevor Boyd Smith
Jan 22 at 14:09
|
show 1 more comment
4
`Some old posts never really get old ... +1.
– Cbhihe
Mar 23 '17 at 11:33
3
If some of the redirections uses /dev/null, the associated file descriptor is closed. No, it really does redirect to/from/dev/null
, so writes still succeed and reads return EOF.close(2)
on an fd would cause read/write system calls to return errors, and you do that withexec 2>&-
for example.
– Peter Cordes
Jul 7 '17 at 2:59
2
Try it yourself:exec 3</dev/null;
ls -l /proc/self/fd
: note that fd 3 will be open read-only on /dev/null. Then close it again withexec 3<&-
, and you can see (withls -l /proc/$$/fd
again) that your shell process has no fd 3 anymore. (closing stdin withexec <&-
can be useful in scripts, but interactively it's a logout.)
– Peter Cordes
Jul 7 '17 at 3:01
@PeterCordes You are absolutely right. Answer updated. Thanks!
– jlliagre
Jul 7 '17 at 5:43
1
This answer is great because it explains the two use-cases ofexec
the current most-upvoted answer only talks about the one use-case and the other answer by g_p only talks about the other use-case. And this answer is nice and concise/readable for such a complex subject matter.
– Trevor Boyd Smith
Jan 22 at 14:09
4
4
`Some old posts never really get old ... +1.
– Cbhihe
Mar 23 '17 at 11:33
`Some old posts never really get old ... +1.
– Cbhihe
Mar 23 '17 at 11:33
3
3
If some of the redirections uses /dev/null, the associated file descriptor is closed. No, it really does redirect to/from
/dev/null
, so writes still succeed and reads return EOF. close(2)
on an fd would cause read/write system calls to return errors, and you do that with exec 2>&-
for example.– Peter Cordes
Jul 7 '17 at 2:59
If some of the redirections uses /dev/null, the associated file descriptor is closed. No, it really does redirect to/from
/dev/null
, so writes still succeed and reads return EOF. close(2)
on an fd would cause read/write system calls to return errors, and you do that with exec 2>&-
for example.– Peter Cordes
Jul 7 '17 at 2:59
2
2
Try it yourself:
exec 3</dev/null;
ls -l /proc/self/fd
: note that fd 3 will be open read-only on /dev/null. Then close it again with exec 3<&-
, and you can see (with ls -l /proc/$$/fd
again) that your shell process has no fd 3 anymore. (closing stdin with exec <&-
can be useful in scripts, but interactively it's a logout.)– Peter Cordes
Jul 7 '17 at 3:01
Try it yourself:
exec 3</dev/null;
ls -l /proc/self/fd
: note that fd 3 will be open read-only on /dev/null. Then close it again with exec 3<&-
, and you can see (with ls -l /proc/$$/fd
again) that your shell process has no fd 3 anymore. (closing stdin with exec <&-
can be useful in scripts, but interactively it's a logout.)– Peter Cordes
Jul 7 '17 at 3:01
@PeterCordes You are absolutely right. Answer updated. Thanks!
– jlliagre
Jul 7 '17 at 5:43
@PeterCordes You are absolutely right. Answer updated. Thanks!
– jlliagre
Jul 7 '17 at 5:43
1
1
This answer is great because it explains the two use-cases of
exec
the current most-upvoted answer only talks about the one use-case and the other answer by g_p only talks about the other use-case. And this answer is nice and concise/readable for such a complex subject matter.– Trevor Boyd Smith
Jan 22 at 14:09
This answer is great because it explains the two use-cases of
exec
the current most-upvoted answer only talks about the one use-case and the other answer by g_p only talks about the other use-case. And this answer is nice and concise/readable for such a complex subject matter.– Trevor Boyd Smith
Jan 22 at 14:09
|
show 1 more comment
To understand exec
you need to first understand fork
. I am trying to keep it short.
When you come to a fork in the road you generally have two options. Linux programs reach this fork in the road when they hit a
fork()
system call.Normal programs are system commands that exist in a compiled form on
your system. When such a program is executed, a new process is
created. This child process has the same environment as its parent,
only the process ID number is different. This procedure is called
forking.- Forking provides a way for an existing process to start a new one. However,
there may be situations where a child process is not the part of the same
program as parent process. In this caseexec
is used.exec
will replace the contents of the currently running process with the
information from a program binary. - After the forking process, the address space of the child process is
overwritten with the new process data. This is done through an exec
call to the system.
3
can you explain whyexec
can redirect a script output, as in the link I posted?
– becko
Sep 18 '14 at 21:45
I found this unclear "However, there may be situations where a child process is not the part of the same program as parent process"
– cdosborn
Oct 15 '18 at 22:34
add a comment |
To understand exec
you need to first understand fork
. I am trying to keep it short.
When you come to a fork in the road you generally have two options. Linux programs reach this fork in the road when they hit a
fork()
system call.Normal programs are system commands that exist in a compiled form on
your system. When such a program is executed, a new process is
created. This child process has the same environment as its parent,
only the process ID number is different. This procedure is called
forking.- Forking provides a way for an existing process to start a new one. However,
there may be situations where a child process is not the part of the same
program as parent process. In this caseexec
is used.exec
will replace the contents of the currently running process with the
information from a program binary. - After the forking process, the address space of the child process is
overwritten with the new process data. This is done through an exec
call to the system.
3
can you explain whyexec
can redirect a script output, as in the link I posted?
– becko
Sep 18 '14 at 21:45
I found this unclear "However, there may be situations where a child process is not the part of the same program as parent process"
– cdosborn
Oct 15 '18 at 22:34
add a comment |
To understand exec
you need to first understand fork
. I am trying to keep it short.
When you come to a fork in the road you generally have two options. Linux programs reach this fork in the road when they hit a
fork()
system call.Normal programs are system commands that exist in a compiled form on
your system. When such a program is executed, a new process is
created. This child process has the same environment as its parent,
only the process ID number is different. This procedure is called
forking.- Forking provides a way for an existing process to start a new one. However,
there may be situations where a child process is not the part of the same
program as parent process. In this caseexec
is used.exec
will replace the contents of the currently running process with the
information from a program binary. - After the forking process, the address space of the child process is
overwritten with the new process data. This is done through an exec
call to the system.
To understand exec
you need to first understand fork
. I am trying to keep it short.
When you come to a fork in the road you generally have two options. Linux programs reach this fork in the road when they hit a
fork()
system call.Normal programs are system commands that exist in a compiled form on
your system. When such a program is executed, a new process is
created. This child process has the same environment as its parent,
only the process ID number is different. This procedure is called
forking.- Forking provides a way for an existing process to start a new one. However,
there may be situations where a child process is not the part of the same
program as parent process. In this caseexec
is used.exec
will replace the contents of the currently running process with the
information from a program binary. - After the forking process, the address space of the child process is
overwritten with the new process data. This is done through an exec
call to the system.
edited Feb 16 '18 at 10:41
David Foerster
28.5k1366112
28.5k1366112
answered Sep 18 '14 at 21:38
g_pg_p
12.9k24661
12.9k24661
3
can you explain whyexec
can redirect a script output, as in the link I posted?
– becko
Sep 18 '14 at 21:45
I found this unclear "However, there may be situations where a child process is not the part of the same program as parent process"
– cdosborn
Oct 15 '18 at 22:34
add a comment |
3
can you explain whyexec
can redirect a script output, as in the link I posted?
– becko
Sep 18 '14 at 21:45
I found this unclear "However, there may be situations where a child process is not the part of the same program as parent process"
– cdosborn
Oct 15 '18 at 22:34
3
3
can you explain why
exec
can redirect a script output, as in the link I posted?– becko
Sep 18 '14 at 21:45
can you explain why
exec
can redirect a script output, as in the link I posted?– becko
Sep 18 '14 at 21:45
I found this unclear "However, there may be situations where a child process is not the part of the same program as parent process"
– cdosborn
Oct 15 '18 at 22:34
I found this unclear "However, there may be situations where a child process is not the part of the same program as parent process"
– cdosborn
Oct 15 '18 at 22:34
add a comment |
In bash
, if you do help exec
:
$ help exec
exec: exec [-cl] [-a name] [command [arguments ...]] [redirection ...]
Replace the shell with the given command.
Execute COMMAND, replacing this shell with the specified program.
ARGUMENTS become the arguments to COMMAND. If COMMAND is not specified,
any redirections take effect in the current shell.
Options:
-a name pass NAME as the zeroth argument to COMMAND
-c execute COMMAND with an empty environment
-l place a dash in the zeroth argument to COMMAND
If the command cannot be executed, a non-interactive shell exits, unless
the shell option `execfail' is set.
Exit Status:
Returns success unless COMMAND is not found or a redirection error occurs.
The relevant bit:
If COMMAND is not specified, any redirections take effect in the current shell.
exec
is a shell builtin, which is the shell equivalent of the exec
family of system calls that G_P speaks of (and whose manpages you appear to have read). It just has the POSIX mandated functionality of affecting the current shell if no command is specified.
add a comment |
In bash
, if you do help exec
:
$ help exec
exec: exec [-cl] [-a name] [command [arguments ...]] [redirection ...]
Replace the shell with the given command.
Execute COMMAND, replacing this shell with the specified program.
ARGUMENTS become the arguments to COMMAND. If COMMAND is not specified,
any redirections take effect in the current shell.
Options:
-a name pass NAME as the zeroth argument to COMMAND
-c execute COMMAND with an empty environment
-l place a dash in the zeroth argument to COMMAND
If the command cannot be executed, a non-interactive shell exits, unless
the shell option `execfail' is set.
Exit Status:
Returns success unless COMMAND is not found or a redirection error occurs.
The relevant bit:
If COMMAND is not specified, any redirections take effect in the current shell.
exec
is a shell builtin, which is the shell equivalent of the exec
family of system calls that G_P speaks of (and whose manpages you appear to have read). It just has the POSIX mandated functionality of affecting the current shell if no command is specified.
add a comment |
In bash
, if you do help exec
:
$ help exec
exec: exec [-cl] [-a name] [command [arguments ...]] [redirection ...]
Replace the shell with the given command.
Execute COMMAND, replacing this shell with the specified program.
ARGUMENTS become the arguments to COMMAND. If COMMAND is not specified,
any redirections take effect in the current shell.
Options:
-a name pass NAME as the zeroth argument to COMMAND
-c execute COMMAND with an empty environment
-l place a dash in the zeroth argument to COMMAND
If the command cannot be executed, a non-interactive shell exits, unless
the shell option `execfail' is set.
Exit Status:
Returns success unless COMMAND is not found or a redirection error occurs.
The relevant bit:
If COMMAND is not specified, any redirections take effect in the current shell.
exec
is a shell builtin, which is the shell equivalent of the exec
family of system calls that G_P speaks of (and whose manpages you appear to have read). It just has the POSIX mandated functionality of affecting the current shell if no command is specified.
In bash
, if you do help exec
:
$ help exec
exec: exec [-cl] [-a name] [command [arguments ...]] [redirection ...]
Replace the shell with the given command.
Execute COMMAND, replacing this shell with the specified program.
ARGUMENTS become the arguments to COMMAND. If COMMAND is not specified,
any redirections take effect in the current shell.
Options:
-a name pass NAME as the zeroth argument to COMMAND
-c execute COMMAND with an empty environment
-l place a dash in the zeroth argument to COMMAND
If the command cannot be executed, a non-interactive shell exits, unless
the shell option `execfail' is set.
Exit Status:
Returns success unless COMMAND is not found or a redirection error occurs.
The relevant bit:
If COMMAND is not specified, any redirections take effect in the current shell.
exec
is a shell builtin, which is the shell equivalent of the exec
family of system calls that G_P speaks of (and whose manpages you appear to have read). It just has the POSIX mandated functionality of affecting the current shell if no command is specified.
edited Apr 13 '17 at 12:37
Community♦
1
1
answered Sep 18 '14 at 21:52
murumuru
1
1
add a comment |
add a comment |
Thanks for contributing an answer to Ask Ubuntu!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f525767%2fwhat-does-an-exec-command-do%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Are you familiar with whar a process is?
– fkraiem
Sep 18 '14 at 21:18
1
@fkraiem what do you mean?
– becko
Sep 18 '14 at 21:28
Sorry I meant "what". :p But the answer seems to be no.
– fkraiem
Sep 18 '14 at 21:47
But actually your script uses
exec
in a special way which can be explained much more simply, I will write an answer.– fkraiem
Sep 18 '14 at 21:51
1
Related: unix.stackexchange.com/q/296838/85039
– Sergiy Kolodyazhnyy
Jul 7 '17 at 6:31