lpr + getlogin() (was: When is set[re]uid() effective? [...])

[Maarten Litmaath]

purple at hadrian.uwo.ca (Lori Corrin) writes:
\...
\  lpr searchs /etc/utmp for some unknown reason. [...]

The relevant part of lpr.c:

	if ((person = getlogin()) == NULL || (pw = getpwnam(person)) == NULL) {
		userid = getuid();
		if ((pw = getpwuid(userid)) == NULL)
			fatal("Who are you?");
		person = pw->pw_name;
	} else
		userid = pw->pw_uid;

The getlogin() call is ridiculous. (I can imagine why the author put it in:
normally strcmp(getlogin(), getpwuid(getuid())->pw_name) == 0, and getlogin()
is (was) generally faster; if the print job is a batch job, speed doesn't
really matter.)
Anyway, circumvent it by a front-end:

	% cat mylpr
	#!/bin/sh 
		 
	exec 3>&1

	test -t 0 && exec < /dev/null

	(/usr/ucb/lpr ${1+"$@"} | cat >&3) 2>&1 | cat >&2
	%

Now neither stdin, nor stdout, nor stderr refers to a terminal, as far as
lpr is concerned.
lprm needs such a wrapper too.

BTW:
1) sh seems to lack a `redirect to pipe' feature, something like

	cmd 1| stdout_filter 2| stderr_filter

   Instead one needs all those messy file descriptor manipulations to
   accomplish the desired effect.

2) To Lori: nice login name, `purple'; I can guess your favorite group. :-)
-- 
   "... a lap-top Cray-2 with builtin    |Maarten Litmaath @ VU Amsterdam:
cold fusion power supply"  (Colin Dente) |maart at cs.vu.nl, mcvax!botter!maart