I also use xlbiff and would like it to continue working without needing to fuss with it.
The next best option for me is that I might be required to set some environment variables in a sane way that doesn't cascade into the operation of other programs. Thanks for uncovering this release client change/issue! On Mon, Jan 30, 2023 at 10:47 AM Stephen Gildea <stepheng+...@gildea.com> wrote: > I have investigated the failure of the xlbiff tests with nmh 1.8RC2. > (This is https://bugs.debian.org/1029752) > > In one of the tests, xlbiff sets environment variable HOME to an empty > string and MH to a file containing a custom profile with an absolute Path. > With nmh 1.7.1, this environment works. > > With nmh 1.8RC2, this environment fails with the error message > "environment variable HOME is empty". > > You can see the change in behavior as follows: > > $ printf 'Path: /tmp\n' > /tmp/mh-profile-minimal > $ HOME= MH=/tmp/mh-profile-minimal /usr/bin/mh/mhparam path > > > nmh 1.7.1: > /tmp > > nmh 1.8RC2: > mhparam: environment variable HOME is empty > > > My analysis: > > This is a regression. HOME is used only to set the default profile > file to "$HOME/.mh_profile". But nmh doesn't need HOME if MH is set. > > A further documentation issue: mh-profile(5) does not specify the > treatment of a relative Path. I expected it to be relative to the > directory of the profile file, but it seems to actually be relative to > HOME. > > Whatever your decision, the choice should be documented. If you decide to > keep Path relative to HOME, then HOME should be required to be non-empty if > (and only if!) Path is relative. (nmh 1.7.1 used "/", which seems wrong.) > > < Stephen > >
