🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.os.ms-windows.setup
Article #1140

Re: Can't pipe to NUL in a dos session - Help please!

#1140
From: Fuzzy Fox
Date: Sun, 22 Nov 1992 04:26
51 lines
3047 bytes
colfelt@ucsu.Colorado.EDU (Andrew BW Colfelt) writes:

>I always thought that piping > NUL was just a
>fancy @ECHO OFF statement, but this comment leads
>me to believe that it is not as innocuous as I
>believed.

Since I have not programmed TSR's, I must first explain that this is
information I have heard on the net, but I have no direct experience.

When you run a command and redirect its output via >NUL, the shell
(command.com) opens the NUL device as a file and passes this file handle
to the program.  The program writes its output to this file and thus the
output goes nowhere, essentially the 'ECHO OFF' behavior.  However, the
file is still opened by DOS and the application still performs write
operations on this device.

Most programs terminate when they are done, and so the file that they
are writing output to is then closed for them.  However, in the case of
a TSR, the program does not exactly terminate, because it stays resident
in the machine.  So, if the program is written poorly and the programmer
forgets to close the output file, then that means the output file for
that program remains open forever, or at least until you reboot the
machine.

I'm not sure how the sharing code works, but SHARE is a program which
prevents simultaneous conflicting access to files and devices.  For
instance, it will prevent to programs from trying to write to the PRN or
COM1 device (which is a very good thing!).  I am not sure, but I believe
that DOS does not differentiate when it comes to the NUL device, and it
prevents conflicting accesses to that device as well.

So if a TSR is installed with its output redirected to >NUL and it does
not close the file as part of its installation, then SHARE will prevent
other programs from trying to write to >NUL because another program is
using it.

Now, the short version:  Go into AUTOEXEC.BAT and remove all the
redirections to >NUL, then reboot and see if your problem goes away.  If
it does, then what I said above is causing it.  Find out which program
is causing the trouble, and don't redirect that program's output to
>NUL.

If your problem does not go away, then that means I'm wrong.  Please let
me know if I am.

-- 
#ifdef TRUE         | Fuzzy Fox                  fuzzy@netcom.com
#define  TRUE   0   | a.k.a. David DeSimone      an207@cleveland.freenet.edu
#define  FALSE  1   | "You have been recruited by the Star League to defend
#endif              |    the Frontier against Xur and the Kodan Armada."
Technical Details
Message-ID: <1992Nov22.042652.5566@netcom.com>
Path: arc1-ca.pugleaf.net!sparky!uunet!cs.utexas.edu!swrinde!sdd.hp.com!spool.mu.edu!umn.edu!csus.edu!netcom.com!fuzzy
References: <168A28014.ANAVARRO@vm.poly.edu> <1992Nov18.175648.17461@rei.com> <1992Nov21.182227.12451@ucsu.Colorado.EDU>

Show Full Headers
Complete Article Headers
Newsgroups: comp.os.ms-windows.setup
Path: arc1-ca.pugleaf.net!sparky!uunet!cs.utexas.edu!swrinde!sdd.hp.com!spool.mu.edu!umn.edu!csus.edu!netcom.com!fuzzy
From: fuzzy@netcom.com (Fuzzy Fox)
Subject: Re: Can't pipe to NUL in a dos session - Help please!
Message-ID: <1992Nov22.042652.5566@netcom.com>
Organization: Foxes 'R' Us - Seven locations to serve you
References: <168A28014.ANAVARRO@vm.poly.edu> <1992Nov18.175648.17461@rei.com> <1992Nov21.182227.12451@ucsu.Colorado.EDU>
Date: Sun, 22 Nov 1992 04:26:52 GMT
Lines: 51