Re: sh(1) and ksh(1) default PATH
On Tue, Aug 16, 2022 at 08:59:13AM +0200, tlaro...@polynum.com wrote: > But the argument "if something is modified, that"s the problem of the > user" can be reversed: NetBSD provides utilities whose > functionnalities it relies upon. So, by default, the system should use > its utilities, the ones it has been tested with and expects. So base > should always come first by default; user can modify this but in this > case, he is on is own. The system is provided without anything in > /usr/local/ so placing something in /usr/local is modifying the > system. So for the core to still function, it has to be designed to > ignore whatever is in /usr/local for its core functionnalities. Except that the whole reason for installing e.g. bind or sendmail from pkgsrc is to replace the corresponding functionality in base. -- David A. Holland dholl...@netbsd.org
Re: sh(1) and ksh(1) default PATH
On Tue, Aug 16, 2022 at 02:03:49AM +0700, Robert Elz wrote: > So, for example if the shell were to not start with line editing > enabled (to borrow from one of the recent issues) a moron user > with complain about how useless it is, and moan a lot, and that's > about it. A user who is merely inexperienced will wonder why > that is, and perhaps decide to have a look in the documentation for > the shell, which will tell them that "set -E" (or set -o emacs) or > set -V (or set -o vi) will enable it. Then they'd try that, and > discover that it does work. Next would be how to make that happen > automatically, so back to the man page to learn about the startup > scripts that the shell runs. An inexperienced user has no basis upon which to make any such conjectures. There's no rational reason to suppose line editing exists but is disabled by default for some unfathomable reason; the logical conclusion is that if it doesn't work, it's not supported. And then they tell a thousand of their facebook friends that NetBSD sucks. That is only a reasonable line of thinking for a user who already knows enough about Unix and NetBSD to realize that (a) this feature is thirty-odd years old and they entitled to expect it; (b) NetBSD is not thirty years "behind"; and (c) in 2022 NetBSD still ships with some assembly required and it's expected to have to tinker with the config to get acceptable results. > There's a proverb something about giving a fish vs teaching fishing that > is probably relevant here. Are you really suggesting that the default config should be broken to force people to learn how to change it? -- David A. Holland dholl...@netbsd.org
Re: sh(1) and ksh(1) default PATH
On Mon, Aug 15, 2022 at 04:36:13PM +0700, Robert Elz wrote:
> Date:Sun, 14 Aug 2022 21:41:08 +
> From:David Holland
> Message-ID:
>
> | 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-t...@netbsd.org 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
dholl...@netbsd.org
Re: sh(1) and ksh(1) default PATH
On Mon, Aug 15, 2022 at 10:50:39AM +0200, Hauke Fath wrote:
> > Argument 2:
> > the stuff in base is canonical and it's wrong for random whatnot to
> > arbitrarily override it. I admit I don't fully understand argument 2 [...]
>
> To give an arbitrary example: I had ${PREFIX}/{s,}bin first in PATH at
> one point. A Kerberos pkgsrc package installed a su(1), which for
> whatever reason didn't work (I don't use Kerberos).
>
> Until pkgsrc prefixes any tools that duplicate base tools, or we grow a
> viable alternatives system, that will remain a problem. And I am not
> sure the above cures are any better than the problem.
pkgsrc should not install stuff that duplicates/replaces/overrides
base tools unless you asked it to. That part I fully agree on.
(That particular bug got fixed in heimdal at least fifteen years ago.)
--
David A. Holland
dholl...@netbsd.org
Re: Relative interpreter pathname on #! line
On Wed, Aug 17, 2022 at 08:29:48AM -0400, Mouse wrote: > > Is [#! taking a relative interpreter path] intentional? > > > What's more, the relative interpreter filename is taken relative to > > the current directory, not relative to the script directory. > > That's exactly what I'd expect, and what I'd say should happen: it's > consistent with ~every other use of relative pathnames. > > > There's probably some logic to this but it seems bug-prone and I > > can't think of a legitimate use for it. > > I can't offhand either, but I also don't see any real risk from it, and > am very far from certain there is no clever use for it. There is a slight risk if you have untrustworthy users and you run one of these things (perhaps by accident) while in /tmp. However, it would be substantially more useful if relative paths were interpreted relative to the location of the script file. I would have to look in the exec code to be sure, but I don't think that would be hard to arrange. -- David A. Holland dholl...@netbsd.org
Re: sh(1) and ksh(1) default PATH
On Sun, 14 Aug 2022 at 03:13, Robert Elz wrote: > > The normal default path for sh comes from sysctl user.cs_path > and if there was a desire to alter that, that would be the place to > do it (as in, by setting that in /etc/sysctl.conf). This seems like a critical fulcrum we already have. If so, could we move towards either having system dotfiles with some form of: PATH="$(/sbin/sysctl -n user.cs_path)" or just comment out PATH settings and have sh, ksh, and csh default PATH to user.cs_path when unset? In the latter case that would mean the following would have printed the same PATH outputs # sysctl -n user.cs_path ; env -i sh -c 'echo $PATH' /usr/bin:/bin:/usr/sbin:/sbin:/usr/pkg/bin:/usr/pkg/sbin:/usr/local/bin:/usr/local/sbin /usr/bin:/bin:/usr/pkg/bin:/usr/local/bin I note that sys_info already sets PATH to user.cs_path https://nxr.netbsd.org/xref/src/usr.bin/sys_info/sys_info.sh#31 At first glance (which means I've missed something :), this seems like a very attractive option - it would mean one central place can define the default PATH for multiple shells Thanks David
Re: Relative interpreter pathname on #! line
> Is [#! taking a relative interpreter path] intentional? > What's more, the relative interpreter filename is taken relative to > the current directory, not relative to the script directory. That's exactly what I'd expect, and what I'd say should happen: it's consistent with ~every other use of relative pathnames. > There's probably some logic to this but it seems bug-prone and I > can't think of a legitimate use for it. I can't offhand either, but I also don't see any real risk from it, and am very far from certain there is no clever use for it. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
