Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-developers-owner AT sourceware DOT cygnus DOT com
Delivered-To: mailing list cygwin-developers AT sourceware DOT cygnus DOT com
From: Chris Faylor <cgf AT cygnus DOT com>
Date: Mon, 24 May 1999 22:05:49 -0400
To: Egor Duda <deo AT logos-m DOT ru>
Cc: cygwin-developers <cygwin-developers AT sourceware DOT cygnus DOT com>
Subject: Re: bash fails to handle background jobs
Message-ID: <19990524220549.A31791@cygnus.com>
References: <15984 DOT 990523 AT logos-m DOT ru>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.3i
In-Reply-To: <15984.990523@logos-m.ru>; from Egor Duda on Sun, May 23, 1999 at 11:37:57PM +0400

This should be fixed in the latest snapshot.  After playing around with
this for hours, I finally realized that there was a very simple solution
to this problem.  I'm not sure exactly why your fix worked but it really
wasn't the proper solution -- as you intimated.

In the course of tracking this down, I found that CTRL-D wasn't properly
causing EOF when CYGWIN=tty.  That should be fixed now, too.

There is still one other tty handling bug that I have to fix when I
have spare cycles.  It is causing Xemacs to loop.  I think I've narrowed
down the problem but it will take a concerted effort to fix.

cgf

On Sun, May 23, 1999 at 11:37:57PM +0400, Egor Duda wrote:
>  Trying to run background jobs in bash causes it to exit. According
>to traces, is seems that when background job exits, pty-master writes
>dummy data to tty_slave:
>
>fhandler_pty_master::accept_input ()
>{
>  DWORD written;
>  DWORD n = eat_readahead (-1);   // returns 0;
>  const char dummy[1] = {'X'};
>  const char *buf;
>
>  if (n != 0)
>    buf = rabuf;
>  else
>    {
>      n = 1;
>      buf = dummy;
>    }
>  termios_printf ("about to write %d chars to slave", n);
>  if (!WriteFile (get_output_handle (), buf, n, &written, NULL))
>      return -1;
>  return buf == dummy ? 0 : (int)n;
>    /* returns 0, but still puts 1 byte of data into the pipe between
>     * master and slave. Later on, peek_pipe () detects this data and
>     * marks slave as "ready to read". Slave tries to read, retrives 0
>     * bytes (as long tc->read_retval is set to 0 in
>     * fhandler_termios.cc:191) and interprets it as EOF. bash sees
>     * EOF and exits.
>     */
>}
>
>Applying following patch seems to fix a problem, but it really looks
>like quick'n'dirty workaround to me. i'm not so good with tty stuff,
>so i hope someone will find a way to fix this problem properly.
>
>Index: fhandler_tty.cc
>===================================================================
>RCS file: /usr/local/src/cvs/cygnus/cygwin/winsup/fhandler_tty.cc,v
>retrieving revision 1.1.1.1
>diff -u -2 -r1.1.1.1 fhandler_tty.cc
>--- fhandler_tty.cc 1999/04/10 14:55:01 1.1.1.1
>+++ fhandler_tty.cc 1999/05/23 19:25:05
>@@ -136,5 +136,5 @@
>   else
>     {
>-      n = 1;
>+      n = 0;
>       buf = dummy;
>     }
>
>
>Egor.            mailto:deo AT logos-m DOT ru ICQ 5165414 FidoNet 2:5020/496.19