Path: utzoo!attcan!uunet!auspex!guy
From: guy@auspex.UUCP (Guy Harris)
Newsgroups: comp.unix.wizards
Subject: Re: script & lock
Keywords: getlogin(3)
Message-ID: <837@auspex.UUCP>
Date: 12 Jan 89 19:45:42 GMT
References: <17972@adm.BRL.MIL> <596@cf-cm.UUCP> <15399@mimsy.UUCP> <6925@june.cs.washington.edu>
Reply-To: guy@auspex.UUCP (Guy Harris)
Organization: Auspex Systems, Santa Clara
Lines: 47

>A process running under script is attached to a pty, and there is
>(presumably) a utmp entry for the pty, so getlogin should return
>the user name from the /etc/utmp entry for the pty.  Since no user
>is actually logged onto the pty, the name in the /etc/utmp entry is
>the null string.

Which means that the S5R3 and 4.3BSD versions of "getlogin" will return
a null pointer.  I don't have older versions handy, so I can't say that
this behavior dates back to V7.

>So unless Berkeley screwed up, code that depends upon getlogin
>returning a NULL pointer when it encounters a null string won't be
>portable to vanilla 4.3 BSD.

Berkeley's only screwup - or AT&T's screwup, if the wording in question
is derived from that in the 32V manual page - is that they didn't make
it clear that the "utmp" entry in question must not only exist (in the
sense that an entry in "/etc/ttys", for V7/BSD, or an entry in
"/etc/utmp" of type INIT_PROCES, LOGIN_PROCESS, USER_PROCESS or
DEAD_PROCESS, for S5, exists specifying the terminal in question), but
that it must represent a valid entry (in the sense that it must not have
a null user name). 

The code in question *is* portable to vanilla 4.3BSD, because 4.3BSD's
"getlogin" *does* return a NULL pointer when it encounters a null
string; the fact that the manual page may not explicitly say so is
arguably a deficiency of the manual page (unless you consider it to be
implicit in the description that the "utmp" entry must really specify a
user), but it doesn't affect the portability of code....

>It certainly won't be portable to Ultrix 2.3 (a 4.2 BSD derivative
>which we run here).

This according to the Ultrix documentation, or the Ultrix code (either
by inspecting the code or by probing its behavior)?  I don't have 4.2BSD
source handy to check, but if 4.2BSD returns NULL if the user name is
null and Ultrix doesn't, the screwup there is DEC's.

>I will resist commenting on whether 4.2 and 4.3 BSD can accurately
>be described as "broken Unixes"

If a system that returns NULL if the user name is a null string is
broken, that means 4.3BSD, 4.3-tahoe, and S5R3 are broken, and other
4.xBSD and S5 systems may be broken as well - perhaps even V7 and S3. 
If that's the case, I'd be inclined to say the only thing broken about
those systems may be the documentation, and say that systems that
*don't* provide that behavior are broken.