Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!calvin!richard
From: richard@calvin.EE.CORNELL.EDU (Richard Brittain)
Newsgroups: comp.sys.ibm.pc
Subject: Re: MS-DOS puzzle #1
Message-ID: <1171@calvin.EE.CORNELL.EDU>
Date: 11 Jul 89 15:00:39 GMT
References: <8167@bsu-cs.bsu.edu>
Reply-To: richard@calvin.spp.cornell.edu (Richard Brittain)
Distribution: comp
Organization: Cornell Space Plasma Physics Group
Lines: 50

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 PUZZLE.  Does the above make any sense?  If it does, why?  If it
>>does not, what is the real answer to the question?
 ......
>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).
 ...... 
>Rahul Dhesi <dhesi@bsu-cs.bsu.edu>
>UUCP:    ...!{iuvax,pur-ee}!bsu-cs!dhesi

	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.  
	It seems to me to be purely a design decision not to allow stderr to be
redirected by the "default" shell, although there is no reason why a
replacement shell could not do so (like ksh in the MKS toolkit).  I work
on a non-unix system a lot of the time (Harris VOS) in which there is a
definite design decision to make it very hard (though not quite impossible)
to redirect stderr.
	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.

Richard Brittain,                   School of Elect. Eng.,  Upson Hall   
                                    Cornell University, Ithaca, NY 14853
ARPA: richard@calvin.spp.cornell.edu	
UUCP: {uunet,uw-beaver,rochester,cmcl2}!cornell!calvin!richard