Bug#3038: PATCH for lpr

[Carlos Carvalho <carlos@riglos.fisica.ufpr.br>]

Maybe some of you remember the problems I discussed some time ago
about lprm not working when you try to remove a job in a remote
machine. I didn't hear from the maintainer, nor did I see a new
version of the lpr package, so here's a patch to lpr that fixes the
problem.

--- lpr-5.9/lpr.c.orig	Sat May 21 17:35:05 1994
+++ lpr-5.9/lpr.c	Wed Jun 12 15:22:16 1996
@@ -60,6 +60,7 @@
 #include <unistd.h>
 #include <stdlib.h>
 #include <string.h>
+#include <netdb.h>
 #include "lp.local.h"
 #include "pathnames.h"
 
@@ -128,6 +129,14 @@
 
 	name = argv[0];
 	gethostname(host, sizeof (host));
+	{ /* use the official host name, like lprm */
+		register struct hostent *hp;
+
+		if (hp = gethostbyname(host))
+			strcpy(host, hp->h_name);
+		else
+			fatal("unable to get official name for local machine");
+	}
 	openlog("lpd", 0, LOG_LPR);
 
 	while (argc > 1 && argv[1][0] == '-') {


Another problem is the one mentioned by IJ, that lprm kills the
instance of lpd that's printing the removed job. It finds the pid of
the process from the control files, but this isn't good because pids
are re-used. This is only a problem if the process that was printing
got killed without the files being removed; it's unlikely, but may
happen. I don't know how to fix this in an elegant way. One
possibility is to check that ppid of the one you want to kill is the
same as yours, since they all come from the same parent. However, I
don't know how to get the ppid of another process. It certainly is
possible, but maybe only in a linux-specific way.

The lpr suite has behaved like this from the beginning I think, and as
I don't have a good way to fix it I prefer to leave it as is.

Finally, another weird problem. lpd is complaining about invalid
printer names, but the printcap is correct; also, the behaviour is
somewhat erratic. To debug this I inserted a fprintf in the routine
that gets the hole lines from /etc/printcap, to show the full line,
and in the calling routine, to show the returned value. This is inside
a loop, that finishes when the printcap file ends. I also just made
the forked children exit immediately. This way I got a large dump,
with many repetitions of the printer entries, which is obviously
bogus. However, putting a fflush right after the two fprintf's the
problem disappeared completely!! Am I missing something or is there a
problem elsewhere?

Carlos