Printing only works for PostScript files or CUPS' own test page
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
samba (Ubuntu) |
Fix Released
|
High
|
Unassigned |
Bug Description
System is Xubuntu 6.06.1 LTS.
Printer is a Brother HL-1650 (BRScript3, i.e. probably PostScript in all but name) over Samba (this does not seem to be an smbspool issue though).
CUPS can print its own test page.
lp SomePostScriptF
BTW while the user might be expected to find http://
sudo adduser cupsys shadow
/etc/init.d/cupsys restart
to even be allowed to add a printer. This should probably be considered automagically in future versions...
I assume something goes wrong in foomatic's attempt to convert into PostScript and found the ways to make it write a debug log, but the parameters it is called with are a mystery to me (and apparently to itself either, judging from the output linked above) - so I can't tell yet whether it fails because of wrong parameters, missing input or insufficient rights to write its output.
The suspects - and indeed they've tried to escape:
" vs. '
In /tmp/foomatic- rip.log we have:
renderer command: level=0; /usr/bin/printf "%%!\n%%%% %%%%\n<</Duplex false>> setpagedevice\ n"; if [ $level -gt 0 ]; then if [ $level -lt 99 ]; then level=" -dLanguageLevel =$level" ; else level=""; fi; gs -q -dPARANOIDSAFER -dNOPAUSE -dBATCH -sDEVICE= pswrite$ level -sOutputFile=- -; else cat; fi
This is from line 3567 of /usr/bin/ foomatic- rip which tries to run: "$commandline" );
system(
See the nested, unescaped double quotes colliding...
Now even on the plain shell prompt we can only expect garbled output from setpagedevice\ n"
:~$ /usr/bin/printf "%%!\n%%%% %%%%\n<</Duplex false>>
bash: !\n%%%%: event not found
...and nor does the following look right to me:
else cat; fi
Now if someone more familiar with that code could figure out where the /usr/bin/printf statements used in the invocations of rendercmd and the subsequent cmd and currentcmd are constructed, and if they are what makes the script fail '$commandline' );],
[at least it terminates without error, albeit without proper results as well, as soon as the above is changed to system(
I'd suggest replacing them with single quotes - rather than doing the same only for the system() calls which would make CUPS believe the jobs had been completed while producing empty output.