Re: Cygwin Subprocesses on XEmacs
Volker - On Fri, Jan 30, 2015 at 10:51 AM, Dr. Volker Zell wrote: I downloaded the latest version 21.4.23 and tried to build it, but I consistently get: gcc -c -ggdb -O2 -pipe -Wimplicit-function-declaration -fdebug-prefix-map=/cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/build=/usr/src/debug/xemacs-21.4.22-2 -fdebug-prefix-map=/cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22=/usr/src/debug/xemacs-21.4.22-2 -Demacs -I. -DHAVE_CONFIG_H -Wno-sign-compare -fno-caller-saves dump-id.c gcc -ggdb -O2 -pipe -Wimplicit-function-declaration -fdebug-prefix-map=/cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/build=/usr/src/debug/xemacs-21.4.22-2 -fdebug-prefix-map=/cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22=/usr/src/debug/xemacs-21.4.22-2 -o xemacs abbrev.o alloc.o blocktype.o buffer.o bytecode.o callint.o callproc.o casefiddle.o casetab.o chartab.o cmdloop.o cmds.o console.o console-stream.o data.o device.o dired.o doc.o doprnt.o dynarr.o editfns.o elhash.o emacs.o eval.o events.o filelock.o ntplay.o dumper.o scrollbar-msw.o menubar-msw.o toolbar-msw.o dialog-msw.o console-msw.o device-msw.o event-msw.o frame-msw.o objects-msw.o select-msw.o redisplay-msw.o glyphs-msw.o gui-msw.o balloon_help.o balloon-x.o dragdrop.o eldap.o postgresql.o dgif_lib.o gif_io.o menubar.o scrollbar.o dialog.o toolbar.o menubar-x.o scrollbar-x.o dialog-x.o toolbar-x.o gui-x.o mule.o mule-ccl.o mule-charset.o file-coding.o input-method-xlib.o realpath.o getloadavg.o inline.o nas.o console-tty.o device-tty.o event-tty.o frame-tty.o objects-tty.o redisplay-tty.o cm.o terminfo.o event-unixoid.o database.o process-unix.o event-stream.o extents.o faces.o fileio.o filemode.o floatfns.o fns.o font-lock.o frame.o general.o glyphs.o glyphs-eimage.o glyphs-widget.o gui.o gutter.o hash.o imgproc.o indent.o insdel.o intl.o keymap.o line-number.o lread.o lstream.o macros.o marker.o md5.o minibuf.o objects.o opaque.o print.o process.o profile.o rangetab.o redisplay.o redisplay-output.o regex.o search.o select.o signal.o sound.o specifier.o strftime.o symbols.o syntax.o sysdep.o undo.o console-x.o device-x.o event-Xt.o frame-x.o glyphs-x.o objects-x.o redisplay-x.o select-x.o xgccache.o widget.o window.o win32.o xemacs_res.o lastfile.o gmalloc.o vm-limit.o EmacsFrame.o EmacsShell.o TopLevelEmacsShell.o TransientEmacsShell.o EmacsManager.o offix.o dump-id.o ../lwlib/liblw.a -laudio -lXaw3d -lXaw3d -ltiff -lpng -ljpeg -lz -lcompface -lXpm -lXmu -lXt -lXext -lX11 -lSM -lICE -ldb -lncurses -lintl -lpq -lldap -llber -lwinmm -lshell32 -lgdi32 -luser32 -lcomdlg32 -lcomctl32 -lkernel32 -lwinspool collect2: error: ld terminated with signal 11 [Segmentation fault], core dumped GNUmakefile:159: recipe for target 'xemacs' failed make[1]: *** [xemacs] Error 1 make[1]: Leaving directory '/cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/build/src' GNUmakefile:123: recipe for target 'src' failed make: *** [src] Error 2 [1;31m*** ERROR: [0;0m make failed After the ld core dump, when I delete the corrupted xemacs.exe from /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/build/src manually and restart the build with make from the /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/build directory again, the build actually succeeds and ld doesn't core dump anymore. I don't see this segfault. I am running the default version of gcc, and I assume you are, too. Perhaps you need to rebaseall? Your build path is ...xemacs-21.4.22... are you sure you're using 21.4.23 sources? Additionally I had to use an older version of texinfo (namely version 4.13) otherwise the build breaks when generating the .info files (I got the information to use an older version from Vin Shelton). Yes, the texinfo incompatibilities is one reason I want to EOL 21.4. An alternative approach for Cygwin would be to patch the .texi sources to work with newer texinfos. I then installed everything and with my current setup xemacs crashed as soon as font-locking is involved. The current 32 bit xemacs-21.4.22 version works fine with this setup. After googling around I found a workaround by setting (setq progress-feedback-use-echo-area t) in my .emacs. This error should be fixed in 21.4.23, there's a new configure.in/configure designed to prevent this. Again - are you sure you're using 21.4.23? So, the good news finally after 6 years !!! it seems I have a working xemacs on 32 bit which runs on cygwin 1.7.x. Of course I will need to do more testing. The bad news, an automatic build via cygport is currently not possible because: 1. cygport's compile stage bails out after the ld core dump 2. the current xemacs version needs an older version of texinfo (4.13) than we have currently in the distribution (5.2-3) Question: How shall I proceed ? - Vin
Re: Cygwin Subprocesses on XEmacs
Vin Shelton writes: I don't see this segfault. I am running the default version of gcc, and I assume you are, too. Perhaps you need to rebaseall? I'm using the latest gcc-4.9.2 Your build path is ...xemacs-21.4.22... are you sure you're using 21.4.23 sources? Yes...I copied from the wrong log file (that was the latest build from the hg repository I did before you released 21.4.23). But in the latest version I get the exact error. I then installed everything and with my current setup xemacs crashed as soon as font-locking is involved. The current 32 bit xemacs-21.4.22 version works fine with this setup. After googling around I found a workaround by setting (setq progress-feedback-use-echo-area t) in my .emacs. This error should be fixed in 21.4.23, there's a new configure.in/configure designed to prevent this. Again - are you sure you're using 21.4.23? Yes...my current xemacs just spits out XEmacs 21.4 (patch 23) Moral Majoritywhen using M-X: emacs-version - Vin Ciao Volker
Re: Cygwin Subprocesses on XEmacs
Vin Shelton writes: On Thu, Jan 29, 2015 at 4:39 AM, Corinna Vinschen wrote: On Jan 28 22:32, Vin Shelton wrote: 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. Good news! So the XEmacs code is in a state now that Volker can start creating a Cygwin package? Yes, the 21.4 code in the hg repository builds and runs on Cygwin. I downloaded the latest version 21.4.23 and tried to build it, but I consistently get: gcc -c -ggdb -O2 -pipe -Wimplicit-function-declaration -fdebug-prefix-map=/cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/build=/usr/src/debug/xemacs-21.4.22-2 -fdebug-prefix-map=/cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22=/usr/src/debug/xemacs-21.4.22-2 -Demacs -I. -DHAVE_CONFIG_H -Wno-sign-compare -fno-caller-saves dump-id.c gcc -ggdb -O2 -pipe -Wimplicit-function-declaration -fdebug-prefix-map=/cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/build=/usr/src/debug/xemacs-21.4.22-2 -fdebug-prefix-map=/cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22=/usr/src/debug/xemacs-21.4.22-2 -o xemacs abbrev.o alloc.o blocktype.o buffer.o bytecode.o callint.o callproc.o casefiddle.o casetab.o chartab.o cmdloop.o cmds.o console.o console-stream.o data.o device.o dired.o doc.o doprnt.o dynarr.o editfns.o elhash.o emacs.o eval.o events.o filelock.o ntplay.o dumper.o scrollbar-msw.o menubar-msw.o toolbar-msw.o dialog-msw.o console-msw.o device-msw.o event-msw.o frame-msw.o objects-msw.o select-msw.o redisplay-msw.o glyphs-msw.o gui-msw.o balloon_help.o balloon-x.o dragdrop.o eldap.o postgresql.o dgif_lib.o gif_io.o menubar.o scrollbar.o dialog.o toolbar.o menubar-x.o scrollbar-x.o dialog-x.o toolbar-x.o gui-x.o mule.o mule-ccl.o mule-charset.o file-coding.o input-method-xlib.o realpath.o getloadavg.o inline.o nas.o console-tty.o device-tty.o event-tty.o frame-tty.o objects-tty.o redisplay-tty.o cm.o terminfo.o event-unixoid.o database.o process-unix.o event-stream.o extents.o faces.o fileio.o filemode.o floatfns.o fns.o font-lock.o frame.o general.o glyphs.o glyphs-eimage.o glyphs-widget.o gui.o gutter.o hash.o imgproc.o indent.o insdel.o intl.o keymap.o line-number.o lread.o lstream.o macros.o marker.o md5.o minibuf.o objects.o opaque.o print.o process.o profile.o rangetab.o redisplay.o redisplay-output.o regex.o search.o select.o signal.o sound.o specifier.o strftime.o symbols.o syntax.o sysdep.o undo.o console-x.o device-x.o event-Xt.o frame-x.o glyphs-x.o objects-x.o redisplay-x.o select-x.o xgccache.o widget.o window.o win32.o xemacs_res.o lastfile.o gmalloc.o vm-limit.o EmacsFrame.o EmacsShell.o TopLevelEmacsShell.o TransientEmacsShell.o EmacsManager.o offix.o dump-id.o ../lwlib/liblw.a -laudio -lXaw3d -lXaw3d -ltiff -lpng -ljpeg -lz -lcompface -lXpm -lXmu -lXt -lXext -lX11 -lSM -lICE -ldb -lncurses -lintl -lpq -lldap -llber -lwinmm -lshell32 -lgdi32 -luser32 -lcomdlg32 -lcomctl32 -lkernel32 -lwinspool collect2: error: ld terminated with signal 11 [Segmentation fault], core dumped GNUmakefile:159: recipe for target 'xemacs' failed make[1]: *** [xemacs] Error 1 make[1]: Leaving directory '/cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/build/src' GNUmakefile:123: recipe for target 'src' failed make: *** [src] Error 2 [1;31m*** ERROR:[0;0m make failed After the ld core dump, when I delete the corrupted xemacs.exe from /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/build/src manually and restart the build with make from the /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/build directory again, the build actually succeeds and ld doesn't core dump anymore. Additionally I had to use an older version of texinfo (namely version 4.13) otherwise the build breaks when generating the .info files (I got the information to use an older version from Vin Shelton). I then installed everything and with my current setup xemacs crashed as soon as font-locking is involved. The current 32 bit xemacs-21.4.22 version works fine with this setup. After googling around I found a workaround by setting (setq progress-feedback-use-echo-area t) in my .emacs. So, the good news finally after 6 years !!! it seems I have a working xemacs on 32 bit which runs on cygwin 1.7.x. Of course I will need to do more testing. The bad news, an automatic build via cygport is currently not possible because: 1. cygport's compile stage bails out after the ld core dump 2. the current xemacs version needs an older version of texinfo (4.13) than we have currently in the distribution (5.2-3) Question: How shall I proceed ? By the way, I'm off for a week. Regards, Vin Ciao Volker
Re: Cygwin Subprocesses on XEmacs
Hi Vin, On Jan 28 22:32, Vin Shelton wrote: 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? [...] 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. Good news! So the XEmacs code is in a state now that Volker can start creating a Cygwin package? 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. Ok, thanks. Hopefully we can find the snag in Cygwin. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpjF3dNvZ_LJ.pgp Description: PGP signature
Re: Cygwin Subprocesses on XEmacs
On Thu, Jan 29, 2015 at 4:39 AM, Corinna Vinschen wrote: On Jan 28 22:32, Vin Shelton wrote: 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. Good news! So the XEmacs code is in a state now that Volker can start creating a Cygwin package? Yes, the 21.4 code in the hg repository builds and runs on Cygwin. Regards, Vin
Re: Cygwin Subprocesses on XEmacs
On Jan 29 06:49, Vin Shelton wrote: On Thu, Jan 29, 2015 at 4:39 AM, Corinna Vinschen wrote: On Jan 28 22:32, Vin Shelton wrote: 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. Good news! So the XEmacs code is in a state now that Volker can start creating a Cygwin package? Yes, the 21.4 code in the hg repository builds and runs on Cygwin. Super! Thanks a lot, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgppDOSBGqaPR.pgp Description: PGP signature
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: 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
Cygwin Subprocesses on XEmacs
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.
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.
I here reproduce all of disconnect_controlling_terminal() for your
reading pleasure.
void
disconnect_controlling_terminal (void)
{
# 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
process group. */
setsid ();
# else
/* Put us in our own process group. */
EMACS_SEPARATE_PROCESS_GROUP ();
#if defined (TIOCNOTTY)
/* This is the older way of disconnecting the controlling
terminal, on 4.3 BSD. We must open /dev/tty; using
filedesc 0 is not sufficient because it could be
something else (e.g. our stdin was redirected to
another terminal).
*/
{
int j = open (/dev/tty, O_RDWR, 0);
ioctl (j, TIOCNOTTY, 0);
close (j);
}
#endif /* TIOCNOTTY */
/*
On systems without TIOCNOTTY and without
setsid(), we don't need to do anything more to
disconnect our controlling terminal. Here is
what the man page for termio(7) from a SYSV 3.2
system says:
The first terminal file opened by the process group leader
of a terminal file not already associated with a process
group becomes the control terminal for that process group.
The control terminal plays a special role in handling quit
and interrupt signals, as discussed below. The control
terminal is inherited by a child process during a fork(2).
A process can break this association by changing its process
group using setpgrp(2).
*/
# endif /* not HAVE_SETSID */
}
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.
- Vin
