Must a foreground process group started by an interactive bash process be a job of the shell? [closed]
Clash Royale CLAN TAG#URR8PPP
up vote
-1
down vote
favorite
Suppose an interactive bash process with a controlling terminal starts a process group, and the process group runs foreground in the controlling terminal of the interactive bash process.
Must the foreground process group be a job of the shell? Is it possible that it is not a job of the shell?
If I am correct, disown can't apply to a foreground process group started by an interactive shell. Not sure if there is any other way to make that possible. Thanks.
The following is just some background which might distract you away.
https://books.google.com/books?id=Ps2SH727eCIC&lpg=PP1&dq=The%20lInux%20programming%20interface&pg=PA709#v=onepage&q&f=false says
The delivery of SIGHUP to the controlling process can set off a kind
of chain reaction, resulting in the delivery of SIGHUP to many other
processes. This may occur in two ways:
- The controlling process is typically a shell. The shell establishes a handler for SIGHUP , so that, before terminating, it can send a
SIGHUP to each of the jobs that it has created. This signal
terminates those jobs by default, but if instead they catch
the signal, then they are thus informed of the shell’s demise.
- Upon termination of the controlling process for a terminal, the kernel disassociates all processes in the session from the controlling
terminal, disassociates the controlling terminal from the session (so
that it may be acquired as the controlling terminal by another session
leader), and informs the members of the foreground process group of
the terminal of the loss of their controlling terminal by sending them
a SIGHUP signal.
I am considering the case when an interactive bash process is also the controlling process for a terminal. when an interactive bash process is also the controlling process for a terminal, when it receives SiGHUP, should I say "it send SIGHUP to all its jobs and its foreground process group" or "it send SIGHUP to all its jobs"? If the foreground process group of the shell can be non-job of the shell, then I should say "and its foreground process group"; otherwise, I can just ignore it because it is already included in "all the jobs" of the shell. That is my question.
bash job-control
asked Nov 26 at 23:49
Tim
25.2k72243445
closed as unclear what you're asking by Stephen Harris, Sparhawk, l0b0, Inian, G-Man Nov 27 at 4:52
Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
|
show 5 more comments
up vote
-1
down vote
favorite
Suppose an interactive bash process with a controlling terminal starts a process group, and the process group runs foreground in the controlling terminal of the interactive bash process.
Must the foreground process group be a job of the shell? Is it possible that it is not a job of the shell?
If I am correct, disown can't apply to a foreground process group started by an interactive shell. Not sure if there is any other way to make that possible. Thanks.
The following is just some background which might distract you away.
https://books.google.com/books?id=Ps2SH727eCIC&lpg=PP1&dq=The%20lInux%20programming%20interface&pg=PA709#v=onepage&q&f=false says
The delivery of SIGHUP to the controlling process can set off a kind
of chain reaction, resulting in the delivery of SIGHUP to many other
processes. This may occur in two ways:
- The controlling process is typically a shell. The shell establishes a handler for SIGHUP , so that, before terminating, it can send a
SIGHUP to each of the jobs that it has created. This signal
terminates those jobs by default, but if instead they catch
the signal, then they are thus informed of the shell’s demise.
- Upon termination of the controlling process for a terminal, the kernel disassociates all processes in the session from the controlling
terminal, disassociates the controlling terminal from the session (so
that it may be acquired as the controlling terminal by another session
leader), and informs the members of the foreground process group of
the terminal of the loss of their controlling terminal by sending them
a SIGHUP signal.
I am considering the case when an interactive bash process is also the controlling process for a terminal. when an interactive bash process is also the controlling process for a terminal, when it receives SiGHUP, should I say "it send SIGHUP to all its jobs and its foreground process group" or "it send SIGHUP to all its jobs"? If the foreground process group of the shell can be non-job of the shell, then I should say "and its foreground process group"; otherwise, I can just ignore it because it is already included in "all the jobs" of the shell. That is my question.
bash job-control
asked Nov 26 at 23:49
Tim
25.2k72243445
closed as unclear what you're asking by Stephen Harris, Sparhawk, l0b0, Inian, G-Man Nov 27 at 4:52
Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
2
What are you trying to do? Do you have an example, such as pseudocode?
– l0b0
Nov 27 at 0:52
If you don't understand it, it is completely okay. Just leave it alone, do no harm, and give others a chance to answer it.
– Tim
Nov 27 at 1:20
Please help to reopen, and/or reply my question in comments. Thanks.
– Tim
Nov 27 at 12:52
I don't think I understand what you're trying to do either. Do you want to disown the job currently running in foreground? Why? Is that because you want it to survive if the interactive shell waiting for it is killed.
– Stéphane Chazelas
Nov 27 at 14:06
1
The foreground process group is an attribute of the terminal device, it's the foreground process group of a terminal, not of a shell. Seetcsetpgrp()andtgetpgrp()(which are libc functions eventually doingioctl()on the tty device on Linux at least). You may want to revisit What are the responsibilities of each Pseudo-Terminal (PTY) component (software, master side, slave side)?
– Stéphane Chazelas
Nov 27 at 15:13
|
show 5 more comments
up vote
-1
down vote
favorite
up vote
-1
down vote
favorite
Suppose an interactive bash process with a controlling terminal starts a process group, and the process group runs foreground in the controlling terminal of the interactive bash process.
Must the foreground process group be a job of the shell? Is it possible that it is not a job of the shell?
If I am correct, disown can't apply to a foreground process group started by an interactive shell. Not sure if there is any other way to make that possible. Thanks.
The following is just some background which might distract you away.
https://books.google.com/books?id=Ps2SH727eCIC&lpg=PP1&dq=The%20lInux%20programming%20interface&pg=PA709#v=onepage&q&f=false says
The delivery of SIGHUP to the controlling process can set off a kind
of chain reaction, resulting in the delivery of SIGHUP to many other
processes. This may occur in two ways:
- The controlling process is typically a shell. The shell establishes a handler for SIGHUP , so that, before terminating, it can send a
SIGHUP to each of the jobs that it has created. This signal
terminates those jobs by default, but if instead they catch
the signal, then they are thus informed of the shell’s demise.
- Upon termination of the controlling process for a terminal, the kernel disassociates all processes in the session from the controlling
terminal, disassociates the controlling terminal from the session (so
that it may be acquired as the controlling terminal by another session
leader), and informs the members of the foreground process group of
the terminal of the loss of their controlling terminal by sending them
a SIGHUP signal.
I am considering the case when an interactive bash process is also the controlling process for a terminal. when an interactive bash process is also the controlling process for a terminal, when it receives SiGHUP, should I say "it send SIGHUP to all its jobs and its foreground process group" or "it send SIGHUP to all its jobs"? If the foreground process group of the shell can be non-job of the shell, then I should say "and its foreground process group"; otherwise, I can just ignore it because it is already included in "all the jobs" of the shell. That is my question.
bash job-control
asked Nov 26 at 23:49
Tim
25.2k72243445
Suppose an interactive bash process with a controlling terminal starts a process group, and the process group runs foreground in the controlling terminal of the interactive bash process.
Must the foreground process group be a job of the shell? Is it possible that it is not a job of the shell?
If I am correct, disown can't apply to a foreground process group started by an interactive shell. Not sure if there is any other way to make that possible. Thanks.
The following is just some background which might distract you away.
https://books.google.com/books?id=Ps2SH727eCIC&lpg=PP1&dq=The%20lInux%20programming%20interface&pg=PA709#v=onepage&q&f=false says
The delivery of SIGHUP to the controlling process can set off a kind
of chain reaction, resulting in the delivery of SIGHUP to many other
processes. This may occur in two ways:
- The controlling process is typically a shell. The shell establishes a handler for SIGHUP , so that, before terminating, it can send a
SIGHUP to each of the jobs that it has created. This signal
terminates those jobs by default, but if instead they catch
the signal, then they are thus informed of the shell’s demise.
- Upon termination of the controlling process for a terminal, the kernel disassociates all processes in the session from the controlling
terminal, disassociates the controlling terminal from the session (so
that it may be acquired as the controlling terminal by another session
leader), and informs the members of the foreground process group of
the terminal of the loss of their controlling terminal by sending them
a SIGHUP signal.
I am considering the case when an interactive bash process is also the controlling process for a terminal. when an interactive bash process is also the controlling process for a terminal, when it receives SiGHUP, should I say "it send SIGHUP to all its jobs and its foreground process group" or "it send SIGHUP to all its jobs"? If the foreground process group of the shell can be non-job of the shell, then I should say "and its foreground process group"; otherwise, I can just ignore it because it is already included in "all the jobs" of the shell. That is my question.
bash job-control
bash job-control
asked Nov 26 at 23:49
Tim
25.2k72243445
asked Nov 26 at 23:49
Tim
25.2k72243445
edited Dec 1 at 15:06
asked Nov 26 at 23:49
Tim
25.2k72243445
asked Nov 26 at 23:49
Tim
25.2k72243445
asked Nov 26 at 23:49
Tim
25.2k72243445
25.2k72243445
closed as unclear what you're asking by Stephen Harris, Sparhawk, l0b0, Inian, G-Man Nov 27 at 4:52
Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
closed as unclear what you're asking by Stephen Harris, Sparhawk, l0b0, Inian, G-Man Nov 27 at 4:52
Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
2
What are you trying to do? Do you have an example, such as pseudocode?
– l0b0
Nov 27 at 0:52
If you don't understand it, it is completely okay. Just leave it alone, do no harm, and give others a chance to answer it.
– Tim
Nov 27 at 1:20
Please help to reopen, and/or reply my question in comments. Thanks.
– Tim
Nov 27 at 12:52
I don't think I understand what you're trying to do either. Do you want to disown the job currently running in foreground? Why? Is that because you want it to survive if the interactive shell waiting for it is killed.
– Stéphane Chazelas
Nov 27 at 14:06
1
The foreground process group is an attribute of the terminal device, it's the foreground process group of a terminal, not of a shell. Seetcsetpgrp()andtgetpgrp()(which are libc functions eventually doingioctl()on the tty device on Linux at least). You may want to revisit What are the responsibilities of each Pseudo-Terminal (PTY) component (software, master side, slave side)?
– Stéphane Chazelas
Nov 27 at 15:13
|
show 5 more comments
2
What are you trying to do? Do you have an example, such as pseudocode?
– l0b0
Nov 27 at 0:52
If you don't understand it, it is completely okay. Just leave it alone, do no harm, and give others a chance to answer it.
– Tim
Nov 27 at 1:20
Please help to reopen, and/or reply my question in comments. Thanks.
– Tim
Nov 27 at 12:52
I don't think I understand what you're trying to do either. Do you want to disown the job currently running in foreground? Why? Is that because you want it to survive if the interactive shell waiting for it is killed.
– Stéphane Chazelas
Nov 27 at 14:06
1
The foreground process group is an attribute of the terminal device, it's the foreground process group of a terminal, not of a shell. Seetcsetpgrp()andtgetpgrp()(which are libc functions eventually doingioctl()on the tty device on Linux at least). You may want to revisit What are the responsibilities of each Pseudo-Terminal (PTY) component (software, master side, slave side)?
– Stéphane Chazelas
Nov 27 at 15:13
2
2
What are you trying to do? Do you have an example, such as pseudocode?
– l0b0
Nov 27 at 0:52
What are you trying to do? Do you have an example, such as pseudocode?
– l0b0
Nov 27 at 0:52
If you don't understand it, it is completely okay. Just leave it alone, do no harm, and give others a chance to answer it.
– Tim
Nov 27 at 1:20
If you don't understand it, it is completely okay. Just leave it alone, do no harm, and give others a chance to answer it.
– Tim
Nov 27 at 1:20
Please help to reopen, and/or reply my question in comments. Thanks.
– Tim
Nov 27 at 12:52
Please help to reopen, and/or reply my question in comments. Thanks.
– Tim
Nov 27 at 12:52
I don't think I understand what you're trying to do either. Do you want to disown the job currently running in foreground? Why? Is that because you want it to survive if the interactive shell waiting for it is killed.
– Stéphane Chazelas
Nov 27 at 14:06
I don't think I understand what you're trying to do either. Do you want to disown the job currently running in foreground? Why? Is that because you want it to survive if the interactive shell waiting for it is killed.
– Stéphane Chazelas
Nov 27 at 14:06
1
1
The foreground process group is an attribute of the terminal device, it's the foreground process group of a terminal, not of a shell. See
tcsetpgrp() and tgetpgrp() (which are libc functions eventually doing ioctl() on the tty device on Linux at least). You may want to revisit What are the responsibilities of each Pseudo-Terminal (PTY) component (software, master side, slave side)?– Stéphane Chazelas
Nov 27 at 15:13
The foreground process group is an attribute of the terminal device, it's the foreground process group of a terminal, not of a shell. See
tcsetpgrp() and tgetpgrp() (which are libc functions eventually doing ioctl() on the tty device on Linux at least). You may want to revisit What are the responsibilities of each Pseudo-Terminal (PTY) component (software, master side, slave side)?– Stéphane Chazelas
Nov 27 at 15:13
|
show 5 more comments
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
2
What are you trying to do? Do you have an example, such as pseudocode?
– l0b0
Nov 27 at 0:52
If you don't understand it, it is completely okay. Just leave it alone, do no harm, and give others a chance to answer it.
– Tim
Nov 27 at 1:20
Please help to reopen, and/or reply my question in comments. Thanks.
– Tim
Nov 27 at 12:52
I don't think I understand what you're trying to do either. Do you want to disown the job currently running in foreground? Why? Is that because you want it to survive if the interactive shell waiting for it is killed.
– Stéphane Chazelas
Nov 27 at 14:06
1
The foreground process group is an attribute of the terminal device, it's the foreground process group of a terminal, not of a shell. See
tcsetpgrp()andtgetpgrp()(which are libc functions eventually doingioctl()on the tty device on Linux at least). You may want to revisit What are the responsibilities of each Pseudo-Terminal (PTY) component (software, master side, slave side)?– Stéphane Chazelas
Nov 27 at 15:13