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

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    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.

In all of this we can adopt the attitude "all the users are morons and
cannot make a decision, or configure things even if they knew what they
wanted to configure, so we will decide for them" which some other systems
are doing.

That certainly makes it easier for the users who are morons (at least wrt
operating system setup, whatever their accomplishments in other areas).

But, IMO, for NetBSD, at least right now, those aren't the users we need
or really even want.

We don't need them as they can't help the project much (they can report
bugs, but more than half the time the seeming bugs reported aren't).
There's almost no chance that any time soon there could be enough of
them to encourage better manufacturer support for NetBSD.

We don't want them, as they need support, and we don't have the resources
to do that.   We're running years behind on hardware support, so everyone
who says "I just bought a XYZ and it doesn't work" is likely to be 
disappointed.   We don't have the manpower to even just answer questions
from a large number of users who are unable to work out solutions for
themselves.

What we need and want are the users with ability, who can solve problems
for themselves, and who appreciate the challenge of doing so - and who also
understand both the benefits of doing things the NetBSD way (ultimate
portability) and the drawbacks of being a relatively small project (but also
the opportunities that provides).

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".

And then 10 minutes later dholland-tech%netbsd.org@localhost also said:

  | That's a nice idea, in a way, but:
  | (1) startx is in there, so if you don't already have it in the path you will
  | find starting X a nuisance if you have logged in on the console (which I
  | think is not uncommon); 

Yes, that one is an issue.  But the solution is not to simply stick
/usr/X11R7/bin in the non-X PATH, but to provide a script in base which
will start X for the user - setting up the environment (including PATH,
using the user's preferences where possible, or sane defaults otherwise)
checking that the system has X installed (and if so, where) and that the
user is not currently already running X, and is logged in in an environment
where simply starting X makes sense (eg: on the console, rather than via
ssh or similar).

nb: I don't mean moving (or replacing) startx - this imaginary script (not
really so imaginary, I have one like it, and I would assume others do as
well) would simply run startx once it has verified it should do so, and
has setup the appropriate environment.

  | (2) it's not common but far from unheard-of to log in somewhere without a
  | DISPLAY and then start X programs [...]
  | Granted, if you know enough about what you're doing to do this,
  | having /usr/X11R7/bin not in the PATH is only an annoyance,
  | but it's highly irritating.

Any user doing that often enough to get irritated by it, should really
be irritated at themself, as they're obviously capable of adding /usr/X11R7/bin
to their PATH for themselves (even when not running X) if that suits
their needs, yet apparently didn't.   Whose fault is that do you think?
This discussion is really about what should be done for those new users
who don't know any of this, not those who do.

  | (3) it is entirely moot if you installed X from pkgsrc,

Not entirely - if your X binaries are in /usr/pkg/bin what would be
the point of including /usr/X11R7/bin in PATH?   All that would ever
accomplish in that circumstance would be to have the shell attempting
to stat("/usr/X11R7/bin/whatever")  and getting ENOENT errors.

  | in which case all the X bins are on the path (or not) regardless.

I've never really thought that was a great idea - but since the
directory (/usr/pkg/bin) is presumably in PATH already, having them
there is relatively harmless - most such programs give rather cryptic
error messages when run when X is not running, which don't always make
it obvious what the problem is, but that's the only real drawback.

  | (4) it's far from the case that the only things that require an X display
  | live in /usr/X11R7/bin. 

Not that far, but sure, there are some, and if you want to run those
few (lndir cleanlinks ...) then you probably know enough about the
system to adjust PATH for yourself.   Nothing in this category is the
kind of thing that a new user reading a beginners "try this" howto is
going to expect to work.   Some of it is really only ever used while
building X.    [Aside: WTF is fillblnk supposed to be, and why are we
installing that - it has no man page.]

In all of this we need to resist the temptation to argue for what works
best for ourselves - we're all supposed to be capable of configuring the
system to suit our own needs.    Most of the people here would really not
like it if there was a suggestion to push the config towards the way that I
run my systems, which have all kinds of differences from what is "normal".

kre