Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 16986 - print filers not working with remote winnt system
print filers not working with remote winnt system
Product: Red Hat Linux
Classification: Retired
Component: rhs-printfilters (Show other bugs)
i386 Linux
high Severity high
: ---
: ---
Assigned To: Crutcher Dunnavant
Depends On:
  Show dependency treegraph
Reported: 2000-08-26 11:04 EDT by Gene Czarcinski
Modified: 2008-05-01 11:37 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2000-08-28 23:45:12 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 Gene Czarcinski 2000-08-26 11:04:45 EDT
I have rc2 installed and configured as a print server with an HP4000 on a
network connection (HP JetDirect).  Using printtool, I have it configured
as a Postscript printer.  However, when I try to print from a winnt system
configured to print using the LPR "port" interface, it does not work
properly -- the only thing that prints is a single page with "No spool file
found."  (lp in printcap)

I have a program which also produces this (I can send it if necessary but
it is not small).  However, with this program I can get output if I remove
the filter (lp0 in printcap).

All of this works under rhl 6.2.

Here is my /etc/printcap:

# /etc/printcap
# Please don't edit this file directly unless you know what you are doing!
# Be warned that the control-panel printtool requires a very strict format!
# Look at the printcap(5) man page for more info.
# This file can be edited with the printtool in the control-panel.

##PRINTTOOL3## REMOTE POSTSCRIPT 1200x1200 letter {} PostScript Default {}
Comment 1 Gene Czarcinski 2000-08-26 11:40:15 EDT
I ripped out all the stuff in /var/spool/lpd/* and /et/printcap.  Rebooted and
rebuilt with printtool.  Now it works!?

Who knows?  The program still does not work (sometimes) but I don't believe it
is a RH problem.

Comment 2 Gene Czarcinski 2000-08-27 21:25:48 EDT
I thought I had this resolved but I do not.

Win/nt when using a linux system as a print server  and using the tcp lpr
interface will generate a control file whose pointer to the data file uses the
"l" (literal) flag rather the the "f" flag. 

While LPRng can handle this fine (and so can its filter package ifhp),
rhs-printfilters cannot.

This is easily reproducable.

The "fix" looks fairly simple.  In line 165 of
/usr/lib/rhs/rhs-printfilters/master-filter the test is for an "f" as the first
character to get the name of the related data file.  If this "fails", another
test needs to look for a "l" first character.

This should be high priority since it will effect users with a multi-os
situation which is using a linux print spooler and win/nt.

For some reason, this did NOT occur with the old lpr package.  It must be
something that LPRng does.
Comment 3 Crutcher Dunnavant 2000-08-28 23:45:10 EDT
Yeah, well, the old lpd actually spooled files, so it directed streams into the
printfilters. You are very right, rhs-printfilters needs to do this.

I will fix this. I will also do a complete comparison to RFC 1179, to see if
there are more fun borkenness in the printfilters. I'll just bet there is... :(

Man, I am getting mad at bugzilla, this should have been mine from the start.
I wonder how many other bugs of mine its droping...
Comment 4 Crutcher Dunnavant 2000-08-30 15:35:18 EDT
This is *fixed*, though we continue to ignore format specifications, and rely on
This system needs to go.

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