Re: [nmh-workers] I Could Have Sworn that the inc Command used to work.

[Bakul Shah]

On Jun 4, 2019, at 10:08 AM, Ken Hornstein <address@hidden> wrote:
>> This fails when there are multiple users with the same uid as getpwuid()
>> will likely fetch the first matching entry. On FreeBSD (& May be other
>> BSDs) getlogin() is a syscall and works correctly without a controlling
>> terminal.  But I was forgetting about Linux which never disappoints
>> in disappointing.  I think use of $LOGNAME as a fallback may be good
>> enough.
> 
> I have to say ... if you have multiple users with the same UID, you deserve
> whatever breakage you get.  According to POSIX:

May be so but this is allowed and getpwuid(geteuid()) will do the wrong
thing for all but one login id sharing the same uid.

>       The getlogin() function shall return a pointer to a string
>       containing the user name associated by the login activity with
>       the controlling terminal of the current process.

The next sentence in getlogin(3P) says this:

    If getlogin() returns a non-null pointer, then that pointer points
    to the name that the user logged in under, even if there are several
    login names with the same user ID.

> Also, POSIX says about LOGNAME:
> 
>       The system shall initialize this variable at the time of login
>       to be the user's login name.
> 
> I am unclear on what "login" means; does it apply when running as part
> of a .forward file?  When you have a controlling terminal, yes, that is
> understood but I see no guarantees for other execution environments.

Practically speaking, pretty much all the programs I have seen use
either $USER or $LOGNAME. Cron automatically sets up LOGNAME, HOME,
SHELL and PATH before invoking a user specific cron job.

> True story: a long time ago we had a number of IRIX systems.  The inetd
> on those systems was buggy so it was common when you changed the inetd
> configuration you just restarted it instead of sending it a HUP signal.
> But even though the person who did this had su'd to root, some of their
> user environment variables were inherited by their root shell and then
> inherited by inetd ... and those made it down into various daemons
> spawned by inetd which caused a whole bunch of confusing behavior at
> login time.  We eventually figured that out and fixed everything, but it
> just made me realize that depending on inherited environment variables
> isn't always safe.  If nmh already depended on LOGNAME or USER, then
> I'd be fine with keeping that behavior but I just fear the unintended
> consequences of making a significant change like this.

Perhaps but most every program that cares already uses USER or
LOGNAME. I would’ve preferred getlogin() but Linux.