Ralph wrote:
> 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.
I'd rather crank out an RC3 than pass up the opportunity to solidify
the behaviour
Ralph Corderoy wrote in
<20230131181958.1cfb121...@orac.inputplus.co.uk>:
...
|But if HOME is empty we do not know their intent so to ignore it and use
|pw_dir may not be what they think will occur. The wrong profile could
|be read or the wrong .netrc used, upsetting the user.
By the way my
Date:Tue, 31 Jan 2023 13:29:46 +
From:Ralph Corderoy
Message-ID: <20230131132946.44a5f20...@orac.inputplus.co.uk>
| > Similarly, in XCU 4 in the description of the cd utility:
| Yes, but also allowed there is âemptyâ which also triggers
|
Date:Tue, 31 Jan 2023 13:22:19 +
From:Ralph Corderoy
Message-ID: <20230131132219.5e02b20...@orac.inputplus.co.uk>
| It looks to me like code assumes mypath isn't NULL, e.g. exmaildir(),
| so not bothering to call set_mypath() if MH is set doesn't look a goer.
Date:Tue, 31 Jan 2023 18:19:58 +
From:Ralph Corderoy
Message-ID: <20230131181958.1cfb121...@orac.inputplus.co.uk>
| 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
Hi Ken,
> > What's the intent of an empty HOME?
> > Is it set by accident when it's meant to be unset?
> > Is it empty by accident when it's meant to be non-empty?
> > Do they want HOME=/, HOME=$PWD, or are they expecting it to error.
> > Any choice could be not what the user intended so exit.
>
>What's the intent of an empty HOME?
>Is it set by accident when it's meant to be unset?
>Is it empty by accident when it's meant to be non-empty?
>Do they want HOME=/, HOME=$PWD, or are they expecting it to error.
>Any choice could be not what the user intended so exit.
I mean ... you could say
On Jan 31, 2023, at 8:32 AM, Ralph Corderoy wrote:
>
> Hi Ken,
>
>>> So an unset HOME is allowed by this function, it's an empty HOME
>>> which isn't.
>>
>> It strikes me as strange that there is a difference between an unset
>> HOME and an empty HOME in terms of behavior. I mean, yes, I can
Hi Ken,
> > So an unset HOME is allowed by this function, it's an empty HOME
> > which isn't.
>
> It strikes me as strange that there is a difference between an unset
> HOME and an empty HOME in terms of behavior. I mean, yes, I can see
> how the code is written, the historical precedent and how
>So an unset HOME is allowed by this function, it's an empty HOME which
>isn't.
It strikes me as strange that there is a difference between an unset
HOME and an empty HOME in terms of behavior. I mean, yes, I can see how
the code is written, the historical precedent and how we got here, but
...
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,
Hi az,
> "Author: Ralph Corderoy
> Date: Thu May 13 13:46:20 2021 +0100
>
> sbr/path.c: add set_mypath() to factor out repeated code."
I think it's worth expanding on that.
commit d8ca46fabc26469be325b73a73dcc26e70681eb5
Author: Ralph Corderoy
Date: Thu May 13 13:46:20 2021
Hi David,
> I'd like to get Ralph's take on what we should do.
Thanks. If my suggestion to Stephen of unsetting HOME works and is
acceptable to him then I suggest we don't change nmh for this release.
> > A further documentation issue: mh-profile(5) does not specify the
> > treatment of a
Hi Stephen,
> I have investigated the failure of the xlbiff tests with nmh 1.8RC2.
Thanks.
> $ printf 'Path: /tmp\n' > /tmp/mh-profile-minimal
> $ HOME= MH=/tmp/mh-profile-minimal /usr/bin/mh/mhparam path
My suggestion for a quick fix to try is to not have HOME in the
environment so
14 matches
Mail list logo
