Mail Archives: djgpp/1998/04/01/09:46:22
On Wed, 1 Apr 1998, Mahadevan R. wrote:
> I thought handle 0 was CON opened read-only.
If you can write to it, it wasn't, right?
The read-only bit in the case of the device is handled by the device
driver, which seemingly doesn't care.
> You just lost yourself a bet.
So I will never bet again ;-).
> * ax=4400h/int 21h (get device info) can be used to check if CON is in a
> "bugged" state or not. Call with:
> ax = 4400h
> bx = 0 ; handle 0
> If the call successfully returns with bit 6 of DL cleared, then
> anyone reading from CON will immediately get an EOF.
Bit 6 cleared means that stdin is NOT at EOF. Does that mean that normal
reads from stdin always return bit 6 set (i.e. stdin IS at EOF)?
> * The ^Z trick only seems to work at the start of line:
This one, I have known for a long time. ^Z behaves strangely in text
input because DOS doesn't gobble the input before you press RET, due to
buffering.
> bash$ echo -e "ab\032cd" | cat
> abbash$
>
> Here everything after ^Z is discarded, but cat terminates properly.
Bzzzz!! wrong example. When `cat's stdin is redirected, `cat' switches
it to binary mode, so ^Z isn't special. (And the console device driver
isn't involved in this example anyway.)
> #include <io.h>
> int main() { char ch; _read(0, &ch, 1); return 0; }
> ----------------
>
> When this program is run, it reads a *line* from the keyboard,
> although only one character is actually used.
Known. To *really* read a single character, you need to switch stdin
handle into raw mode (usually done automatically for you by library
functions when you switch stdin to binary mode, if stdin is connected to
the console device, but you can use IOCTL to do that by hand). This is
how DOS works: raw mode disables DOS buffering.
> Perhaps bash should ensure that the handle 0 buffer is empty before
> executing a program ?
I think this is a bad idea, since it will cause Bash lose typeahead.
People who type faster than programs run will get very upset.
- Raw text -