Message-Id:	<199803301513.RAA34720@ieva06.lanet.lv>
From:	"Andris Pavenis" <pavenis AT lanet DOT lv>
To:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
Date:	Mon, 30 Mar 1998 18:11:08 +0000
MIME-Version:	1.0
Subject:	Re: "bash"ing "cat"s.
CC:	djgpp AT delorie DOT com
References:	<199803301137 DOT NAA26326 AT ieva06 DOT lanet DOT lv>
In-reply-to:	<Pine.SUN.3.91.980330165119.20293C-100000@is>

> From:          Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
> 
> On Mon, 30 Mar 1998, Andris Pavenis wrote:
> 
> > 2) start FAR or Norton Commander in DOS session under Win95
> > 3) run test1.exe and terminate input with Ctrl-Z
> > 4) run test1.exe once more (for me it gets EOF IMMEDIATELLY)
> 
> Thanks, that's an important piece of evidence.
> 
> So, it seems that (once again) COMMAND.COM is doing something that other 
> shells don't.  The question is: what that thing is?
> 
> You said in previous messages that you looked at the DOS calls issued by
> COMMAND.COM and didn't see anything special.  What *did* you see?  In
> particular, were there any IOCTL calls (Int 21h/AH=44h) which reference
> the console device?
> 

At first exactly the same situation is with 4DOS (not only COMMAND.COM)
Looks also that outputing at least one byte to stdout or stderr fixes 
problem (WHY??). I didn't see any difference if this was done before or 
after EOF. COMMAND.COM outputs DOS prompt, so the problem is
fixed for this time. Perhaps NC or FAR does not use DOS console output 
functions. I don't still understand why this problem appears with bash.

I havent looked at sources of DOS port of bash. Looks that bash does
some tricks with console I/O:
	- bash >somfile
               does not work
         - bash did not work for me correctly in 80x50 console mode. For
           command.com or 4dos.com I didn't see any problems.

The only IOCTL call for stdin I saw was GET_DEV_INFO (so it is not
significant)

Maybe this is Micro$oft bug. Perhaps I can test the same with 
Calder DR-Open DOS 7.02  at home sometime.

Andris

- Raw text -