>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
