Mail Archives: djgpp/1998/04/01/09:26:30
Hi.
> Why do you say ``it shouldn't''?
I thought handle 0 was CON opened read-only.
> The conclusion in this thread was
> that the reason for this behavior is some quirk peculiar to the DOS
> console device driver. If so, any write to the CON device would
> probably produce the same effect. I didn't test, but I'd bet that
> even if you open "CON" on another handle and write to it, it will
> clear the ^Z condition as well.
You just lost yourself a bet.
Here are the two cures in question:
- cure1.c --------------
#include <io.h>
int main() { _write(0, 0, 0); return 0; }
------------------------
The above could also have been _write(1, 0, 0). Equally good.
- cure2.c --------------
#include <io.h>
int main()
{
int fd = _open("con", 1); /* or _open("con", 2) */
if (fd < 0) return 1;
_write(fd, 0, 0);
_close(fd);
return 0;
}
------------------------
cure1 works, cure2 doesn't.
Note:
* The _write() will fail if "con" were opened read-only (_open("con", 0)).
* "con", "CON", "con:" and "CON:" have the same effect.
And here a few interesting observations:
* 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.
* The ^Z trick only seems to work at the start of line:
bash$ cat
ab^Zcd
ab<waits for further i/p>
Here the entire line after the ^Z is discarded, and cat does not
terminate. However, have a look at this:
bash$ echo -e "ab\032cd" | cat
abbash$
Here everything after ^Z is discarded, but cat terminates properly.
* Since bash itself does not use handle 0, "remnants" may be present in
it, which can affect other programs that are run after it (and which
read from handle 0). I mean:
- xyz.c --------
#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. The rest of the chars
remain in CON's buffer (or whereever). Try running this program, give
it a more-than-one-character input, then run cat (with no args of
course).
Perhaps bash should ensure that the handle 0 buffer is empty before
executing a program ?
Regards,
Mahesh (Mahadevan R.), <mdevan AT iname DOT com>
- Raw text -