Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!lll-winken!snll-arpagw!paolucci From: paolucci@snll-arpagw.UUCP (Sam Paolucci) Newsgroups: comp.lang.postscript Subject: Re: "copy" to Amiga serial port Message-ID: <107@snll-arpagw.UUCP> Date: 1 May 89 02:49:56 GMT References: <2994@daisy.UUCP> <775@adobe.UUCP> <8751@polya.Stanford.EDU> <98@snll-arpagw.UUCP> <22489@ccicpg.UUCP> <100@snll-arpagw.UUCP> <798@adobe.UUCP> Reply-To: paolucci@snll-arpagw.UUCP (Sam Paolucci) Organization: Sandia National Labs, Livermore, CA Lines: 82 In article <798@adobe.UUCP> greid@adobe.COM (Glenn Reid) writes: ->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. It is not the printer that is treated like a file, but the serial device on the Amiga. This makes it easy and convenient to send a file to anything that is attached to the serial port. ->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. This is handled automatically by the serial device. -> 2. Control-D. Somebody needs to signal the end of the file/job. That's the reason why the ^D is appended to the end of the file. -> 3. Error conditions. Errors are reported back along the serial -> connection. If nothing is listening to the serial line, the -> errors will be lost. I usually download at bootup ehandler.ps to the printer to catch those. ->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. That is exactly the problem. If OS's for the smaller systems included spooling software we would not be having this discussion. But due to the lack of it, something needs to be done. So we are only arguing on how this is best done. It is easy enough for me to write a script on the Amiga, call it psprint, that does the following: .k file/a copy ser: copy pseof ser: where the file pseof included the single byte ^D. I could then execute the psprint command with "psprint myfile". Now the problem comes when I want to redirect the output of an application program directly to the printer without saving it as a file. Then, in order not to get an EOF timeout from the printer, I still need to "copy pseof ser:". You see that if a ^D is always appended at the end of the application output, the user does not need to distinguish between the cases, and does not need to know anything about PostScript for that matter. Now I know that this will reduce portability, so the user should be made aware that a ^D is appended to the end of the file so that if he wants to move the file to some other system, he should strip it off. Note that this happens a lot less frequently than printing files on a dedicated printer. Furthermore, I do not condone putting a ^D at the end of an EPS file, since such files are usually intended to be part of a larger file. ->Glenn Reid ->Adobe Systems -- -+= SAM =+- "the best things in life are free" ARPA: paolucci@snll-arpagw.llnl.gov