Re: nmh 1.8RC2, xlbiff, and $HOME

[Robert Elz]

    Date:        Wed, 01 Feb 2023 14:54:36 +0000
    From:        Ralph Corderoy <ralph@inputplus.co.uk>
    Message-ID:  <20230201145436.1AA5222058@orac.inputplus.co.uk>

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

Ralph, do you not see the contradiction between that, and:

  | If 3 is implemented then the user may have thought a different pretence
  | would occur.

which is exactly a desire to satisfy user expectations, and when you
don't know what they are, refuse to do anything.

There is plenty in nmh that doesn't act (by default) to satisfy my
expectations, but that's OK, it works as documented, and there is
generally a method by which I can achieve what I want.

Why does this need to be different?

  | After all, it's an arbitrary choice.  Perhaps he expects it
  | will carry on just like his shell does.

Perhaps.   But we cannot meet that objective, as shells do different
things, there are many to choose from, but there is just one nmh (well
two, if you count the mmh I recall hearing of).   Do you think we should
create nmh forks so users can pick the one that meets all their expectations
by default?

  | This could result in surprising files being read, e.g. /tmp/.mh_profile,

Yes, if someone's pw_dir is /tmp ... but then that is what it should do.
No-one is suggesting treating an empty HOME literally (as "") in this
context, nor as "." or anything odd - just treat it the same as an unset
HOME.   If the user doesn't like that, then HOME should be set to whatever
they want it to be.   Simple.  Clean.   Easy to document.

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

It can.   But what's the point?

  | 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.

We have already had users (the xlbiff test suite) be surprised by the
current result - which was not only unexpected, it varied from earlier
behaviour.

  | 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.

That's solely because that's the way you see it.   It is entirely
possible to treat two different settings (such as +0 and -0 in one's
complement arithmetic) as meaning the same thing in one context, such
as they do when using normal + - * / operations, yet a different one
in a different context (like & | ^ bit operations).   That's just the
way things work.   Treating an unset HOME and an empty but set HOME
the same in nmh is a perfectly valid choice, and seems to be the
preferred one.

kre