Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!apple!uokmax!rmtodd
From: rmtodd@uokmax.uucp (Richard Michael Todd)
Newsgroups: comp.unix.aux
Subject: Re: A/UX 2.0 and Chooser/Printer problems
Keywords: A/UX, 2.0, chooser, Imagewriter, printer, problem
Message-ID: <1990Aug29.185900.2036@uokmax.uucp>
Date: 29 Aug 90 18:59:00 GMT
References: <20070@well.sf.ca.us>
Distribution: usa
Organization: Engineering Computer Network, University of Oklahoma, Norman, OK
Lines: 41

espen@well.sf.ca.us (Peter Espen) writes:
>in A/UX 2.0.   No matter what I do, I can't get the chooser
>to believe that appletalk is inactive,  and so it won't let me
>select that printer port for the Imagwriter.  I know that  someone
>else has been having the same problem and posting it to 
>comp.unix.aux.   I finally gave up on getting the chooser to 

Yep. I have the same problem.  Like you, I moved the ImageWriter to
the modem port and moved the modem to the printer port.  

>under A/UX  are getting hung in the "printing....type clover
>and . to cancel" .  I have gotten  MS Word to print once or twice
>correctly with this set-up, but it is highly erratic  and unreliable.

  Well, I don't use Mickeysoft Word (it being against my religion to format
text with anything except troff or TeX :-), but I've been seeing some of the 
same problems with Maple.  Sometimes it prints real quickly, other times
it prints a few lines of the graph and then hangs for like 10-20 *minutes*
before eventually finishing.  Alas, it's hard to say whether this is the fault
of Maple or of the A/UX Mac-emulation environment, as I really don't use any
other MacOS software...

   There's another nasty feature of the current printer software: it
apparently opens the serial device (/dev/tty0) with O_EXCL set and never
closes it after your file has finished printing.  This means that once you
print a file from the MacOS environment you will *not* be able to access
the printer from the Unix side (with lpr/lpd) until you Logout of the MacOS
emulator and log back in again.  Tacky.  I *think* I've come up with a
workaround; it involves moving the real /dev/tty0 "out of the way" of the
MacOS emulator and putting in its place a slave pseudo-tty, and having a
process to read from the master side of the pty and send the output to lpr,
so that your Mac-style printing will look like just another Unix job.  I'm
still working on the software to do this, but I whipped up a quick program
to run the master pty side of things and it seemed to work, and printing
from the Mac side to a file instead of to the printer is a whole lot faster
:-). Print spooling, what a concept...  I'll post the software that does
this when I've done some more work on it, probably sometime in the next few
weeks.  
-- 
Richard Todd   rmtodd@chinet.chi.il.us    rmtodd@servalan.UUCP
"MSDOS is a Neanderthal operating system" - Henry Spencer