Re: sh(1) and ksh(1) default PATH

[David Holland <dholland-tech%netbsd.org@localhost>]

On Mon, Aug 15, 2022 at 04:36:13PM +0700, Robert Elz wrote:
 >     Date:        Sun, 14 Aug 2022 21:41:08 +0000
 >     From:        David Holland <dholland-tech%netbsd.org@localhost>
 >     Message-ID:  <Yvlr9AbBdDJHIXrd%netbsd.org@localhost>
 > 
 >   | There's another wrinkle, which is that /usr/local and /usr/pkg should
 >   | come before /usr... except that this point is apparently contentious
 >   | and has been bikeshedded to death in the past with no consensus
 >   | reached.
 > 
 > Aside from the issue you address there, there's also the question of
 > which of /usr/local{/bin,...} and /usr/pkg{/bin,...} should come first.
 > 
 > That one is ever harder to make any general decision upon.

Not really; the same principle applies. Same with ~/bin, for that
matter, though adding that by default isn't traditional.

 > Those kinds of users need to be able to discover where they can set PATH
 > so that it works for their needs - and encouraged to do that, not told
 > "this way is the right way".

Sure. But also, in the common case, they shouldn't have to learn the
hard way that the default does not suit their needs.

It's easy to ignore these problems because you and I (and probably
most netbsd users) have session configs they've been carrying around
since the 90s or longer. However, the days where someone in the
terminal room would tell you to get started by copying ~kre/.profile
are gone for good, and furthermore we no longer in general accept
vendor-Unix-quality software deliveries. The default session needs to
function well enough for new users to get to the point where they can
figure out how to adjust it on their own. This is true regardless of
whether they're users we approve of or not.

I don't think we disagree on that, but we seem to disagree on what it
entails; for example, I don't think it's acceptable to have to type
out "/usr/X11R7/bin/startx" in longhand because whatever copy of the
default path actually took effect doesn't have X in it.

A good first step would be to hunt down all the path strings scattered
all over everywhere and fix things so that even if they have to appear
in more than one place in the installed system, there's only one copy
in the source tree.

 > And then 10 minutes later dholland-tech%netbsd.org@localhost also said:
 >
 > [stuff about dropping X tools from the path when X isn't running]

As I said, it's a nice idea, in a way, but it doesn't actually work
and isn't practical. Also, it ends up being confusing: "I thought I
installed xyz; why is it telling me it's not found?"

-- 
David A. Holland
dholland%netbsd.org@localhost