Re: nmh 1.8RC2, xlbiff, and $HOME

[Ralph Corderoy]

Hi kre,

Thanks for your learned input on this.  As I said in another reply just
now, where I listed set_mypath(), HOME being unset is fine as getpwuid()
is the fallback in which case pw_dir must be non-empty.

> > Alexander does point out that HOME is supposed to be valid according
> > to POSIX,
>
> That's actually not correct, all the text quoted requires is that HOME
> be set at login time - nothing at all about what can be done with it
> after that.

Agreed.  Nearby, is:

    8.1 Environment Variable Definition

    ...
    Some are placed into the environment by the implementation at the
    time the user logs in; all can be added or changed by the user or
    any ancestor of the current process.

Does ‘changed’ include unsetting them?  I'd expect the spec. to be
precise and list ‘unset’ to clarify if they can.

> Further POSIX reading will also find, in the description of ~
> expansion in the shell (XCU 2.6.1 in Issue 7 TC2 - the current version
> from 2018):
>
>     If the login name is null (that is, the tilde-prefix contains only
>     the tilde), the tilde-prefix is replaced by the value of the
>     variable HOME.  If HOME is unset, the results are unspecified.
...
> Setting HOME='' isn't even mentioned: in that case ~/foo expands to
> /foo (which is actually what you want

Agreed, it isn't mentioned.

> Similarly, in XCU 4 in the description of the cd utility:
>
>     1. If no directory operand is given and the HOME environment
>     variable is empty or undefined, the default behavior is
>     implementation-defined and no further steps shall be taken.
>
> Again, HOME being unset is allowed there, this time with
> implementation-defined results (which just means the implementation
> must say what happens in the doc).

Yes, but also allowed there is ‘empty’ which also triggers
implementation-defined.

Also, POSIX's chdir(3) says

           int chdir(const char *path);
    ...

    ERRORS
           The chdir() function shall fail if:
           ...
           ENOENT  A component of path does not name an existing
                   directory or path is an empty string.

chdir(NULL) is invalid, obviously.  But so is chdir("") so if an empty
HOME is really to be treated as the root directory then code can't do

    h = getenv("HOME");
    r = chdir(h ? h : "/");

but must instead

    r = chdir(h && *h ? h : "/");

I expect lots of non-nmh code doesn't do that extra check so the chdir()
has no effect and the error return may not even be tested so an empty
HOME results in the current directory being used rather than /.

> Running with HOME unset is not even all that unusual

I think it is a bit.  :-)

> "env -i command" results in that

Agreed, my self-at(1)-ing shell scripts run at(1) under ‘env -i’ but
bequeath HOME, LANG, LOGNAME, and PATH at the same time.

> (and I'd even retain: relative to / if HOME is not set, which it can
> be when there as been no login - like when you're in single user
> mode).

It would be nice for nmh to work in single-user mode as reading email
might be vital in fixing problems.  As long as HOME is unset and pw_dir
is valid then all is well at the moment.

> I'd also suggest never issuing errors because the user's environment
> isn't like we think it ought to be, unless that actually prevents
> something functioning as intended.

The code I replaced mislead the user as to the cause of the exit.
That's fixed and no HOME is okay.  The possible errors are now

    environment variable HOME is empty
    password entry not found
        [perhaps with ‘getpwuid() failed’ and errno if it did]
    password entry has empty home directory

This close to a release, I think we should stick with requiring HOME to
be non-empty if it's set as otherwise there's too many paths to consider
which the test harness probably doesn't exercise.

> But I agree that a relative Path in MH should be relative to HOME

Yes, I think it's too late to alter that.
Though ‘path: mail’ would be a more Unixy default.  :-)

-- 
Cheers, Ralph.