Why is the exec command used for file descriptor redirection?
In UNIX shells like Bash and Korn shell exec is used for two specific uses.
Its use to replace the current program with another, as in exec prog is understandable. The name exec is a contraction from the C family of routines based on execve.
If I was writing a shell and I wanted a command to open a file then I would probably call it open, but no, Bash and Korn shells use exec again, as in exec 3<file, for example.
Why was the exec command reused for something completely different?
shell
add a comment |
In UNIX shells like Bash and Korn shell exec is used for two specific uses.
Its use to replace the current program with another, as in exec prog is understandable. The name exec is a contraction from the C family of routines based on execve.
If I was writing a shell and I wanted a command to open a file then I would probably call it open, but no, Bash and Korn shells use exec again, as in exec 3<file, for example.
Why was the exec command reused for something completely different?
shell
add a comment |
In UNIX shells like Bash and Korn shell exec is used for two specific uses.
Its use to replace the current program with another, as in exec prog is understandable. The name exec is a contraction from the C family of routines based on execve.
If I was writing a shell and I wanted a command to open a file then I would probably call it open, but no, Bash and Korn shells use exec again, as in exec 3<file, for example.
Why was the exec command reused for something completely different?
shell
In UNIX shells like Bash and Korn shell exec is used for two specific uses.
Its use to replace the current program with another, as in exec prog is understandable. The name exec is a contraction from the C family of routines based on execve.
If I was writing a shell and I wanted a command to open a file then I would probably call it open, but no, Bash and Korn shells use exec again, as in exec 3<file, for example.
Why was the exec command reused for something completely different?
shell
shell
asked Mar 20 '15 at 17:18
cdarkecdarke
1083
1083
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
It's not really completely different: you can use redirections with an command
bash -c 'exec date > date.out' ; cat date.out
Why not use it without a command
bash -c 'exec > date.out; date' ; cat date.out
I had never considered the exec command in that way, even though I have been using it for over 20 years. Thanks.
– cdarke
Mar 20 '15 at 22:57
add a comment |
I'm 4 years late to the party but I've just been looking at this myself.
Just note that you need to be careful with Glenn's answer, because in the case where you use exec with both a command and redirection, the result is just the redirection.
The supposedly 'exec'd' command will run in a subshell, and commands after it in the calling script will still run.
Which to me suggests that the two uses really should be two separate commands.
1
(1) Perhaps I misunderstand what you’re saying, but I can’t reproduce what I think you’re saying in bash 4.1. I didexec date > date.outin a script, and commands after it in the script did not run. (2) This is not really an answer to the question.
– Scott
Jan 25 at 3:19
1
So far as I can tell the exec'd command does not occur in a sub-shell but in the same process, unless you have evidence that it is a sub-shell. I also tried to reproduce this and got the same results as @Scott in bash 3.2 and 4.4. To quote the source code (builtins/exec.def) 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.
– cdarke
Jan 25 at 20:53
To answer Scott's point 2 - I don't have the reputation to be able to comment so I added an answer - I'm not sure whether that's an approved of thing or not.. I see what you mean with your date example. I was debugging a script that did something likeexec date | tee date.outand that behaves differently. If you exec a script that prints $$ this way you can see you get a new shell. So it looks like a pipe works differently. I was kind of looking it as the same thing but I guess a pipe includes redirection but is more than just redirection.
– Jeff Beggs
Jan 27 at 7:08
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "3"
};
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%2fsuperuser.com%2fquestions%2f891998%2fwhy-is-the-exec-command-used-for-file-descriptor-redirection%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
It's not really completely different: you can use redirections with an command
bash -c 'exec date > date.out' ; cat date.out
Why not use it without a command
bash -c 'exec > date.out; date' ; cat date.out
I had never considered the exec command in that way, even though I have been using it for over 20 years. Thanks.
– cdarke
Mar 20 '15 at 22:57
add a comment |
It's not really completely different: you can use redirections with an command
bash -c 'exec date > date.out' ; cat date.out
Why not use it without a command
bash -c 'exec > date.out; date' ; cat date.out
I had never considered the exec command in that way, even though I have been using it for over 20 years. Thanks.
– cdarke
Mar 20 '15 at 22:57
add a comment |
It's not really completely different: you can use redirections with an command
bash -c 'exec date > date.out' ; cat date.out
Why not use it without a command
bash -c 'exec > date.out; date' ; cat date.out
It's not really completely different: you can use redirections with an command
bash -c 'exec date > date.out' ; cat date.out
Why not use it without a command
bash -c 'exec > date.out; date' ; cat date.out
answered Mar 20 '15 at 20:32
glenn jackmanglenn jackman
16k22645
16k22645
I had never considered the exec command in that way, even though I have been using it for over 20 years. Thanks.
– cdarke
Mar 20 '15 at 22:57
add a comment |
I had never considered the exec command in that way, even though I have been using it for over 20 years. Thanks.
– cdarke
Mar 20 '15 at 22:57
I had never considered the exec command in that way, even though I have been using it for over 20 years. Thanks.
– cdarke
Mar 20 '15 at 22:57
I had never considered the exec command in that way, even though I have been using it for over 20 years. Thanks.
– cdarke
Mar 20 '15 at 22:57
add a comment |
I'm 4 years late to the party but I've just been looking at this myself.
Just note that you need to be careful with Glenn's answer, because in the case where you use exec with both a command and redirection, the result is just the redirection.
The supposedly 'exec'd' command will run in a subshell, and commands after it in the calling script will still run.
Which to me suggests that the two uses really should be two separate commands.
1
(1) Perhaps I misunderstand what you’re saying, but I can’t reproduce what I think you’re saying in bash 4.1. I didexec date > date.outin a script, and commands after it in the script did not run. (2) This is not really an answer to the question.
– Scott
Jan 25 at 3:19
1
So far as I can tell the exec'd command does not occur in a sub-shell but in the same process, unless you have evidence that it is a sub-shell. I also tried to reproduce this and got the same results as @Scott in bash 3.2 and 4.4. To quote the source code (builtins/exec.def) 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.
– cdarke
Jan 25 at 20:53
To answer Scott's point 2 - I don't have the reputation to be able to comment so I added an answer - I'm not sure whether that's an approved of thing or not.. I see what you mean with your date example. I was debugging a script that did something likeexec date | tee date.outand that behaves differently. If you exec a script that prints $$ this way you can see you get a new shell. So it looks like a pipe works differently. I was kind of looking it as the same thing but I guess a pipe includes redirection but is more than just redirection.
– Jeff Beggs
Jan 27 at 7:08
add a comment |
I'm 4 years late to the party but I've just been looking at this myself.
Just note that you need to be careful with Glenn's answer, because in the case where you use exec with both a command and redirection, the result is just the redirection.
The supposedly 'exec'd' command will run in a subshell, and commands after it in the calling script will still run.
Which to me suggests that the two uses really should be two separate commands.
1
(1) Perhaps I misunderstand what you’re saying, but I can’t reproduce what I think you’re saying in bash 4.1. I didexec date > date.outin a script, and commands after it in the script did not run. (2) This is not really an answer to the question.
– Scott
Jan 25 at 3:19
1
So far as I can tell the exec'd command does not occur in a sub-shell but in the same process, unless you have evidence that it is a sub-shell. I also tried to reproduce this and got the same results as @Scott in bash 3.2 and 4.4. To quote the source code (builtins/exec.def) 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.
– cdarke
Jan 25 at 20:53
To answer Scott's point 2 - I don't have the reputation to be able to comment so I added an answer - I'm not sure whether that's an approved of thing or not.. I see what you mean with your date example. I was debugging a script that did something likeexec date | tee date.outand that behaves differently. If you exec a script that prints $$ this way you can see you get a new shell. So it looks like a pipe works differently. I was kind of looking it as the same thing but I guess a pipe includes redirection but is more than just redirection.
– Jeff Beggs
Jan 27 at 7:08
add a comment |
I'm 4 years late to the party but I've just been looking at this myself.
Just note that you need to be careful with Glenn's answer, because in the case where you use exec with both a command and redirection, the result is just the redirection.
The supposedly 'exec'd' command will run in a subshell, and commands after it in the calling script will still run.
Which to me suggests that the two uses really should be two separate commands.
I'm 4 years late to the party but I've just been looking at this myself.
Just note that you need to be careful with Glenn's answer, because in the case where you use exec with both a command and redirection, the result is just the redirection.
The supposedly 'exec'd' command will run in a subshell, and commands after it in the calling script will still run.
Which to me suggests that the two uses really should be two separate commands.
answered Jan 25 at 2:41
Jeff BeggsJeff Beggs
112
112
1
(1) Perhaps I misunderstand what you’re saying, but I can’t reproduce what I think you’re saying in bash 4.1. I didexec date > date.outin a script, and commands after it in the script did not run. (2) This is not really an answer to the question.
– Scott
Jan 25 at 3:19
1
So far as I can tell the exec'd command does not occur in a sub-shell but in the same process, unless you have evidence that it is a sub-shell. I also tried to reproduce this and got the same results as @Scott in bash 3.2 and 4.4. To quote the source code (builtins/exec.def) 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.
– cdarke
Jan 25 at 20:53
To answer Scott's point 2 - I don't have the reputation to be able to comment so I added an answer - I'm not sure whether that's an approved of thing or not.. I see what you mean with your date example. I was debugging a script that did something likeexec date | tee date.outand that behaves differently. If you exec a script that prints $$ this way you can see you get a new shell. So it looks like a pipe works differently. I was kind of looking it as the same thing but I guess a pipe includes redirection but is more than just redirection.
– Jeff Beggs
Jan 27 at 7:08
add a comment |
1
(1) Perhaps I misunderstand what you’re saying, but I can’t reproduce what I think you’re saying in bash 4.1. I didexec date > date.outin a script, and commands after it in the script did not run. (2) This is not really an answer to the question.
– Scott
Jan 25 at 3:19
1
So far as I can tell the exec'd command does not occur in a sub-shell but in the same process, unless you have evidence that it is a sub-shell. I also tried to reproduce this and got the same results as @Scott in bash 3.2 and 4.4. To quote the source code (builtins/exec.def) 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.
– cdarke
Jan 25 at 20:53
To answer Scott's point 2 - I don't have the reputation to be able to comment so I added an answer - I'm not sure whether that's an approved of thing or not.. I see what you mean with your date example. I was debugging a script that did something likeexec date | tee date.outand that behaves differently. If you exec a script that prints $$ this way you can see you get a new shell. So it looks like a pipe works differently. I was kind of looking it as the same thing but I guess a pipe includes redirection but is more than just redirection.
– Jeff Beggs
Jan 27 at 7:08
1
1
(1) Perhaps I misunderstand what you’re saying, but I can’t reproduce what I think you’re saying in bash 4.1. I did
exec date > date.out in a script, and commands after it in the script did not run. (2) This is not really an answer to the question.– Scott
Jan 25 at 3:19
(1) Perhaps I misunderstand what you’re saying, but I can’t reproduce what I think you’re saying in bash 4.1. I did
exec date > date.out in a script, and commands after it in the script did not run. (2) This is not really an answer to the question.– Scott
Jan 25 at 3:19
1
1
So far as I can tell the exec'd command does not occur in a sub-shell but in the same process, unless you have evidence that it is a sub-shell. I also tried to reproduce this and got the same results as @Scott in bash 3.2 and 4.4. To quote the source code (
builtins/exec.def) 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.– cdarke
Jan 25 at 20:53
So far as I can tell the exec'd command does not occur in a sub-shell but in the same process, unless you have evidence that it is a sub-shell. I also tried to reproduce this and got the same results as @Scott in bash 3.2 and 4.4. To quote the source code (
builtins/exec.def) 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.– cdarke
Jan 25 at 20:53
To answer Scott's point 2 - I don't have the reputation to be able to comment so I added an answer - I'm not sure whether that's an approved of thing or not.. I see what you mean with your date example. I was debugging a script that did something like
exec date | tee date.out and that behaves differently. If you exec a script that prints $$ this way you can see you get a new shell. So it looks like a pipe works differently. I was kind of looking it as the same thing but I guess a pipe includes redirection but is more than just redirection.– Jeff Beggs
Jan 27 at 7:08
To answer Scott's point 2 - I don't have the reputation to be able to comment so I added an answer - I'm not sure whether that's an approved of thing or not.. I see what you mean with your date example. I was debugging a script that did something like
exec date | tee date.out and that behaves differently. If you exec a script that prints $$ this way you can see you get a new shell. So it looks like a pipe works differently. I was kind of looking it as the same thing but I guess a pipe includes redirection but is more than just redirection.– Jeff Beggs
Jan 27 at 7:08
add a comment |
Thanks for contributing an answer to Super User!
- 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%2fsuperuser.com%2fquestions%2f891998%2fwhy-is-the-exec-command-used-for-file-descriptor-redirection%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