Date: Wed, 25 Mar 1998 16:07:41 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: Nate Eldredge <eldredge AT ap DOT net>
cc: Ned Ulbricht <nedu AT ee DOT washington DOT edu>, djgpp AT delorie DOT com
Subject: Re: bash$ cat -
In-Reply-To: <199803250555.VAA20288@adit.ap.net>
Message-ID: <Pine.SUN.3.91.980325160401.28802M-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Precedence: bulk


On Tue, 24 Mar 1998, Nate Eldredge wrote:

> >It seems to me that this is likely caused by the ^Z remaining buffered
> >somewhere in the input stream and being resent to cat on the subsequent
> >invocations under bash.
> 
> That seems unlikely to me, since this doesn't happen with any other of the
> textutils. (I checked.) Strange.

`cat' is unlike other Textutils: it pulls out a few tricks at startup 
that other Textutils don't.  (That's because `cat' is used both to print 
files to the screen and to copy/concatenate disk files, and it needs to 
do reasonable things in both cases.)  You can look in the sources to see 
what exactly.

However, there's no way known to me that a program can leave something in 
the stdin stream for its next invocation.  So it's probably some 
assumption in Bash that `cat' breaks that causes this.  Unfortunately, 
I'm not at liberty now to debug this.