From:	pd AT kubism DOT ku DOT dk (Peter Dalgaard BSA)
Subject:	Re: Bash bug wth read
28 Jan 1997 02:56:02 -0800 :
Approved:	cygnus DOT gnu-win32 AT cygnus DOT com
Distribution:	cygnus
Message-ID:	<x2ybdejf1k.fsf.cygnus.gnu-win32@bush.kubism.ku.dk>
References:	<01BC0B86 DOT D4EA9D80 AT wayned DOT sc DOT scruznet DOT com>
	<32ECF113 DOT 62D8 AT chromatic DOT com>
Original-To:	gnu-win32 AT cygnus DOT com
In-Reply-To:	Shankar Unni's message of Mon, 27 Jan 1997 10:16:51 -0800
X-Mailer:	Gnus v5.2.40/Emacs 19.34
Original-Sender:	owner-gnu-win32 AT cygnus DOT com

Shankar Unni <shankar AT chromatic DOT com> writes:

> 
> Running "./script < /dev/tty" gives:
> 
> one:
> two: <wait for return>
> three: <wait for return>
> four: <wait for return>
> 
> etc.
> 
> The first one suggests that someone's shoving a "<cr><nl>" down the pipe
> when starting up. Also, when the user hits <return>, a "<cr><nl>" is
> being sent that gets interpreted as two EOLs.
> 
> The second one suggests that when reading directly from /dev/tty,
> somehow, things are being cooked properly (<cr><nl> -> <nl>), but that
> the initial <cr><nl> down the pipe is still happening..

This makes it almost certain that the problem is that readline is not
cooking properly. Either it should explicitly gobble LF-after-CR, or
there's somthing wrong with the tty controls. 

On unixen, "cmd < /dev/tty" is not making any visible difference; why
does it do it here?

What happens if you execute "bash < /dev/tty" and *then* ./script ?  

-- 
   O__  ---- Peter Dalgaard             Blegdamsvej 3  
  c/ /'_ --- Dept. of Biostatistics     2200 Cph. N   
 (*) \(*) -- University of Copenhagen   Denmark      Ph: (+45) 35327918
~~~~~~~~~~ - (p DOT dalgaard AT biostat DOT ku DOT dk)             FAX: (+45) 35327907
-
For help on using this list, send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".

- Raw text -