Message-Id: <199803301513.RAA34720@ieva06.lanet.lv> From: "Andris Pavenis" To: Eli Zaretskii Date: Mon, 30 Mar 1998 18:11:08 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT 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: Precedence: bulk > From: Eli Zaretskii > > 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