From: shankar AT chromatic DOT com (Shankar Unni)
Subject: Re: Bash bug wth read
27 Jan 1997 12:30:10 -0800
Approved: cygnus DOT gnu-win32 AT cygnus DOT com
Distribution: cygnus
Message-ID: <32ECF113.62D8.cygnus.gnu-win32@chromatic.com>
References: <01BC0B86 DOT D4EA9D80 AT wayned DOT sc DOT scruznet DOT com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 3.0Gold (X11; I; SunOS 5.5.1 sun4u)
Original-To: Wayne Davison <wayne AT clari DOT net>
Original-CC: gnu-win32 AT cygnus DOT com
Original-Sender: owner-gnu-win32 AT cygnus DOT com

Wayne Davison wrote:

> Is anyone else having trouble with "read" in a /bin/sh script?  The code is
> apparently reading extra newlines.  

> [ Code deleted ]

> one: two:
> three: four:            [User presses return]
> five: six:                      [User presses return]
> seven: eight:           [User presses return]
> done

I've seen different behavior on Windows 95. 

Running "bash script" from command.com (win95) or "./script" from bash
gives
one:
two: three: <wait for return>
four: five: <wait for return>

etc.

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

-- 
Shankar Unni                                  shankar AT chromatic DOT com
Chromatic Research                            (408) 752-9488
-
For help on using this list, send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".