Xref: utzoo comp.sys.ibm.pc:46873 comp.binaries.ibm.pc.d:7113
Path: utzoo!utgpu!watserv1!watmath!iuvax!mailrus!cornell!calvin.spp.cornell.edu!richard
From: richard@calvin.spp.cornell.edu (Richard Brittain)
Newsgroups: comp.sys.ibm.pc,comp.binaries.ibm.pc.d
Subject: Re: Redirecting 4Dos output? ( > nul is bad)
Message-ID: <1990Mar22.031405.14193@calvin.spp.cornell.edu>
Date: 22 Mar 90 03:14:05 GMT
References: <17026@orstcs.CS.ORST.EDU>
Reply-To: richard@calvin.spp.cornell.edu (Richard Brittain)
Organization: Cornell Space Plasma Physics Group
Lines: 27

In article <17026@orstcs.CS.ORST.EDU> gatesl@uranus.CS.ORST.EDU (Lee Gates) writes:
>
>	After some dishartening attempts, I have rtfm, and not figured
>out the change to redirect output to nul.  I have several batch files
>I use daily, and after installing the new version of 4Dos, they aren't
>getting along too well.
>
>	I had statements like:
>execute.exe > nul
>	And 4Dos responded with access denied.  So, after reading, tried
>the >! and the >& options, and still no real progress.
>
Two possibilities:
Do you have noclobber set ?  If so, since "nul" already exists, 4dos
may not let you overwrite it (it works properly for me, but maybe it is 
dos version dependant.  I have dos 4.01)

Also possible, if you have share installed, and install a TSR with output
redirected to NUL, you may well end up with a write access handle permanently
tied to NUL (since most tsrs don't close stdout before going tsr).  4dos v 3.0
is more observant of correct file sharing then 2.21 was, so a subsequent 
attempt to open a write access handle to NUL will fail with access denied.

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