Timeline for Why does bash (executing the script) stay in the foreground group when executing commands in a script?
Current License: CC BY-SA 4.0
10 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 19 at 14:07 | comment | added | Yakog | Yap, that could be an answer, but I think that it (job control) is not completely useless within script, since by moving from background to foreground and vice verse you are controlling which processes can send/read to/from terminal | |
| Feb 19 at 13:38 | comment | added | grawity | I guess the counter-question is why would it do that? As I said, when it is interpreting a script, it itself is the job - it is already running under job control, and it cannot usefully manage jobs since it's not interactive and doesn't take user input from which to fg/bg a certain job; what purpose would it have to "take over" job control in the first place? | |
| Feb 19 at 13:18 | comment | added | Yakog | Thanks, asking about one topic I learned about another :D However, my question still remains (for what reason does bash remain in the same group as command, and not just to turn on job control and to move itself to the foreground/background...) | |
| Feb 19 at 12:51 | comment | added | grawity |
Yes. They're intertwined of course (when job control is available, then each &-command becomes tracked as a job, etc.) but I'm pretty sure it predates the existence of tty job control in Unix shells – after all, it doesn't rely on any other feature except the creation of processes. (Which means it can also work even when there is no controlling tty at all.)
|
|
| Feb 19 at 12:44 | comment | added | Yakog |
So, & is a concept by itself where it allows programs to be executed asynchronously, it is not related to (part of) job control. If job control is on, then calling a command with & will additionally result in a new group/job being created for each command etc., but & is still a concept for itself ... Am I right?
|
|
| Feb 19 at 12:38 | comment | added | grawity |
Without & the interpreter forks, execs the program, and the parent process waits for the child to exit/return before proceeding with the next script statement. With & the interpreter forks, execs the program, and the parent process doesn't wait for the child to exit/return – that's the only difference. Instead it stores the PID in $! and immediately carries on with the next statement. (Though it can be asked to do so explicitly, using the wait builtin.)
|
|
| Feb 19 at 12:25 | comment | added | Yakog |
After trying some examples, it looks like you are correct about job control within script. You can't do it (fg command doesn't work; error: "fg: no job control"). However, then I don't get what is the difference between starting command with & and without within script.
|
|
| Feb 19 at 12:19 | comment | added | grawity |
Thanks for the correction. But starting commands with & does not imply job control; it's achieved with the same basic fork/exec/waitpid.
|
|
| Feb 19 at 12:14 | comment | added | Yakog |
Shell doesn't need to be a session leader to perform a job control. Look at this Stéphane Chazelas's answer. Cite: "When you start xterm, xterm runs your shell (by default) in the new process that it starts in a new session and that will control the pseudo-terminal slave device. Then that shell will be the session leader. But if you start another interactive shell from that shell, it will not be session leader but will take over job control." Also, it can do a job control since you can start command asynchronously in the script via &.
|
|
| Feb 19 at 12:09 | history | answered | grawity | CC BY-SA 4.0 |