Bug 18683 - Incorrect printcap generation for network printer
Incorrect printcap generation for network printer
Product: Red Hat Linux
Classification: Retired
Component: printtool (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Crutcher Dunnavant
Aaron Brown
Depends On:
  Show dependency treegraph
Reported: 2000-10-09 04:50 EDT by gregory.hosler
Modified: 2007-04-18 12:29 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2000-10-09 06:08:01 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description gregory.hosler 2000-10-09 04:50:35 EDT
I have a problem that used to work on earlier RH systems. 

I have a remote print queue on a HP-UX system.

I run printtool.

I click [Add] -> <> Remote Unix (lpd) Queue, add my remote hostname and
queue name.

The generated /etc/printcap looks like this:


The last line (:lpd_bounce=true:) will cause printing to fail. i.e.
when I print something/anything, The following displays

Oct  9 16:29:50 amnesia (Worker - Remote)[2443]: ps: Remote_job: fstatb
failed - Bad file descriptor
Oct  9 16:29:50 amnesia (Worker - Remote)[2443]: ps: Remote_job: close(5)
failed - Bad file descriptor

I must manually remove the lpd_bounce line - note that setting
also works - the "true" setting is definately wrong.

I suspect that printtool is generating the default printcat, and this
should be changed.

Comment 1 Crutcher Dunnavant 2000-10-11 12:04:37 EDT
Garh, this is yet another "How do most people expect printtool to behave" issue.

The answer is this:
lpd_bouce=true tells the system to filter requests locally, before sending them.
This way, you can easily print to postscript only printers, because the format
gets changed locally, and postscript gets sent to the printer. For most people,
this is a good thing.

However, apparently printtool doesn't notice if you don't set a filter (which
you didn't), so LPRng tries to filter locally, and sends some wierdness on to
the remote queue (because you told it to filter, using no filter, so ...).

So, the in-printtool answer is: select a print filter for the remote queue.

I will put this on the pile of printtool changes that need to be made.

Note You need to log in before you can comment on or make changes to this bug.