On Friday 20 April 2007 23:00, Pavel Tsekov wrote: > > Small one: child process is not given its own porcess group when run > > under mc, while under sh it is. It means that if child will create its > > Yes - because, you have a shell which supports job control. > > > own process group by itself and then die, under shell it works but > > under mc mc will auto-background itself on child's death, > > because tty's pgrp will not match mc's. Nasty. > > I am confused a bit by the statement above. The foreground process > group (tty's pgrp) is controlled by the process which has the > controlling terminal - the shell itself.
Parent and children aren't different here. They both can manipulate ctty's pgrp. Whenever you run a pipe from shell: # sleep 1 | sleep 2 shell creates new process group. First process in pipe (sleep 1) with pid=pid1 will become process group leader by executing setpgrp(0, 0); 2nd, 3rd and so on processes (sleep 2 above) will join this process group by doing setpgrp(0, pid1), and all these child processes can switch tty pgrp to pid1 by doing tcsetpgrp(ctty_fd, pid1). (In theory just one child can do it, but because of possible races all children do it, in parallel). This will make parent shell process to become _backgrounded_ (because parent process is *not* in pid1 process group, which is the foreground group now). Note that this process group switch is done *by children*, not parent. (However, parent can do it too for paranoid reasons, and parent definitely will want to re-foreground itself when all children exit). > Neither the child nor MC > can manipulate the foreground process group. Yes it can. I spent entire day doing exactly this while I was fixing a shell from busybox project. It works. > Please, explain in > details what you mean. If can provides a simple testcase to reproduce > the problem I'd be happy to investigate. Simple: start bash from mc, and kill it so that it (bash) have no chance to restore tty's pgrp: # mc # bash bash-3.2# kill -KILL $$ [1]+ Stopped mc # _ See? mc is backgrounded! This is how it should work (and in fact works when parent is a shell, not mc): # bash bash-3.2# kill -KILL $$ Killed <=========== parent shell reports exit status of child # _ Parent shell has recovered (did not end up backgrounded), because it brought itself to foreground (did tcsetpgrp(ctty_fd, parent_pid)) after child exited. -- vda _______________________________________________ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
