Hi, Corinna et al,
On Wed, Jan 28, 2015 at 4:53 AM, Corinna Vinschen wrote:
> On Jan 27 23:05, Vin Shelton wrote:
>> I spent some time debugging M-x shell in XEmacs on 32-bit Cygwin.
>> Here's what I found out.
>>
>> In the child after fork() but before exec(), the setsid() call in
>> disconnect_controlling_terminal() is causing the subprocess not to
>> function after it gets spawned.
>
> Can you define "not function" a bit more detailed? Does no process work
> at all, or do only processes requiring a tty not work? For instance,
> does something like an "echo foo > bar" still work?
M-x shell is specifically designed to spawn an interactive process
like a shell. The bash subprocess starts, but it accepts no input.
Here is the output of ps for that process:
S 1740 252 1740 268 pty1 1003 08:10:54 /usr/bin/bash
I think it's only commands requiring a tty, but that's the whole point
of M-x shell mode. There is a separate command - M-x shell-command -
which is designed to run and capture the output of individual commands
like "ls" or "echo". That works fine.
BTW, if I try to spawn gdb as a shell, the behavior is similar, but
this time the process looks like this:
3328 3248 3328 3408 pty2 1003 08:15:18
/usr/bin/gdb <defunct>
HTH.
>>
>> Thanks for any insight you can offer.
>
> Hmm, not off the top of my head. Is there a chance that you could
> provide a simple, self contained testcase to reproduce the setsid
> behaviour? I think I have to debug that.
You mean a simpler test case than XEmacs? That seems like a low bar. :-)
I'll try. Meanwhile, I've been looking at the emacs code (which in
this case is simpler) to see if I can figure out how it is that M-x
shell works there.
Thank you!
- Vin
