Mail Archives: djgpp-workers/1999/04/06/07:26:50
> > I know some programs first check isatty(stdin), but someone
> > might want to be able to type binary data (C-z, C-c, C-m and
> > such) on the terminal.
> > The computer freezes when getchar (or any other DOS input
> > function) is called
> And that's exactly the reason why programs which use DOS I/O *should*
> check isatty(stdin) and only switch stdin to binary mode if
> it is NOT the console device.
Ah. Ok, so it's the application that is in error.
> If the program actually *needs* to read binary data from the
> terminal, it should read it one character at a time, like so:
> read (0, &c, 1);
> (or use `getch').
True. The program must know how many bytes to read beforehand, as no EOF
char exists any more to type.
> Using buffered stdio functions, like `getchar', won't
> return until the full 512-byte long request is satisfied, and
> until then you are parked inside a DOS call, so signals don't
> work, and Ctrl-Z doesn't work either, since it is not special
> in raw mode. For all practical purposes, the machine appears
> to be wedged...
> > Using 1 (stdout) or 2 (stderr) instead of 0 (stdin) shows
> > exactly the same behaviour, as DOS just changes the mode
> > of the same `console' if no redirection is used.
> Right. See the complicated logic in the DJGPP port of Gzip
> 1.24a, which is meant to prevent people typing "gzip [Enter]"
> and getting the behavior you describe.
I only just noticed a note to this in it's README, yes.
> Seems like `zip' doesn't do that...
True. I'll send the maintainers a bug fix soon.
> > I dug all the inner details out of libc, but at first it
> > turned out to be a problem in DOS itself.
> The library simply switches the device to raw mode;
> everything else is DOS behavior.
Yes, I experienced that...
> > All problems disappeared when I set stdin to _IONBF (not buffered)
> > instead of _IOLBF (line buffered). At least, just one key press is
> > enough to let the C-BREAK through.
> I'm worried about the possible implications of turning off
> the buffering just because somebody reads in binary mode.
> Can anybody think of any downside to this change? If not,
> let's do it.
Or let's just fix "all" the applications using setmode(O_BINARY)...
And it's documentation in setmode.txh.
And, after all, the change is *only* in the situation that one would like to
be able to SIGINT...
> Also, I don't see how this would help, except that it enables
> SIGINT. You still cannot signal EOF with Ctrl-Z
Of course, as you should be able to type one. Or the application should stop
reading after it encountered a C-z itself. But the SIGINT is a big win,
though.
> so this is still a small disaster, and programs like zip still
> need to check isatty, no?
Yes, they should. Or we could change setmode to deny setting the console to
binary. But that might have other consequences...
> > Nothing is echoed, but should it?
> No. Binary mode doesn't echo.
Ok.
It seems this problem is already known among some DJGPP "porters" but not
all. We (someone how knows most about this) should document this somewhere
at least...
Groente, Michel.
- Raw text -