Re: nmh 1.8RC2, xlbiff, and $HOME
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 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
Re: nmh 1.8RC2, xlbiff, and $HOME
>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 release, I defer to his decision in terms of changing the behavior for the next release candidate (I would vote for making the behavior of unset and empty be the same, but I consider David the God Emperor of nmh 1.8, so it's up to him). You ask the question: What is the user trying to achieve by explicitly setting an empty HOME? To me, the answer is obvious: they were trying to create a clean environment. You say that they could do that by unsetting HOME; well, count me in the pool of people who did not know until now that 'unset' even existed. I mean, I vaguely knew that there was a difference between a variable that was never used and one that was set to an empty string, but as far as I could tell there wasn't a PRACTICAL difference between those two states and I certainly wouldn't expect an application to treat those states differently. I suspect the person who wrote that test for xlbiff didn't know about 'unset' either and would be bewildered that there is any difference in behavior. Also, some quick testing suggests that: % HOME='' command Does the expected thing but: % unset HOME command Simply unsets the HOME and 'command' variables. I realize you could do that in a subshell but it just seems awkward, and the idiom of doing % FOO=value command to change an environment variable is very common and I see why people would just use that. I have read your arguments carefully and ... well, I still do not agree that there should be a difference in behavior between an unset HOME and an empty HOME. To me there is no ambiguity and they are the same, even if it's a technically different variable state. Again, I realize we're just not going to agree on this. --Ken
Re: nmh 1.8RC2, xlbiff, and $HOME
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 way to do it’. DWIM obviously gets one tied to chair. http://www.jargon.net/jargonfile/d/DWIM.html I'm a fan of Perl, programming a lot of it in Perl 4 and early 5 days, but having introduced it to a large site of engineers who did a bit of programming, I came to see TMTOWTDI as a problem. I could read all their code because I knew all the ways. They wrote in dialects by using different subsets, reducing re-use and understanding. Many saw TMTOWTDI as a problem. It's one reason why Python has boomed. Amongst its ‘import this’ Zen are Explicit is better than implicit. In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it. An empty HOME isn't explicit in its meaning, it's ambiguous, we shouldn't guess, and the obvious way of specifying the home directory is to set HOME to it. -- Cheers, Ralph.
Re: nmh 1.8RC2, xlbiff, and $HOME
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 behaviour here. The behaviour cannot solidify further. :-) It's clear, determinate, predictable, and simple to document. I thought RCn+1 was meant to be minimal differences from RCn? That's why Andy Bradford's POP3 patch is post 1.8. Switching the behaviour of a set-but-empty HOME now seems significant given some value for HOME must be chosen. And will mean another round of testing by others on top of your time. > Ken's point that different treatmet of unset vs empty HOME is a mistake > is fairly compelling for me. I've covered that in my reply to kre just now. -- Cheers, Ralph.
Re: nmh 1.8RC2, xlbiff, and $HOME
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.
