This is the mail archive of the cygwin-xfree mailing list for the Cygwin XFree86 project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Xterm hangs with latest Cygwin (-62?)

On Oct  5 10:20, Andy Koppe wrote:
> 2009/10/5 Corinna Vinschen:
> > There's a difference, though, when starting xterm via the `run -p xterm
> > -ls' shortcut. ?With Cygwin -61, xterm just starts tcsh and it works,
> > with Cygwin -62, xterm tries to start the shell via luit, and that
> > fails. ?If luit is missing on the system (renamed), xterm starts with
> > a message "Can't execvp /usr/bin/luit: No such file or directory", and
> > then starts tcsh just fine afterwards.
> >
> > Since there's no difference otherwise, it's not clear to me why this
> > occurs. ?In both cases the locale is set to the default "C" locale.
> Perhaps its behaviour depends on MB_CUR_MAX?

Probably, but that's not the actual problem.  The same happens in any
other, valid non-C locale, evey time tcsh is started via luit.

I digged deeper into this and it appears to be a bug in luit in the
first place.  In the second place it appears to be a bug in Cygwin as
well.  In the third place tcsh is not as smart as bash making the
current terminal on the stdio descriptors its controlling tty.

What happens is this, somewhat simplified:

Xterm creates a pty, make that the controlling tty and starts luit.
Luit creates another pty to run tcsh in it:

  /* Give up own controlling tty. */
  close (0);
  close (1);
  close (2);
  /* Set process group to own pid and set controlling tty to -1. */
  setsid ();
  /* Open tty as non-controlling tty. */
  new_tty = open (line, O_RDWR | O_NOCTTY);
  /* Make new tty controlling tty. */
  #ifdef TIOCSCTTY 
    ioctl(tty, TIOCSCTTY, (char *)0);

And here's the problem.  Cygwin doesn't have TIOCSCTTY, and the only way
to make a terminal a controlling tty in Cygwin is to call open() on it,
which tcsh misses to do.  Bash, however, calls open("/dev/tty", O_RDWR),
so bash doesn't have this problem.

Unfortunately, luit has no alternative way to make the new tty the
controlling tty.  What we need is a patch like this in luit:

--- sys.c.ORIG	2009-10-05 19:23:58.000000000 +0200
+++ sys.c	2009-10-05 19:18:34.000000000 +0200
@@ -408,7 +408,11 @@ openTty(char *line)
     int rc;
     int tty = -1;
+#ifdef __CYGWIN__
+    tty = open(line, O_RDWR);
     tty = open(line, O_RDWR | O_NOCTTY);
     if(tty < 0)
         goto bail;

This works fine for me with tcsh now as well.  This patch is really
important, since not only tcsh is affected by this.  If you call, for
instance, `xterm -e /bin/vim', vim works, but it has no controlling tty
either, as easily visible in `ps -e' output.  So a patch to tcsh would
only fix this for tcsh, but not for any other application.

As for the Cygwin bug, it has to do with the return value of tcgetpgrp,
which appears to be incorrect in a couple of situations.  I'm not
quite sure how to explain this, yet, nor if I really understood it.
I'll follow up on this later this week on the cygwin-developers list.

Yaakov, could you please generate a new luit package with the above


P.S: I had to build luit manually for testing.  Building with cyport
failed: error: must install xorg-macros 1.3 or later before
  running autoconf/autogen

Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]