Cygwin Subprocesses on XEmacs

Vin Shelton
Thu Jan 29 03:33:00 GMT 2015

Dear Corinna, et al -

On Wed, Jan 28, 2015 at 8:58 AM, Corinna Vinschen wrote:
> On Jan 28 08:20, Vin Shelton wrote:
>> 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.  :-)
> LOL.

After thinking about this for awhile, it dawned on me that the problem
is not with setsid() per se, but rather with the sequence of events
_following_ the setsid() call.  That is, setsid() causes some of the
ensuing ioctl() (or similar) calls that set up the pty to fail.

I think I have verified this behavior - I restored the old sysdep.c
module and moved the disconnect_controlling_terminal() call [which
calls setsid()] from right after the fork() to just before the exec()
call and M-x shell works on Cygwin as it always has on linux.

I will endeavor to create a STC for Cygwin that includes all the code
involved in setting up the terminal so we can experiment with moving
the setsid() call between the beginning and the end of the function.

  - Vin

More information about the Cygwin-apps mailing list