Date: Wed, 10 Jan 2001 23:45:06 -0500 From: Tim Pierce <twp@rootsweb.com> To: UCTC Sysadmin <ecsd@transbay.net> Cc: questions@FreeBSD.ORG Subject: lprm/lpd process management [was Re: flushing the parallel port buffer?] Message-ID: <20010110234506.N41427@ma-1.rootsweb.com> In-Reply-To: <3A4D872B.C2611C40@transbay.net>; from ecsd@transbay.net on Fri, Dec 29, 2000 at 10:56:43PM -0800 References: <20001224035533.A376@ma-1.rootsweb.com> <3A4D872B.C2611C40@transbay.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Sorry for the delayed response (holidays &c).
On Fri, Dec 29, 2000 at 10:56:43PM -0800, UCTC Sysadmin wrote:
> Tim Pierce wrote:
> >
> > Hi -
>
> > I have exactly this problem (modulo apsfilter, which I do not use).
> > My printer is an Epson Stylus Color 740, driven by GhostScript
> > 6.50, under FreeBSD 3.3-RELEASE. If I run a large print job at
> > high quality, and lprm the job while the first page is printing,
> > it will continue to print buffered data for several pages, a
> > half-hour or more.
>
> I imagine the problem is the data's been sent to the device already,
> because there are no 'buffers' per se for the parallel port (in
> hardware) and lprm should get rid of what's on Unix.
I did find the source of my problem, and it was quite elsewhere.
While lprm does remove the current job from the queue, it does not
kill the underlying GhostScript process that is actually shoving
bits at the printer. After lprm I have to kill the gs process
manually.
Should lprm and/or lpd not be doing this for me? Is my printer
setup too baroque? I'm driving my printer with a shell script that
runs GhostScript on the input stream, like so:
fine|Epson Color Stylus 740 at 720x720 dpi:\
:sh:\
:lp=/dev/lpt0:sd=/var/spool/output/fine:lf=/var/log/lpd-errs:\
:mx#0:\
:if=/local/sbin/gsprint_h
/local/sbin/gsprint_h in turn is:
#/bin/sh
/local/bin/enscript --margins=:::36 --pass-through -o - | \
/local/bin/gs -dNOPAUSE -q @stc500ph.upp -sOutputFile=- - -c quit
So a file that gets sent to this printer gets run through
gsprint_h, which runs it through enscript, which pipes it through
gs, which *then* renders the page on the printer. (I don't actually
think this is too horribly complicated: I could cut out enscript,
but I think all the other parts are still necessary.)
--
Regards,
Tim Pierce
RootsWeb.com lead system admonsterator
and Chief Hacking Officer
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010110234506.N41427>