From Bugzilla Helper: User-Agent: Mozilla/4.76 [en] (X11; U; Linux 2.4.1-0.1.9 i686) If lpr_bounce support is used to pre-filter a print job before sending the job to a remote printer, then the data file transfer name is mistakenly set to <NULL> instead of the proper dfXXXXhost name. Reproducible: Always Steps to Reproduce: 1. set up a printcap.local entry to use lpr_bounce, a local filter, and a remote printer 2. try to print a file to it using lpr 3. no error will be reported, but not output will be produced (an lpr -V or lpr -D5 will show that the data file "<NULL>" has been sent to the remote printer) Actual Results: No error will be reported (exit status 0), but no output will ever be printed This is a bug with lpr distributed with LPRng version 3.7.4
Created attachment 15164 [details] fix that saves old transfername in data file line_list for print job after filtering
I will look at this some more, but I dont fully understand the 'correct, behaviour on this one. There are some permission issues.
Crutcher, what are the permission issues that you were thinking of? Mitch, the line: if (old_transfername) free(old_transfername); old_transfername = 0; looks like it should instead be: if (old_transfername) { free(old_transfername); old_transfername = 0; } Do you agree?
You are correct that the if statement scope should include both the free() and old_transfername = 0 statements...sorry about the slop...
Well, it's a moot point anyway. This is fixed upstream (3.8.3).
See also bug #20115, which may or may not be related.
Fixed in LPRng-3.8.4-1.