Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!spool.mu.edu!agate!sunkist.berkeley.edu!raymond
From: raymond@math.berkeley.edu (Raymond Chen)
Newsgroups: comp.binaries.ibm.pc.d
Subject: Re: documentation printing
Message-ID: <1991Jun12.171023.26270@agate.berkeley.edu>
Date: 12 Jun 91 17:10:23 GMT
References: <1991Jun11.105816.31353@kuhub.cc.ukans.edu> <1991Jun12.065151.27837@klaava.Helsinki.FI> <6711@uafhp.uark.edu>
Sender: usenet@agate.berkeley.edu (USENET Administrator)
Reply-To: raymond@math.berkeley.edu (Raymond Chen)
Organization: U.C. Berkeley
Lines: 26
In-Reply-To: acrosby@uafhp.uark.edu (Albert Crosby)
Originator: raymond@sunkist.berkeley.edu

In article <6711@uafhp.uark.edu>, acrosby@uafhp (Albert Crosby) writes:
>My $.02 worth is that using copy-to-prn is the better solution for the reason
>that Prof. Salmi indicates:  print loads a memory resident program.  

Agreed.

And what if print.com isn't in the user's path?  Say, if the batch
file is being run from a floppy-only system?  Or if the user has
deleted print.com (like me).  (For example, if I'm on a network that
automatically spools print jobs to a pooled printer.)

And what if the batch file is executed from a secondary shell?  DOS
gets mighty confused when TSR's are installed from secondary shells.
(Usually forcing a reboot.)

And besides, the fact that it is a TSR means that the batch file has a
side-effect.  My development machine needs all the memory it can get
so I can run my debugger.  I would be very annoyed if a purportedly
harmless batch program ran a TSR, which then forced me to reboot my
system just so I can get that memory back.

In summary:  `copy file prn' works.  It doesn't work well, but it
works.

`print file' works sometimes.  Not always.  (And I would even venture
to say `rarely'.)  And sometimes it forces the user to reboot.