mc sets process group differently from shell; forgets to close fd# 3
Pavel Tsekov
ptsekov at gmx.net
Fri Apr 20 21:00:40 UTC 2007
On Fri, 20 Apr 2007, Denis Vlasenko wrote:
> If you compile and run the following program
> under shell and under mc...
[...]
> you will see the following:
>
> bash-3.2# ./z
> pid=8183
> ppid=8181
> tty_pgrp=8183 <========== child is in its own process group
> task_pgrp=8183 <==========
> fd# 0: '/dev/pts/4'
> fd# 1: '/dev/pts/4'
> fd# 2: '/dev/pts/4'
>
> bash-3.2# echo $$ ; exec mc
> 8181
>
> # ./z
> pid=8212
> ppid=8181
> tty_pgrp=8181 <========== child is in mc's process group
> task_pgrp=8181 <========== child is in mc's process group
> fd# 0: '/dev/pts/4'
> fd# 1: '/dev/pts/4'
> fd# 2: '/dev/pts/4'
> fd# 3: '/dev/tty' <=== ??!
>
> Note that there are two differences, one minor and one pretty big.
>
> 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. Neither the child nor MC
can manipulate the foreground process group. Please, explain in
details what you mean. If can provides a simple testcase to reproduce
the problem I'd be happy to investigate.
> Big one (actually, I think it's a bug): stray fd# opened
> to controlling terminal.
/dev/tty is opened by the S-Lang library and, yes, it should
be closed when the new process executes.
More information about the mc-devel
mailing list