🚀 go-pugleaf

In article <100@snll-arpagw.UUCP> paolucci@snll-arpagw.UUCP (Sam Paolucci) writes:
>		.  A copy command (or cat, or type, or ...) should not
>append anything to a file.  It is not their job.  These commands have
>no way, and should not have any way of telling that you are redirecting
>their output to your serial device.  Only the user knows this. 

This is true.  A "copy" command should never add anything to the end of the
file.  However, it is simplistic to treat a printer like a file, especially
a PostScript printer.  A PostScript printer is a computer, not a file.  Here
are three reasons why a simple utility program should be used (if you only
had one, sigh), rather than "copy":

	1.  Flow control.  Unless you configure your printer for DTR/DSR
	flow control, or unless you handle XON/XOFF yourself, there will
	be a practical limit to the size of files you can print without
	overflowing the communications buffer.

	2.  Control-D.  Somebody needs to signal the end of the file/job.

	3.  Error conditions.  Errors are reported back along the serial
	connection.  If nothing is listening to the serial line, the
	errors will be lost.

It certainly is handy to be able to copy files directly to the serial
port.  I don't think that any doctrine should tell you not to do that.  But
is is a quick-and-dirty solution, and not really the best one.  You could
"cat" files directly to the serial port on a UNIX machine, too, but it is
better to use the printer spooling software that comes with UNIX, and it is
also easier.  It is indeed a problem that smaller personal systems do not
come with spooling software or other operating system abstractions that give
you a place to put utility programs to do things like this.

Glenn Reid
Adobe Systems