Ralph wrote:
> Your principles soon went out the window.
Oh no, they're all still there. One of them just got moved to the front.
David
Hi David,
> Then I think that we should do the same in 1.8 for all platforms.
Your principles soon went out the window.
--
Cheers, Ralph.
az wrote:
> minor data point: after following the discussion here, i've decided
> that for now _the debian packages_ of nmh should not distinguish
> between unset $HOME and set-but-empty $HOME, and that either should cause a
> fallback to getpw*.
Then I think that we should do the same in 1.8
etween unset $HOME and set-but-empty $HOME, and that either should cause a
fallback to getpw*.
(1.8RC2 will hopefully/likely be part of the upcoming debian
release; the previous release shipped with 1.7.1.)
regards
az
Description: treat set-but-empty $HOME same as unset
upstream code aborts on
I wrote:
> What case am I missing?
I get it: the non-null, empty HOME. Anyways, I'd like to keep the 1.7
behavior for 1.8 and change it after. Can we agree to that?
David
Ralph wrote:
> Hi David,
>
> > And my feeling at this point is to put out an RC3 with the 1.7
> > behavior for $HOME.
>
> Which, to be clear, is not the behaviour Ken and kre want. :-)
I was thinking that just removing the if (!*var) statement from your
code, leaving:
char *var =
Hi David,
I've had one night's sleep spread over the last two nights so I'm not
going to have time for nmh until the weekend.
> And my feeling at this point is to put out an RC3 with the 1.7
> behavior for $HOME.
Which, to be clear, is not the behaviour Ken and kre want. :-)
Stephen, I'd
Ralph wrote:
> The behaviour cannot solidify further. :-) It's clear, determinate,
> predictable, and simple to document.
Those qualities can be true for the 1.7 behaviour.
> I thought RCn+1 was meant to be minimal differences from RCn?
If there's an RC3, the only code difference would be
Date:Wed, 01 Feb 2023 14:54:36 +
From:Ralph Corderoy
Message-ID: <20230201145436.1aa5222...@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
>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.
Sigh. I'll try to make my point clearer, but I recognize we're not going
to agree on this. Since David is driving this
Hi,
I wrote:
> 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 has overlap with DWIM, ‘do what I mean’, and Perl's TMTOWTDI,
‘there's more than one
Hi David,
> > 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
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’
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 s
Ken Hornstein wrote:
> >$ printf 'Path: /tmp\n' > /tmp/mh-profile-minimal
> >$ HOME= MH=/tmp/mh-profile-minimal /usr/bin/mh/mhparam path
>
> Thank you for the analysis. I am wondering, though ... WHY does xlbiff
> set HOME to '' for this test?
To be clear, it is not xlbiff itself
Stephen wrote:
> 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.
Thanks for your analysis. I'd like to get Ralph's take on what we
should do.
> A further documentation issue:
Date:Mon, 30 Jan 2023 16:11:26 -0500
From:Ken Hornstein
Message-ID: <20230130211131.8e81d1df...@pb-smtp20.pobox.com>
| 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
>$ printf 'Path: /tmp\n' > /tmp/mh-profile-minimal
>$ HOME= MH=/tmp/mh-profile-minimal /usr/bin/mh/mhparam path
Thank you for the analysis. I am wondering, though ... WHY does xlbiff
set HOME to '' for this test?
(I am neutral on whether or not this is technically a regression; I can
see it
On Mon, 30 Jan 2023 10:47:05 -0800, Stephen Gildea writes:
>I have investigated the failure of the xlbiff tests with nmh 1.8RC2.
>(This is https://bugs.debian.org/1029752)
stephen, thanks for that.
>In one of the tests, xlbiff sets environment variable HOME to an empty
>string and
change/issue!
On Mon, Jan 30, 2023 at 10:47 AM Stephen Gildea
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
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
Jerry wrote:
> Success on Mageia Linux 8. Working as promised, using live for email
> as I type.
Thanks, Jerry.
David
On Sat, 28 Jan 2023 06:17:09 -0800, David Levine wrote:
> How does 1.8RC2 look? BSD users, have any of you tried it?
>
> For RedHat and Fedora users, you can install or upgrade using one of:
> sudo dnf install nmh --enablerepo=3Dupdates-testing
> sudo dnf upgrade n
Ken wrote:
> >> But ... did we ever get a resolution on the long lines POP patch?
> >
> >No. How about we defer to post-1.8?
>
> Can we tenatively say that it's targeted for 1.8.1?
Sure, that sounds great.
And it would be great to have shorter release cycles for 1.8.1 (and
beyond), but I know
>> I wanted to test it on MacOS X.
>
>I did. Success both with debug and non-debug builds.
>
>> But ... did we ever get a resolution on the long lines POP patch?
>
>No. How about we defer to post-1.8?
Can we tenatively say that it's targeted for 1.8.1?
--Ken
Bakul wrote:
> On Jan 28, 2023, at 6:17 AM, David Levine wrote:
> >
> > How does 1.8RC2 look? BSD users, have any of you tried it?
>
> Works on FreeBSD 13. make check succeeds + random commands
> I tried worked fine.
Thank you, Bakul.
David
On Jan 28, 2023, at 6:17 AM, David Levine wrote:
>
> How does 1.8RC2 look? BSD users, have any of you tried it?
Works on FreeBSD 13. make check succeeds + random commands
I tried worked fine.
On Sun, 29 Jan 2023 11:54:06 -0800, David Levine writes:
>Including Stephen Gildea, the Debian maintainer of xlbiff.
stephen's already indicated that he'll look into it.
https://bugs.debian.org/#1029752
>I hope the issue can be resolved.
same here. originally i slightly suspected the 'welcome
Ken wrote:
> I wanted to test it on MacOS X.
I did. Success both with debug and non-debug builds.
> But ... did we ever get a resolution on the long lines POP patch?
No. How about we defer to post-1.8?
David
Including Stephen Gildea, the Debian maintainer of xlbiff.
Ralph wrote:
> Finding a Debian system, I think it's more that package xlbiff depends
> on nmh.
So it does, thanks. I hope the issue can be resolved.
David
>If all goes well, I hope to release 1.8 within a week.
I wanted to test it on MacOS X. But ... did we ever get a resolution on the
long lines POP patch?
--Ken
Hi David,
> Alexander wrote:
> > https://qa.debian.org/excuses.php?package=nmh
>
> It looks like that dependent package is xbiff. Do you know how that
> is identified as a dependecy? I don't see it as an explicit
> dependency in nmh itself.
Finding a Debian system, I think it's more that
Alexander wrote:
> debian: works well. however, 1.8 might not make it into the upcoming
> release (upload freeze is just weeks away and one nmh-dependent package
> has a test suite bug that blocks nmh from going in...
> https://qa.debian.org/excuses.php?package=nmh)
It looks like that dependent
Pascal wrote:
> I have been using it (and previously rc1) on OpenBSD since it came out.
> No issues so far.
Thank you, Pascal.
If all goes well, I hope to release 1.8 within a week.
David
On Sat, 28 Jan 2023 06:17:09 -0800, David Levine wrote:
> How does 1.8RC2 look? BSD users, have any of you tried it?
I have been using it (and previously rc1) on OpenBSD since it came out.
No issues so far.
> For RedHat and Fedora users, you can install or upgrade using one of:
>
On Sat, 28 Jan 2023 06:17:09 -0800, David Levine writes:
>How does 1.8RC2 look?
debian: works well. however, 1.8 might not make it into the upcoming
release (upload freeze is just weeks away and one nmh-dependent package
has a test suite bug that blocks nmh from going in...
https://qa.debian.
How does 1.8RC2 look? BSD users, have any of you tried it?
For RedHat and Fedora users, you can install or upgrade using one of:
sudo dnf install nmh --enablerepo=3Dupdates-testing
sudo dnf upgrade nmh --enablerepo=3Dupdates-testing
David
50 matches
Mail list logo
