Roland Mainz writes: > > As an architectural matter, I don't buy that story. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Erm, I missed that line... > ... from an architectural viewpoint I agree with you. But as I said > /usr/bin/man needs more fixes and when I start working on fixing > /usr/bin/man I'd like to make an "inception review" (or how it's really > called) and then start doing a full revamp. It may need some time (and I > am not sure how much time it needs since I have to find a normal job > first and do that project in my free time) and I really would prefer > that the people here start opening their hearts for the end-users and > try to get some small improvements done _now_. It's architecturally not > correct but it would help lots of the end-users. Remeber these cases are > about _usuablity_ which is difficult to measure with a "foot rule" or > other physical tools...
It's not an issue of "opening [our] hearts." Please don't pretend as though the folks reviewing your proposal are hostile to users. That's just not the case, and it makes it very difficult to comment rationally on the proposal. The concern I have is that the proposed solution may well be at odds with a better solution. In other words, suppose we do go with your proposal to set MANPATH exactly once during shell start-up, based on the PATH at that point. If the user changes his PATH, MANPATH won't get those changes. But that's just life with environment variables. If we later come along and enhance /usr/bin/man so that it searches the ../bin parallels of PATH, but only when MANPATH is unset (in order to honor compatibility), then the proposed "fix" from this project will actually get in the way and will need to be undone -- somehow. So, why produce a poor answer when a better one is possible? -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
