Re: nmh 1.8RC2, xlbiff, and $HOME

[Ralph Corderoy]

Hi kre,

> There is never a need to deliberately make anything an error to
> satisfy user expectations, if the user wants a complaint about HOME
> being an empty string, rather than some other behaviour, all they need
> is one of...

My stance has nothing to do with satisfying ‘user expectations’ so I'll
ignore this aspect.

> > No, one cannot say of an unset HOME that it may be set by accident.
>
> No, but it may have been unset by accident, where the intended value
> for mh to use was something different than the pw_dir entry.   No-one
> can possibly know in that case, any more than in the case where
> HOME=''

(I think you've over-cropped in general.)

There is a marked difference which I thought I had made very clear.

There are three cases.  All may be accidental or deliberate, obviously.

1.
- HOME is unset.
- This is valid, i.e. POSIX allows it.
- The only route for continuing is it to use a mandatory passwd.pw_dir.
- HOME=passwd.pw_dir results.

2.
- HOME is set and non-empty.
- Use it.
- If that causes errors then die, do not try again with passwd.pw_dir.
- HOME=$HOME results.

3.
- HOME is set but empty.
- There are at least three ways of continuing.
    - Pretend HOME=$PWD
    - Pretend HOME=/
    - Pretend HOME=passwd.pw_dir
- Other alternatives include trying HOME=... until one ‘works’.
- HOME=??? results.

There is no obvious way to continue for 1 and 2 other than the above.
The result is not surprising.  Even if the manual isn't read.

If 3 is implemented then the user may have thought a different pretence
would occur.  After all, it's an arbitrary choice.  Perhaps he expects it
will carry on just like his shell does.

This could result in surprising files being read, e.g. /tmp/.mh_profile,
and unwanted commands being run, e.g. through a profile's ‘moreproc’ or
‘mhshow-show-text/plain’.  (top(1) had a similar issue.  It used $PWD
when HOME was unset or empty allowing a privilege escalation through its
configuration file; cue CVE.)

Turning it about.  What is the user trying to achieve by explicitly
setting an empty HOME?  Whatever it is, he can achieve it in an
*unambiguous* manner by unsetting HOME or setting it to a non-empty
value.  It seems you're arguing for him to instead first refer to the
manual to determine what set-but-empty means to nmh in the hope it
matches his need when he could just take and explicit short-cut?

> There is always ambiguity if you are doing something different than
> what is documented to happen.

That is not ambiguity.  That is error.

mh_profile(5) can easily say HOME must be non-empty if set for those
that read the fine manual.

> The question is what is best for nmh - and for that I agree with Ken,
> treating an unset HOME and HOME='' differently is a mistake.
> All that is required to make that OK is to document it.

No, you must decide which of the many alternatives of 3 above is the
‘nmh way’, document that, test it, and have some users be surprised by
the result.  There is no ‘All that...’.

Ken, you, and David all seem irked by unset and set-but-empty being
treated differently, as if you'd like a binary outcome by first
conflating the ternary input to binary.  There isn't a clear method of
merging those two inputs.  Ternary's messy, as ever.  We can't stop HOME
being unset or being empty so there are three safe outcomes for three
inputs.

-- 
Cheers, Ralph.