Re: Cygwin Subprocesses on XEmacs
On Jan 28 08:20, Vin Shelton wrote: 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: S1740 2521740268 pty11003 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: 332832483328 3408 pty21003 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. Btw., a testcase which avoids to fork would be nice. It's much easier to debug due to GDBs inability to follow fork on Cygwin :( 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. Good idea. This might give us a clue. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp8Vp35AD4hs.pgp Description: PGP signature
Re: Cygwin Subprocesses on XEmacs
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: S1740 2521740268 pty11003 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: 332832483328 3408 pty21003 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
Re: Cygwin Subprocesses on XEmacs
Hi Vin,
first of all, I haven't looked into the affected piece of code in Cygwin
for a long time, and it was never my domain, so bear with me.
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?
Here is a patch which works around the problem, enabling M-x shell to
work for bash and zsh (at least):
diff -r 00f2705e2cb3 src/sysdep.c
--- a/src/sysdep.c Mon Jan 26 08:53:07 2015 -0500
+++ b/src/sysdep.c Tue Jan 27 22:15:16 2015 -0500
@@ -1319,7 +1319,7 @@
void
disconnect_controlling_terminal (void)
{
-# ifdef HAVE_SETSID
+# if defined(HAVE_SETSID) !defined(CYGWIN)
/* Controlling terminals are attached to a session.
Create a new session for us; it will have no controlling
terminal. This also, of course, puts us in our own
HOWEVER - I don't understand why this should be necessary.
[...]
Since Cygwin doesn't seem to have TIOCNOTTY, commenting out the
setsid() call reduces disconnect_controlling_terminal to:
void
disconnect_controlling_terminal (void)
{
# 1330 sysdep.c
setpgid (0, 0);
# 1362 sysdep.c
}
Incidentally, that setpgid() call causes bash to complain at startup:
bash: cannot set terminal process group (-1): Inappropriate ioctl for device
bash: no job control in this shell
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.
Thanks,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
pgpWH_wHcgpoo.pgp
Description: PGP signature
Re: Updated: [32-bit] libreadline7-6.1.2-4, libreadline-devel-6.1.2-4
On Jan 27 16:06, Eric Blake wrote: On 01/27/2015 03:57 PM, Eric Blake (cygwin) wrote: This is a minor rebuild to sort out packaging issues and refresh against newer cygwin (no source changes). I have renamed the development package from 'readline' to 'libreadline-devel', to match the naming convention already in the 64-bit build. I updated the following setup.hint entries in the 32-bit repository to change 'readline' to 'libreadline-devel'; you should update your local copy before your next, and evaluate if the dependency still makes sense. octave/octave-devel - orphan (Reini) parrot/parrot-devel - Marco Atzeri Vice versa :) Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp4FQ1Qii67Z.pgp Description: PGP signature
Re: Setup patch to keep test version if test version installed
On Jan 27 22:14, Corinna Vinschen wrote: On Jan 27 22:04, Achim Gratz wrote: Corinna Vinschen writes: Or today. Can you try this patch? Most of it is a bit of reformatting, the importnat part is the last set_action call. I think I'll get this wedged in sometime tomorrow. Thanks. I think I have a better one, though. The CleanOrphansOption in cinjunction of not having a curr package should immediately trigger the packagemeta::Uninstall_action: Index: choose.cc === RCS file: /cvs/cygwin-apps/setup/choose.cc,v retrieving revision 2.169 diff -u -p -r2.169 choose.cc --- choose.cc 26 Jan 2015 21:05:45 - 2.169 +++ choose.cc 27 Jan 2015 21:12:01 - @@ -252,19 +252,22 @@ ChooserPage::OnInit () bool deleted = pkg.isManuallyDeleted(); bool basemisc = (pkg.categories.find (Base) != pkg.categories.end () || pkg.categories.find (Misc) != pkg.categories.end ()); - bool current = pkg.curr || CleanOrphansOption; - bool upgrade = wanted || (!pkg.installed basemisc) || UpgradeAlsoOption || !hasManualSelections; + bool upgrade = wanted || (!pkg.installed basemisc) + || UpgradeAlsoOption || !hasManualSelections; bool install = wanted !deleted !pkg.installed; bool reinstall = (wanted || basemisc ) deleted; - bool uninstall = !(wanted || basemisc ) deleted; + bool uninstall = (!(wanted || basemisc ) deleted) +|| (!pkg.curr CleanOrphansOption); if (install) - pkg.set_action( packagemeta::Install_action, pkg.curr ); + pkg.set_action (packagemeta::Install_action, pkg.curr); else if (reinstall) - pkg.set_action( packagemeta::Reinstall_action, pkg.curr ); + pkg.set_action (packagemeta::Reinstall_action, pkg.curr); else if (uninstall) - pkg.set_action( packagemeta::Uninstall_action, packageversion() ); + pkg.set_action (packagemeta::Uninstall_action, packageversion ()); else - pkg.set_action( packagemeta::Default_action, ((upgrade current) ? pkg.trustp (true, TRUST_UNKNOWN) : pkg.installed) ); + pkg.set_action (packagemeta::Default_action, + upgrade ? pkg.trustp (true, TRUST_UNKNOWN) + : pkg.installed); } ClearBusy (); This test release has another puzzeling problem I have to figure out yet. For some reason, it's impossible to downgrade packages at all. Worse, if you try that, it will remove the package. That's a rather weird side effect of my changes, which were only supposed to change the selection method, not the underlying workings. Oh well. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpkSqZBL81eQ.pgp Description: PGP signature
Re: Setup patch to keep test version if test version installed
Corinna Vinschen writes: This version also introduces an experimental option -m/--mirror-mode. Thank you for this! Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Waldorf MIDI Implementation additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs
Re: Cygwin Subprocesses on XEmacs
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: S1740 2521740268 pty11003 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: 332832483328 3408 pty21003 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
