lprm doesn't handle non-existing queues properly - it doesn't report that
no such queue exists, and it doesn't set a non-0 return value.
This defect is considered MUST-FIX for Winston Gold-release
This functionality would be VERY non-trivial to add, as the lprm output is
actually coming from lpd, so we would need a parser to parse a status request
before we made the removal request, which would significantly complicate the
workings of lprm.
Adding this functionality without changing any other behaviour would be a very
I am going to send a feature request to the LPRng upstream, and closing this as
Fixing a bug is an enhancement, and this is a bug - not an RFE.
Besides, adding checks for queues either in the daemon or lprm itself is a
little work, but very far from risky.
The spooler checks for spools, of course, it just doesn't tell
the client if it didn't find any, and changing the communtication
nature of lpd is the wrong thing.
The only Right Thing is to make a status request on the spooler,
parse the text block it returns, and figure out if it has that spool,
then make the remove call if it does, and drop an error if it doesn't.
This is not a trival problem, the complexity of lprm goes up by a second
network call and a parser, and adding this without breaking anything else is
This IS an enhancement. There is no documented behaviour that says there will
be an error message, and it did not do it before. I've sent an enhancement
to the author. Just because you want it to do something does not mean there is a
if it was not designed to do it.
It's clearly a bug not to report that a queue is non-existing - I don't see any
point arguing that. Saying otherwise would imply that e.g. gcc could quietly do
nothing if asked to operate upon a non-existing file... and that fixing that
would be an enhancement, not a fix. "Enhancement" in bugzilla means "new
Back to the main topic: Yes, I think it should do a new call if necessary.
It is not 'clearly' a bug.
the lprm behaviour is documented as:
Lprm will announce the names of any files it removes and is silent if
there are no
jobs in the queue which match the request list. If the job being
active, the LPD server will stop printing the job and then restart
So this is a special case (there are never any jobs waiting in a non-existant
Now admittedly, there are some lprm programs which behave differently, But that
is not the point.
The point is that this would significantly change the internal behaviour of the
lprm that we ship, and could quite easily generate a bit of surprise on the user
end. The lack of response if a spool does not exist is not surprising to LPRng
But if we put a parser into the lpr code, we have to change it every time the
lpd output format changes, and parsers are not simple code, it would be a
relatively large patch for a piece of funcionality that A) is not internaly
developed, and B) works now.
I have sent a feature request to the author, well see what he says about adding
it, but adding a parser at the moment is much more likely to increase bugs than
to close this minor issue.
So I am NOT adding a parser because a trivial error issue does not warrant that
kind of rewrite for a piece of external code.
You don't need a fullblown parser at all, but if you want to close it as
"WONTFIX" feel free.
Some bugs go that way.
Ok I'm checking my depends packages, and the conces seems to be wontfix so I'm
closing this reopen if I've closed it wrongly.