Date: Mon, 30 Mar 1998 20:00:32 +0300 (IDT) From: Eli Zaretskii To: Andris Pavenis cc: djgpp AT delorie DOT com Subject: Re: "bash"ing "cat"s. In-Reply-To: <199803301513.RAA34720@ieva06.lanet.lv> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk 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.