Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!bsu-cs!dhesi
From: dhesi@bsu-cs.bsu.edu (Rahul Dhesi)
Newsgroups: comp.sys.ibm.pc
Subject: Re: MS-DOS puzzle #1
Message-ID: <8177@bsu-cs.bsu.edu>
Date: 11 Jul 89 19:25:56 GMT
References: <8167@bsu-cs.bsu.edu> <1171@calvin.EE.CORNELL.EDU>
Reply-To: dhesi@bsu-cs.bsu.edu (Rahul Dhesi)
Distribution: comp
Organization: CS Dept, Ball St U, Muncie, Indiana
Lines: 20

In article <1171@calvin.EE.CORNELL.EDU> richard@calvin.spp.cornell.edu
(Richard Brittain) writes:
>Since stderr defaults to the console every time
>control returns to COMMAND.COM, why bother preserving the state with a dup'd
>file handle...

Ah, but the reason why stderr defaults to the console every time
is precisely because currently stderr cannot be redirected.

Consider the following hypothetical command in a new enhanced MS-DOS,
which allows redirection of stderr with the >* notation:

	  command >* errors.out < commands.txt

We are invoking a new copy of COMMAND.COM and making its stderr go to
the file errors.out.  This new COMMAND.COM cannot just reopen the
console for its standard error stream.
-- 
Rahul Dhesi <dhesi@bsu-cs.bsu.edu>
UUCP:    ...!{iuvax,pur-ee}!bsu-cs!dhesi