Message-Id:	<199803301730.TAA48088@ieva06.lanet.lv>
From:	"Andris Pavenis" <pavenis AT lanet DOT lv>
To:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
Date:	Mon, 30 Mar 1998 20:27:46 +0000
MIME-Version:	1.0
Subject:	Re: "bash"ing "cat"s.
CC:	djgpp AT delorie DOT com
References:	<199803301513 DOT RAA34720 AT ieva06 DOT lanet DOT lv>
In-reply-to:	<Pine.SUN.3.91.980330195100.20942B@is>

From:          Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
> 
> 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!

Yes it work if stdout (or stderr if we are using it) is not redirected to 
file. So if we want to be sure ^Z will be cleared we should also test 
whether the file is really console.

> 
> 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.
> 

As I tested 'bash >xxxx' does not work. So perhaps all will de Ok.

Andris 

- Raw text -