www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1998/04/01/09:26:30

Date: Wed, 1 Apr 1998 20:02:14 +0530 (IST)
From: "Mahadevan R." <mdevan AT md2 DOT vsnl DOT net DOT in>
Reply-To: mdevan AT iname DOT com
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
Cc: djgpp AT delorie DOT com
Subject: Re: "bash"ing "cat"s.
In-Reply-To: <Pine.SUN.3.91.980401112310.2919I-100000@is>
Message-Id: <Pine.OSF.3.95.980401195721.5455A-100000@md2.vsnl.net.in>
Mime-Version: 1.0

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 -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019