This is the mail archive of the
cygwin-developers@cygwin.com
mailing list for the Cygwin project.
Re: bash misbehavior
At 08:20 PM 9/28/2004 -0400, Christopher Faylor wrote:
>
>Can you still open a handle on a process that has exited? I can't
>remember but I think you probably can as long as there is a handle open
>to it somewhere.
Yes, I tried a simple experiment.
>So, your scheme would probably work. I just hate the
>complication, too. That's why I've never implemented anything like this.
>It's been a long time since I've thought about this problem, though. It's
>nice to have commiseration. :-)
>
>I was idly thinking that whenever a process group leader exits and
>notices that there are still unexited processes sitting around in the
>process group it could run a dummy process with a handle to the process.
>Thiw process would somehow noticed when the last referencing process
>died and would then die itself.
>
>You could run the cygwin dll itself to cause this to happen so you
>wouldn't need another .exe sitting around. I think you can use rundll32
>to do this but I've never tried it.
>
>The tricky part is having the dummy process notice when all of the other
>users of the process group have gone away. I guess you could use the
>tty technique of opening a dummy 'process group' event in all of the
>process group holders. When you can no longer open this event, all
>users of the process group have gone away.
Yep, that would work too, but it's costly. In bash there is a new
process group leader for every command/pipeline
I will leave this issue simmer for a while.
I also tried your patch:
~: true | `echo true` &
[1] 616139
But
~: sleep 1 | `echo true` &
[2] 621615
[1] Done true | `echo true`
~: Use "logout" to leave the shell.
That was predictable. In bash the first process of a pipeline
is the group leader. If it lingers, your patch does not kick in
and the tcsetpgrp() that shouldn't happen succeeds.
At this point I think it's a bash bug, and I don't see anything
specific to Cygwin that triggers it !!!
I will write to the bash maintainer, with cc to this list.
Pierre