Red Hat Bugzilla – Bug 127245
/etc/printcap.local is ignored
Last modified: 2007-11-30 17:10:45 EST
Description of problem:
/etc/printcap.local is supposed to be included into /etc/printcap, but
it isn't. This is true both with the distributed version of
/etc/printcap.local (which consists only of comments) and also after I
added a printer description to it.
Version-Release number of selected component (if applicable):
Every time you start up cups.
Steps to Reproduce:
1. Kill cups.
2. Start cups.
The print spooler is no longer driven by /etc/printcap -- it is there
for informational purposes, to be used by legacy applications that
might read it. CUPS writes /etc/printcap based on its own configuration.
Wouldn't it make sense not to ship the file at all, then?
Oops. Thought it was something you'd created, sorry.
Fixed in system-config-printer-0.6.102-1.
Any chance there'll be a fix I can install in Fedora Core 1?
No, it's not a big enough change to warrant that -- you can get the
same effect by 'rm /etc/printcap.local'.
I think you're misunderstanding the function of /etc/printcap.local: I
have (or at least had, using RedHat 7.3 and many earlier versions) a
hand-edited print filter, and I wanted to create a print queue that
used that filter instead of the ones offered by cups. I put the
following into /etc/printcap.local:
(where /usr/local/bin/ljet4-filter was a hand-edited version of the
filter produced by the (now allegedly obsolete) magicfilter version
1.2). After I created the appropriate spool directory, I could then
use this to print. (In fact, I then had the default print queue
forward print jobs on to this queue, so this was effectively the default.)
This isn't vital, since I have other (slightly less convenient) ways
of accomplishing most of what I want to do, but /etc/printcap.local
*does* allow you to do things that I at least haven't figured out how
to do using cups directly.
See comment #1 -- this is no longer possible, and hasn't been since
the switch to CUPS. You must configure CUPS directly.