Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!rice!sun-spots-request
From: munnari!chudich.co.rmit.oz.au!rcodi@uunet.uu.net (Ian Donaldson)
Newsgroups: comp.sys.sun
Subject: Re: lpr loses last part of output
Keywords: Hardware
Message-ID: <481@chudich.co.rmit.oz>
Date: 8 May 89 13:52:03 GMT
References: <8904122320.AA13033@meridian.com>
Sender: usenet@rice.edu
Organization: RMIT Comm & Elec Eng, Melbourne, Australia.
Lines: 27
Approved: Sun-Spots@rice.edu
Original-Date: 1 May 89 11:27:27 GMT
X-Sun-Spots-Digest: Volume 7, Issue 274, message 7 of 12

> We have a Printronix P6040L printer hooked up to the ALM-2 parallel port
> on a Sun 3/260 running SunOS 4.0.1.  About half the times that lpr is used
> with plain text, the very last part of the output is mysteriously
> truncated.  The problem is reproducible with certain files.  Has anyone
> else run into this one---and fixed it?  There doesn't seem to be anything
> special in /etc/printcap that needs to be set, but perhaps I'm missing
> something.  

There is a bug in a lot of old BSD tty drivers in that the last close on
the device drops DTR before the last data goes out.  This means that if
DCD is connected to DTR (some how) then the last lot of data might be
flushed down the toilet.

In short, the icky method of sticking out extra blanks on the output at
the end works fine.  Another approach is to sleep(4) after you've written
the last data to allow it time to go out.  For lpr, this means you need
your own filter that does this, to replace "lpf".

The fix in the tty driver (at least 4.2bsd and SunOS 3.5 I suspect) is to
reorder the the statements that do the ttyflush() in the code that detects
the drop in DCD.  In 4.3bsd this is fixed in ttymodem() (this is all from
memory, and a bit hazy at that...)

Anyway, I *know* the bug exists in SunOS 3.3 thru 3.5 and Vax 4.2bsd.  Not
sure about other SunOS's.  The bug doesn't exist in Vax 4.3bsd however.

Ian D