Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!henry
From: henry@utzoo.UUCP (Henry Spencer)
Newsgroups: net.unix-wizards
Subject: Re: deceptive mail
Message-ID: <4662@utzoo.UUCP>
Date: Tue, 20-Nov-84 14:00:27 EST
Article-I.D.: utzoo.4662
Posted: Tue Nov 20 14:00:27 1984
Date-Received: Tue, 20-Nov-84 14:00:27 EST
References: <221@turing.UUCP> <4632@utzoo.UUCP>, <225@turing.UUCP>
Organization: U of Toronto Zoology
Lines: 31

> > This should not be a staggering surprise; the login operation is not
> > recursive, and trying to use it that way is obviously a disaster in the
> > making.  The correct approach to this particular problem is to fix login
> > to recognize, and reject, attempts at recursive logins.
> 
> Well, perhaps. I do not see the possibility of a recursive login as
> something that is broken and should be fixed, in fact I use it almost daily.
> 
> My only point was to warn you that the value returned by getlogin() is
> not always reliable.

Well, you pays your money and you takes your choice.  Either you say that:

	(a) the value from getlogin() isn't reliable
	(b) the environment on login can be a strange mishmash of the
		user's environment and the previous user's environment
	(c) the stty settings ditto

or
	(d) the login operation is not recursive, and hence leads to
		confusion if you try to use it that way.

It sure sounds to me like (d) is the simpler explanation of the phenomena.
The fact is, login is modifying "global variables" like the utmp entry,
the environment, and the stty settings, and they don't get put back later.
This is practically the *definition* of something that isn't recursive.
Oh, sure, you can use it that way... provided you aren't too fussy about
the results.
-- 
				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,linus,decvax}!utzoo!henry