Date:	Mon, 30 Mar 1998 20:00:32 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To:	Andris Pavenis <pavenis AT lanet DOT lv>
cc:	djgpp AT delorie DOT com
Subject:	Re: "bash"ing "cat"s.
In-Reply-To:	<199803301513.RAA34720@ieva06.lanet.lv>
Message-ID:	<Pine.SUN.3.91.980330195100.20942B@is>
MIME-Version:	1.0

On Mon, 30 Mar 1998, Andris Pavenis wrote:

> Looks also that outputing at least one byte to stdout or stderr fixes 
> problem (WHY??).

This seems to be the reason.  I threw together a small command 
interpreter which can launch programs and with its help have verified 
that writing to stdout clears the ^Z from stdin buffer.  Moreover, even 
writing ZERO bytes to stdout (try using `_write' to handle 1 with the 
last argument 0) solves the problem!

So it seems like this is some undocumented feature of the CON device 
driver: writing to it empties its buffer, at least when the buffer only 
contains ^Z.  (I say ``undocumented'' because I couldn't find any hint 
about this in all of my references.)

> COMMAND.COM outputs DOS prompt, so the problem is
> fixed for this time.

Significantly, COMMAND.COM uses function 40h of Interrupt 21h to write 
CRLF before the prompt.  And that write clears the buffer (`_write' also 
calls that function).

> Perhaps NC or FAR does not use DOS console output 
> functions. I don't still understand why this problem appears with bash.

Because Bash also doesn't use DOS I/O for screen input/output.  AFAIK, it 
uses the termios functions to do that.  The catch is that the DJGPP 
implementation of termios works around DOS, it uses BIOS functions 
instead.  These functions bypass the CON device driver, and thus don't 
clear the stdin buffer.

Thanks for working on this, it seems like the problem is now understood a 
whole lot better.  Adding a zero-byte write to stdout to Bash should 
solve that problem, I think.

- Raw text -