Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!rochester!udel!burdvax!gvlv2!kleonard
From: kleonard@gvlv2.GVL.Unisys.COM (Ken Leonard)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Redirect > nul affects procomm, why?
Message-ID: <277@gvlv2.GVL.Unisys.COM>
Date: 17 Jul 89 16:12:53 GMT
References: <3816@cps3xx.UUCP> <3817@cps3xx.UUCP>
Distribution: usa
Organization: Unisys Defense Systems, NISD, Great Valley Laboratory
Lines: 53

In article <3817@cps3xx.UUCP> gcook@cps3xx.UUCP (Greg Cook) writes:
* From article <3816@cps3xx.UUCP>, by gcook@cps3xx.UUCP (Greg Cook):
* > Recently, someone posted a request for help concerning procomm not being
* > able to find the dialing directory.  I have just started to experience
* I seem to have found the problem, but it doesn't make sense to me.  I
* have some programs that I install in my autoexec.bat such as kbfix2 and
* dosedit.  I used the "> nul" to redirect the output to nothing so I 
* won't see the messages those programs put on the screen.  However, if
* I do this, procomm has problems.  It won't find the dialing directory,
* it won't run command.com when using DOS gateway, and it won't run
* script files (cmd files).  
* If I use > nul on only some of the programs, then procomm only acts 
* up on some things (ie. it loads dialing directory, but won't do
* DOS gateway).  This is very puzzling to me.
I think you deserve to be puzzled by this one!  It's probably _never_
a good idea to redirect the ouput of a TSR program, anyhow.  Two
reasons...  you may miss seeing messages (not necesarily 'ERRORS') taht
would let you know you are doing effectively unkind things to your system;
and programs (not just Procomm) that get down and low and use DOS or
BIOS interrupt vectors (even using them perfectly properly :-) ) may
end up just a bit confused.  
* 
* I have two questions:
* 
* 1.  What exactly is the "nul" ?
well, "nul" is not-a-file, or file-to-nowhere, or ignore-all-write-calls,
depending on which version of what level of whose port of DOS you have.
so, depending on your system configuration, there's mostly no way to
tell what really happens when a program thinks it's writing stdout that
happens to be redirected to nul.
* 2.  Why is this affecting PROCOMM?
and when a TSR terminates, but does not get fully cleaned-out from memory,
whatever or nothing DOS may do with it's standard-out is not easy to
determine, and if the redirection is at some level lower than the level
of ignore-the-PROGRAM'S-write-calls, you may end up with other programs'
standard-out (and standard-in and con and kbd and ???) rather snarled
-------
BUT, REALLY, all of this is really _not_ likely to _really_ do any damage,
because most DOS versions end up keeping things reasonably cleaned-up.
------
What you really NEED to do is to give Procomm (and everthing else) a
reasonable amount of explicit info to work on, i.e.
SET the PROCOMM environment variable;
USE the PATH command;
ENSURE that PATH leads to a place where COMMAND.COM lives;
SET COMSPEC so that DOS and other things (like Procomm) explicitly
know where to find COMMAND.COM.
-----
regardz,
Ken
* 
* Greg Cook
* gcook@horus.cem.msu.edu    cook@frith.egr.msu.edu