Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!pt.cs.cmu.edu!b.gp.cs.cmu.edu!ralf From: ralf@b.gp.cs.cmu.edu (Ralf Brown) Newsgroups: comp.sys.ibm.pc Subject: Re: MS-DOS puzzle #1 Message-ID: <5486@pt.cs.cmu.edu> Date: 11 Jul 89 19:52:34 GMT References: <8167@bsu-cs.bsu.edu> <1171@calvin.EE.CORNELL.EDU> Distribution: comp Organization: Carnegie-Mellon University, CS/RI Lines: 66 In article <1171@calvin.EE.CORNELL.EDU> richard@calvin.spp.cornell.edu (Richard Brittain) writes: }In article <8167@bsu-cs.bsu.edu> dhesi@bsu-cs.bsu.edu (Rahul Dhesi) writes: }> }>In article <6893@bsu-cs.bsu.edu> a long time ago I wrote: }>> Question: Why does COMMAND.COM allow redirection of standard }>> input and standard output, but not standard error? }>> }>> Answer: MS-DOS, unlike UNIX, doesn't have a fork() system call; }>> therefore the MS-DOS command interpreter, unlike the }>> UNIX shell, can't redirect standard error. } ...... }>The MS-DOS command interpreter can't use fork(). In order to redirect }>a file descriptor for a child process, it must redirect its own file }>descriptor before the EXEC, and save the old file descriptor }>somewhere. One way of doing this is to use dup2() to create a }>duplicate high-numbered fd. } ...... }>But if it does this, then the new process has an extra open file handle }>available to it, since EXEC duplicates all open files. (MS-DOS has no }>close-on-exec flag.) This is risky. A badly-designed program could }>write garbage to fd 15 (which was not really supposed to be open at }>all). } ...... } This sounds like a C programmer thinking only in terms of the standard }way to handle things in C. Since stderr defaults to the console every time }control returns to COMMAND.COM, why bother preserving the state with a dup'd }file handle - just reopen it to the redirected file, then later close and }reopen to the console. Even if stderr were pointing at a file when you }wanted to redirect it, you would only need to remember the file name and }offset to retore later on - there is no need to keep a spare file handle }open in the meantime. . First, stderr does not necesarily refer to the console--I have a program to redirect standard error, and if I use it to run COMMAND.COM on a batch file, having COMMAND unilaterally change stderr to the console after executing a command with redirection would defeat this (same thing goes for stdin and stdout--you can run a COMMAND with them redirected and re-redirect them in a batch file). Secondly, the file name is not necesarily available. If another program did the redirection before spawning COMMAND, the name will be inaccessible. Note that the CTTY command is functionally equivalent to running another copy of COMMAND.COM with both input and output redirected to the specified device. CTTY COM1 <==> COMMAND COM2 . } Also, note that the latest DOS has a child inherit/not inherit attribute }on handles if sharing is used, so actually the dup method could then be }used safely. But note that setting the attribute is only available on OPEN, not on DUP or DUP2.... Unless the program redirecting std{in,out,err} opens the un-redirected handle to begin with, it can't make the file uninheritable. And if it did make it uninheritable, un-redirected output would require a DUP anyway, since the original handle couldn't be passed to the child. What can be done, however, (and this works for DOS 2 and up), is to copy the appropriate entries in the Process File Table in the PSP, zap them to FFh (unused), do the EXEC, and then restore the entries. While the child will then get the same handle number on opening a file, it will refer to a different file (the above is what the no-inherit attribute does, anyway--it zaps the uninheritable handles in the child's PFT to FFh). -- {harvard,uunet,ucbvax}!b.gp.cs.cmu.edu!ralf -=-=- AT&T: (412)268-3053 (school) ARPA: RALF@CS.CMU.EDU |"The optimist is the kind of person who believes a FIDO: Ralf Brown 1:129/46 | housefly is looking for a way out."--Geo.J.Nathan BITnet: RALF%CS.CMU.EDU@CMUCCVMA -=-=-=-=-=- DISCLAIMER? I claimed something?