Mail Archives: djgpp/1998/03/24/10:11:40
From: | Ned Ulbricht <nedu AT ee DOT washington DOT edu>
|
Newsgroups: | comp.os.msdos.djgpp
|
Subject: | bash$ cat -
|
Date: | Mon, 23 Mar 1998 13:33:04 -0800
|
Organization: | University of Washington
|
Lines: | 54
|
Message-ID: | <3516D510.35CB@ee.washington.edu>
|
NNTP-Posting-Host: | cs209-75.student.washington.edu
|
Mime-Version: | 1.0
|
To: | djgpp AT delorie DOT com
|
DJ-Gateway: | from newsgroup comp.os.msdos.djgpp
|
(See below for cat/bash version info)
When using cat within bash to read from stdin
bash$ cat -
then after terminating the input with ^Z (either keyboard ctrl-Z or F6),
subsequent cat's from stdin
bash$ cat -
result in cat returning immediately without accepting input.
However, if either
bash$ cat - < con
or
bash$ cat foo.fil
(foo.fil may or may not exist)
are issued, then they succeed and so does the very next
bash$ cat -
Note that the behavior seems identical for
bash$ cat -<CR>
bash$ cat<CR>
bash$ cat<SP><CR>
Also, this behavior does not occur under either COMMAND.COM (MS-DOS 6.20)
or under NDOS (Norton Utilities ver 8.0).
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.
cat.exe 61,952 02-08-97 5:54p CRC-32=93341d32
precompiled binary from SimtelNet txt122b.zip
bash.exe 403,968 04-19-97 10:03p CRC-32=7e62c73e
precompiled binary from SimtelNet bsh1147b.zip
Let me know if this is not reproducible, so I can dig deeper & then post
more info.
(Aside from this, it seems from the list archive/DejaNews that Daisuke
Aoyama hasn't posted since about last November. Is he or anyone else
still working on a bash 2 port?)
--
Ned Ulbricht
mailto:nedu AT ee DOT washington DOT edu
- Raw text -