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
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
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>
Precedence: bulk

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