that I can have whitespaces in printer names, however the RFC1179 doesn't
explicitly forbid them and other lpd implementation allow whitespaces,
although probably not in the internal RFC1179 implementation.
The following test done with Debian BSD lpr 0.48-1 shows that I can address
a printer using a name with embedded whitespace:
# Test with lpr 0.48-1
$ cat /etc/printcap
# /etc/printcap: printer capability database. See printcap(5).
# You can use the filter entries df, tf, cf, gf etc. for
# your own filters. See the printcap(5) manual page for further
# details.
#
# HP LaserJet 4M
hp|HP LaserJet 4M:\
:lp=/tmp/hp:\
:if=/etc/magicfilter/ljet4m-filter:\
:sd=/var/spool/lpd/hp:\
:lf=/var/log/lpd/%P-errs:\
:af=/var/log/lpd/%P-acct:\
:mx#0:sh:
$ lpq -Php
Warning: hp is down: printing disabled
no entries
$ lpr -Php /tmp/test.ps
$ lpq -Php
Warning: hp is down: printing disabled
Warning: no daemon present
Rank Owner Job Files Total Size
1st dz 6 /tmp/test.ps 3154 bytes
$ lpq -P"HP LaserJet 4M"
Warning: HP LaserJet 4M is down: printing disabled
Warning: no daemon present
Rank Owner Job Files Total Size
1st dz 6 /tmp/test.ps 3154 bytes
$ lpr -P"HP LaserJet 4M" /tmp/test.ps
$ lpq -P"HP LaserJet 4M"
Warning: HP LaserJet 4M is down: printing disabled
Warning: no daemon present
Rank Owner Job Files Total Size
1st dz 6 /tmp/test.ps 3154 bytes
2nd dz 7 /tmp/test.ps 3154 bytes
$ lprm -Php 6
dfA006nikita dequeued
cfA006nikita dequeued
$ lprm -P"HP LaserJet 4M" 7
dfA007nikita dequeued
cfA007nikita dequeued
$ lpq -P"HP LaserJet 4M"
Warning: HP LaserJet 4M is down: printing disabled
no entries
The behavior of LPRng is different and in some way inconsistent. It seems
that it accepts the long printer name without complainig but then it gives
errors when accessing the lpd queue:
# Test with LPRng 3.6.12-6
$ cat /etc/printcap
# /etc/printcap: printer capability database. See printcap(5).
# You can use the filter entries df, tf, cf, gf etc. for
# your own filters. See the printcap(5) manual page for further
# details.
#
# HP LaserJet 4M
hp|HP LaserJet 4M:\
:lp=/tmp/hp:\
:if=/etc/magicfilter/ljet4m-filter:\
:sd=/var/spool/lpd/hp:\
:lf=/var/log/lpd/%P-errs:\
:af=/var/log/lpd/%P-acct:\
:mx#0:sh:
$ lpq -Php
Printer: hp@nikita 'HP LaserJet 4M' (printing disabled)
Queue: no printable jobs in queue
$ lpr -Php /tmp/test.ps
$ lpq -Php
Printer: hp@nikita 'HP LaserJet 4M' (printing disabled)
Queue: 1 printable job
Server: no server active
Rank Owner/ID Class Job Files Size Time
1 dz@nikita+316 A 316 /tmp/test.ps 3154 16:07:04
$ lpq -P"HP LaserJet 4M"
Printer: hp@nikita 'HP LaserJet 4M'
Queue: 1 printable job
Server: no server active
Rank Owner/ID Class Job Files Size Time
$ lpr -P"HP LaserJet 4M" /tmp/test.ps
Status Information:
sending job 'dz@nikita+347' to HP LaserJet 4M@localhost
connecting to 'localhost', attempt 1
connected to 'localhost'
requesting printer HP LaserJet 4M@localhost
error 'LINK_TRANSFER_FAIL' sending str '^BHP LaserJet 4M' to HP LaserJet 4M@localhost
job 'dz@nikita+347' transfer to HP LaserJet 4M@localhost failed
$ lprm -P"HP LaserJet 4M" 316
Printer hp@nikita:
checking perms 'dz@nikita+316'
no permissions 'dz@nikita+316'
$ lprm -Php 316
Printer hp@nikita:
checking perms 'dz@nikita+316'
dequeued 'dz@nikita+316'
$ lpq -Php
Printer: hp@nikita 'HP LaserJet 4M' (printing disabled)
Queue: no printable jobs in queue
My guess is that the BSD lpr accepts the long name and then uses the
canonical name when talking to the lpd daemon with the RFC1179 protocol,
which seems quite reasonable to me from the user's point of view, while
it seems that LPRng doesn't do any checking on the name and uses the long
name to identify the queue and also while speaking to the daemon, which
evidently doesn't like whitespaces. This doesn't seems correct from my
point of view. Or we always forbid whitesspaces or we handle them in a
consistent manner.
I remember also to have read in some old lpd user manual that I can use
whatever name I like, also with embedded whitespaces, to identify a printer,
and the manual gave an explicit example of that, so I have always used this
feature.
The reason why I have signaled this bug is that I'm migrating a system
from BSD lpr to LPRng, because I want to centralize printcaps with NIS,
and the application uses long printer name both in the GUI menus and the
unix print commands.
My suggestion is that LPRng is enhanced to be fully backward compatible with
the old BSD lpr by accepting long names, as it already does now, but using
the canonical printcap entry name while talking to the daemon.
I'm sending you again the scripts encoded in base64.