This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: Cygwin Subprocesses on XEmacs
- From: Vin Shelton <acs at xemacs dot org>
- To: cygwin-apps at cygwin dot com, XEmacs developers <xemacs-beta at xemacs dot org>
- Date: Wed, 28 Jan 2015 22:32:55 -0500
- Subject: Re: Cygwin Subprocesses on XEmacs
- Authentication-results: sourceware.org; auth=none
- References: <CACeGjnWqVT5DJX+PUnic-mNu3WkpF1DPa_FVJQsSX_QHb+DKTw at mail dot gmail dot com> <20150128095323 dot GU14265 at calimero dot vinschen dot de> <CACeGjnXnjcEzU+H4Xe-0L6SsgNFfu4-usLdOBFZ4c4fPwGzPzg at mail dot gmail dot com> <20150128135804 dot GC14265 at calimero dot vinschen dot de>
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