Does ` (sleep 123 &)` remove the process group from bash's job control?
Does the following way
$ (sleep 123 &)
$ jobs
$
remove the process group of sleep 123 from bash's job control? What is the difference between the above way and disown then?
Note that the sleep 123 process is still in the same process group led by the now disappearing subshell, and in the same process session as the interactive shell, so share the same controlling terminal.
Does not being in the shell's job control explain that the sleep 123 process will not receive any signal (including SIGHUP) sent from the bash process?
Thanks.
bash background-process signals job-control
asked Dec 27 '18 at 16:15
TimTim
26.3k74246455
add a comment |
Does the following way
$ (sleep 123 &)
$ jobs
$
remove the process group of sleep 123 from bash's job control? What is the difference between the above way and disown then?
Note that the sleep 123 process is still in the same process group led by the now disappearing subshell, and in the same process session as the interactive shell, so share the same controlling terminal.
Does not being in the shell's job control explain that the sleep 123 process will not receive any signal (including SIGHUP) sent from the bash process?
Thanks.
bash background-process signals job-control
asked Dec 27 '18 at 16:15
TimTim
26.3k74246455
3
Possible duplicate of Putting subshell in background vs putting command in background
– Jesse_b
Dec 27 '18 at 17:10
2
@Jesse_b Not subtle difference between(...)&in the proposed dupe and(...&)in this question.
– Kusalananda
Dec 27 '18 at 17:20
@Jesse_b this is absolutely not a dupe of the question you're pointing to. It may be rather a dupe of this.
– mosvy
Dec 28 '18 at 6:20
add a comment |
Does the following way
$ (sleep 123 &)
$ jobs
$
remove the process group of sleep 123 from bash's job control? What is the difference between the above way and disown then?
Note that the sleep 123 process is still in the same process group led by the now disappearing subshell, and in the same process session as the interactive shell, so share the same controlling terminal.
Does not being in the shell's job control explain that the sleep 123 process will not receive any signal (including SIGHUP) sent from the bash process?
Thanks.
bash background-process signals job-control
asked Dec 27 '18 at 16:15
TimTim
26.3k74246455
Does the following way
$ (sleep 123 &)
$ jobs
$
remove the process group of sleep 123 from bash's job control? What is the difference between the above way and disown then?
Note that the sleep 123 process is still in the same process group led by the now disappearing subshell, and in the same process session as the interactive shell, so share the same controlling terminal.
Does not being in the shell's job control explain that the sleep 123 process will not receive any signal (including SIGHUP) sent from the bash process?
Thanks.
bash background-process signals job-control
bash background-process signals job-control
asked Dec 27 '18 at 16:15
TimTim
26.3k74246455
asked Dec 27 '18 at 16:15
TimTim
26.3k74246455
edited Dec 27 '18 at 17:29
Tim
asked Dec 27 '18 at 16:15
TimTim
26.3k74246455
asked Dec 27 '18 at 16:15
TimTim
26.3k74246455
asked Dec 27 '18 at 16:15
TimTim
26.3k74246455
26.3k74246455
3
Possible duplicate of Putting subshell in background vs putting command in background
– Jesse_b
Dec 27 '18 at 17:10
2
@Jesse_b Not subtle difference between(...)&in the proposed dupe and(...&)in this question.
– Kusalananda
Dec 27 '18 at 17:20
@Jesse_b this is absolutely not a dupe of the question you're pointing to. It may be rather a dupe of this.
– mosvy
Dec 28 '18 at 6:20
add a comment |
3
Possible duplicate of Putting subshell in background vs putting command in background
– Jesse_b
Dec 27 '18 at 17:10
2
@Jesse_b Not subtle difference between(...)&in the proposed dupe and(...&)in this question.
– Kusalananda
Dec 27 '18 at 17:20
@Jesse_b this is absolutely not a dupe of the question you're pointing to. It may be rather a dupe of this.
– mosvy
Dec 28 '18 at 6:20
3
3
Possible duplicate of Putting subshell in background vs putting command in background
– Jesse_b
Dec 27 '18 at 17:10
Possible duplicate of Putting subshell in background vs putting command in background
– Jesse_b
Dec 27 '18 at 17:10
2
2
@Jesse_b Not subtle difference between
(...)& in the proposed dupe and (...&) in this question.– Kusalananda
Dec 27 '18 at 17:20
@Jesse_b Not subtle difference between
(...)& in the proposed dupe and (...&) in this question.– Kusalananda
Dec 27 '18 at 17:20
@Jesse_b this is absolutely not a dupe of the question you're pointing to. It may be rather a dupe of this.
– mosvy
Dec 28 '18 at 6:20
@Jesse_b this is absolutely not a dupe of the question you're pointing to. It may be rather a dupe of this.
– mosvy
Dec 28 '18 at 6:20
add a comment |
1 Answer
1
active
oldest
votes
Yes, it removes it, so to speak.
When you run a (...) subshell from an interactive bash script, a new process group (job) is created, which becomes the foreground process group on the terminal, and in the case where the subshell contains any command terminated by &, (eg. sleep 3600 &) that command will be started in the very same foreground process group, with SIGINT and SIGQUIT ignored and its input redirected from /dev/null). See here for some links to the standard.
When the (...) subshell exits, that foreground job is removed from the shell's jobs table, and the sleep 3600 command will continue to run outside of the control of the shell.
This is quite different from the case where (sleep 3600 &) is run from a non-interactive script with no job control, where everything (the main shell, its (...) subshell, and any "background" commands (foo &), inside or outside the (...) subshell) is run in the same process group.
answered Dec 27 '18 at 17:43
mosvymosvy
6,1861425
Thanks. (1) pubs.opengroup.org/onlinepubs/9699919799/utilities/… doesn't say that "When the (...) subshell exits, that foreground job is removed from the shell's jobs table". How did you get it? (2) What is the difference between the above way anddisownthen?
– Tim
Dec 27 '18 at 19:19
1) that link is about asynchronous lists;(...)is not such a thing, even if the subshell running in it may contain such async lists. That job will be removed from the table because its process group leader has exited when the prompt has been returned after the(...)command. 2)disownis a verybashspecific thing, and will remove jobs from the list it will send aSIGHUPto upon exiting (that's different from theSIGHUPsent by the kernel); thatsleep 123 &wasn't ever a separate job, as I already explained; the shell didn't keep tabs on it in the first place.
– mosvy
Dec 27 '18 at 19:40
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
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: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
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%2funix.stackexchange.com%2fquestions%2f491157%2fdoes-sleep-123-remove-the-process-group-from-bashs-job-control%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Yes, it removes it, so to speak.
When you run a (...) subshell from an interactive bash script, a new process group (job) is created, which becomes the foreground process group on the terminal, and in the case where the subshell contains any command terminated by &, (eg. sleep 3600 &) that command will be started in the very same foreground process group, with SIGINT and SIGQUIT ignored and its input redirected from /dev/null). See here for some links to the standard.
When the (...) subshell exits, that foreground job is removed from the shell's jobs table, and the sleep 3600 command will continue to run outside of the control of the shell.
This is quite different from the case where (sleep 3600 &) is run from a non-interactive script with no job control, where everything (the main shell, its (...) subshell, and any "background" commands (foo &), inside or outside the (...) subshell) is run in the same process group.
answered Dec 27 '18 at 17:43
mosvymosvy
6,1861425
Thanks. (1) pubs.opengroup.org/onlinepubs/9699919799/utilities/… doesn't say that "When the (...) subshell exits, that foreground job is removed from the shell's jobs table". How did you get it? (2) What is the difference between the above way anddisownthen?
– Tim
Dec 27 '18 at 19:19
1) that link is about asynchronous lists;(...)is not such a thing, even if the subshell running in it may contain such async lists. That job will be removed from the table because its process group leader has exited when the prompt has been returned after the(...)command. 2)disownis a verybashspecific thing, and will remove jobs from the list it will send aSIGHUPto upon exiting (that's different from theSIGHUPsent by the kernel); thatsleep 123 &wasn't ever a separate job, as I already explained; the shell didn't keep tabs on it in the first place.
– mosvy
Dec 27 '18 at 19:40
add a comment |
Yes, it removes it, so to speak.
When you run a (...) subshell from an interactive bash script, a new process group (job) is created, which becomes the foreground process group on the terminal, and in the case where the subshell contains any command terminated by &, (eg. sleep 3600 &) that command will be started in the very same foreground process group, with SIGINT and SIGQUIT ignored and its input redirected from /dev/null). See here for some links to the standard.
When the (...) subshell exits, that foreground job is removed from the shell's jobs table, and the sleep 3600 command will continue to run outside of the control of the shell.
This is quite different from the case where (sleep 3600 &) is run from a non-interactive script with no job control, where everything (the main shell, its (...) subshell, and any "background" commands (foo &), inside or outside the (...) subshell) is run in the same process group.
answered Dec 27 '18 at 17:43
mosvymosvy
6,1861425
Thanks. (1) pubs.opengroup.org/onlinepubs/9699919799/utilities/… doesn't say that "When the (...) subshell exits, that foreground job is removed from the shell's jobs table". How did you get it? (2) What is the difference between the above way anddisownthen?
– Tim
Dec 27 '18 at 19:19
1) that link is about asynchronous lists;(...)is not such a thing, even if the subshell running in it may contain such async lists. That job will be removed from the table because its process group leader has exited when the prompt has been returned after the(...)command. 2)disownis a verybashspecific thing, and will remove jobs from the list it will send aSIGHUPto upon exiting (that's different from theSIGHUPsent by the kernel); thatsleep 123 &wasn't ever a separate job, as I already explained; the shell didn't keep tabs on it in the first place.
– mosvy
Dec 27 '18 at 19:40
add a comment |
Yes, it removes it, so to speak.
When you run a (...) subshell from an interactive bash script, a new process group (job) is created, which becomes the foreground process group on the terminal, and in the case where the subshell contains any command terminated by &, (eg. sleep 3600 &) that command will be started in the very same foreground process group, with SIGINT and SIGQUIT ignored and its input redirected from /dev/null). See here for some links to the standard.
When the (...) subshell exits, that foreground job is removed from the shell's jobs table, and the sleep 3600 command will continue to run outside of the control of the shell.
This is quite different from the case where (sleep 3600 &) is run from a non-interactive script with no job control, where everything (the main shell, its (...) subshell, and any "background" commands (foo &), inside or outside the (...) subshell) is run in the same process group.
answered Dec 27 '18 at 17:43
mosvymosvy
6,1861425
Yes, it removes it, so to speak.
When you run a (...) subshell from an interactive bash script, a new process group (job) is created, which becomes the foreground process group on the terminal, and in the case where the subshell contains any command terminated by &, (eg. sleep 3600 &) that command will be started in the very same foreground process group, with SIGINT and SIGQUIT ignored and its input redirected from /dev/null). See here for some links to the standard.
When the (...) subshell exits, that foreground job is removed from the shell's jobs table, and the sleep 3600 command will continue to run outside of the control of the shell.
This is quite different from the case where (sleep 3600 &) is run from a non-interactive script with no job control, where everything (the main shell, its (...) subshell, and any "background" commands (foo &), inside or outside the (...) subshell) is run in the same process group.
answered Dec 27 '18 at 17:43
mosvymosvy
6,1861425
edited Dec 27 '18 at 17:49
answered Dec 27 '18 at 17:43
mosvymosvy
6,1861425
answered Dec 27 '18 at 17:43
mosvymosvy
6,1861425
answered Dec 27 '18 at 17:43
mosvymosvy
6,1861425
6,1861425
Thanks. (1) pubs.opengroup.org/onlinepubs/9699919799/utilities/… doesn't say that "When the (...) subshell exits, that foreground job is removed from the shell's jobs table". How did you get it? (2) What is the difference between the above way anddisownthen?
– Tim
Dec 27 '18 at 19:19
1) that link is about asynchronous lists;(...)is not such a thing, even if the subshell running in it may contain such async lists. That job will be removed from the table because its process group leader has exited when the prompt has been returned after the(...)command. 2)disownis a verybashspecific thing, and will remove jobs from the list it will send aSIGHUPto upon exiting (that's different from theSIGHUPsent by the kernel); thatsleep 123 &wasn't ever a separate job, as I already explained; the shell didn't keep tabs on it in the first place.
– mosvy
Dec 27 '18 at 19:40
add a comment |
Thanks. (1) pubs.opengroup.org/onlinepubs/9699919799/utilities/… doesn't say that "When the (...) subshell exits, that foreground job is removed from the shell's jobs table". How did you get it? (2) What is the difference between the above way anddisownthen?
– Tim
Dec 27 '18 at 19:19
1) that link is about asynchronous lists;(...)is not such a thing, even if the subshell running in it may contain such async lists. That job will be removed from the table because its process group leader has exited when the prompt has been returned after the(...)command. 2)disownis a verybashspecific thing, and will remove jobs from the list it will send aSIGHUPto upon exiting (that's different from theSIGHUPsent by the kernel); thatsleep 123 &wasn't ever a separate job, as I already explained; the shell didn't keep tabs on it in the first place.
– mosvy
Dec 27 '18 at 19:40
Thanks. (1) pubs.opengroup.org/onlinepubs/9699919799/utilities/… doesn't say that "When the (...) subshell exits, that foreground job is removed from the shell's jobs table". How did you get it? (2) What is the difference between the above way and
disown then?– Tim
Dec 27 '18 at 19:19
Thanks. (1) pubs.opengroup.org/onlinepubs/9699919799/utilities/… doesn't say that "When the (...) subshell exits, that foreground job is removed from the shell's jobs table". How did you get it? (2) What is the difference between the above way and
disown then?– Tim
Dec 27 '18 at 19:19
1) that link is about asynchronous lists;
(...) is not such a thing, even if the subshell running in it may contain such async lists. That job will be removed from the table because its process group leader has exited when the prompt has been returned after the (...) command. 2) disown is a very bash specific thing, and will remove jobs from the list it will send a SIGHUP to upon exiting (that's different from the SIGHUP sent by the kernel); that sleep 123 & wasn't ever a separate job, as I already explained; the shell didn't keep tabs on it in the first place.– mosvy
Dec 27 '18 at 19:40
1) that link is about asynchronous lists;
(...) is not such a thing, even if the subshell running in it may contain such async lists. That job will be removed from the table because its process group leader has exited when the prompt has been returned after the (...) command. 2) disown is a very bash specific thing, and will remove jobs from the list it will send a SIGHUP to upon exiting (that's different from the SIGHUP sent by the kernel); that sleep 123 & wasn't ever a separate job, as I already explained; the shell didn't keep tabs on it in the first place.– mosvy
Dec 27 '18 at 19:40
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- 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.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- 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%2funix.stackexchange.com%2fquestions%2f491157%2fdoes-sleep-123-remove-the-process-group-from-bashs-job-control%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
3
Possible duplicate of Putting subshell in background vs putting command in background
– Jesse_b
Dec 27 '18 at 17:10
2
@Jesse_b Not subtle difference between
(...)&in the proposed dupe and(...&)in this question.– Kusalananda
Dec 27 '18 at 17:20
@Jesse_b this is absolutely not a dupe of the question you're pointing to. It may be rather a dupe of this.
– mosvy
Dec 28 '18 at 6:20