Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!rutgers!uwvax!tank!gargoyle!chinet!les
From: les@chinet.chi.il.us (Leslie Mikesell)
Newsgroups: comp.unix.i386
Subject: Re: 386ix and Parallel Printers
Message-ID: <1990May7.215415.15966@chinet.chi.il.us>
Date: 7 May 90 21:54:15 GMT
References: <15427@bfmny0.UU.NET> <1990May3.111446.2879@oct1.UUCP> <1990May6.152012.14804@ddsw1.MCS.COM> <7813@dmshq.mn.org>
Reply-To: les@chinet.chi.il.us (Leslie Mikesell)
Organization: Chinet - Chicago Public Access UNIX
Lines: 23

In article <7813@dmshq.mn.org> pnessutt@dmshq.mn.org (Bob Monio) writes:
[Re: spooling vs. writing to device]
>Agreed.  But remember that it's a rather rough job to provide
>portability in a program across different versions of spoolers on
>different flavors of UNIX.  It's made harder in case of the above
>mentioned program when the 4GL that is being used doesn't support
>spooling of output at all...  (ie: PROGRESS)

Rough???  All you have to do is allow the installer to specify the
name of a program to pipe the output to, and let popen() handle
the details.  I have yet to see a situation where this is not the
correct way to handle printing under unix, although there are
rare cases where it would be useful to offer direct device access
in addition (say you need to hand-feed paper and need to control
output without leaving the application).  Also the application should
keep in mind that the output may be coming to the terminal's aux
port and thus should not be done in the background unless the
installer sets it up that way.  If you are too lazy to read a
per-user set-up file, at least leave PATH alone so that the program
executed as the pipe can be modified per-user.

Les Mikesell
  les@chinet.chi.il.us