Minor lp/lpr command oddity

John A. Murdie john at cs.york.ac.uk
Mon Jul 24 09:51:46 PDT 2006


I note the difference in error/warning messages when one gets (deliberately) muddled over 'lpr -P' and 'lp -d'?

; lpr -dpp23 pikestyle.ps
lpr: warning - 'd' format modifier not supported - output may not be correct!
; lp -Ppp23 pikestyle.ps
lp: unable to print file: client-error-bad-request
;

There is no `lpr -d' option, and  `lp -P' selects a list of pages to be printed; a muddled user will see at least one rather unhelpful error/warning message. The `lpr: warning - 'd' format modifier ...' message gives a fair hint, but why does 'lp -Ppp23' not produce an error message such as:

lp: error - invalid page range "pp23" as argument to -P option

which would help unmuddle them, I think*. The correct commands:

lpr -Ppp23 pikestyle.ps

and:

lp -dpp23 pikestyle.ps

work without any error/warning message as I'd expect, though I note that lp writes e.g: `request id is pp23-123 (1 file(s))' whereas lpr writes nothing - why, is this required behaviour, and the result of Unix print system history?

I felt I had to see what would happen if a user confused the correct 'lpr -P' and 'lp -d'; all the fault of Unix having a divided (Berkeley (lpr(1)) and AT&T (lp(d))) heritage which I presume CUPS has to continue for backwards compatibility.

Also, although many users will print from a GUI these days, I think all textual print commands should make it clear in their error messages if the print submission has not been accepted**, even if `error' always implies this, e.g.

lpr: error - invalid page range "pp23" as argument to -P option (document not queued for printing)

I'll make these two points (* and ** above) feature requests via the bugs interface if you wish.




More information about the cups mailing list