Mail Archives: djgpp/1998/03/30/12:01:01
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 -