Re: sh(1) and ksh(1) default PATH
On Thu, 18 Aug 2022, Hauke Fath wrote: On Wed, 17 Aug 2022 21:56:02 +, David Holland wrote: 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; [...] Except that the whole reason for installing e.g. bind or sendmail from pkgsrc is to replace the corresponding functionality in base. Bad example -- neither will (have to) be in PATH. And sendmail is even special-cased by mailer.conf. Sorry for jumping in so late, but the original change seems bad in the sense that I expect root to use a shell that's limited and doesn't initially include all the extra paths and only use system-provided paths. For me that was sh. I suppose I can override the defaults for root but can't you just give a regular user a different shell? -- Hisashi T Fujinaka - ht...@twofifty.com BSEE + BSChem + BAEnglish + MSCS + $2.50 = coffee
Re: PATH order (was: sh(1) and ksh(1) default PATH)
Le Thu, Aug 18, 2022 at 01:56:11PM +0200, Edgar Fuß a écrit : > If you need the base version of a utility, why not call it by full path? > > OTOH, if people need a newer version of foo, I install foo from pkgsrc and > want that to take precedence over the base version. If someone wants that (this is making the assumption that this someone knows that some package is installing a different version of a base utility; and I very doubt this for some monsters with myriad of dependencies), this someone can reorder the directories in _his_ PATH or for some or all of unprivileged users he manages. PATH is a simple way of managing namespaces (Plan9 has gone far in this area of namespaces). If the user _wants_, he _knows_. And if he wants this for some special purpose, then, this special version has to be prefixed. There is no need to fully qualify a core utility, because this is NetBSD, and by default, one does not need to fully qualify the ones who belong to the "family": one always use the first name. Others are opt and aliens and have to be fully qualified, last name included. If a user reports a problem with 'sh' this is /bin/sh, and the version NetBSD provided. If this is something else he has added, he has to tell where this comes from and he is probably not addressing the bug report to the right audience. I simply don't get the logic behind all this... (But nowadays, I don't get the logic of what's going on anywhere. I'm perhaps simply too old...) Don't worry, this is the last message on my part on the subject. -- Thierry Laronde http://www.kergis.com/ http://kertex.kergis.com/ http://www.sbfa.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
PATH order (was: sh(1) and ksh(1) default PATH)
If you need the base version of a utility, why not call it by full path? OTOH, if people need a newer version of foo, I install foo from pkgsrc and want that to take precedence over the base version. If I write a wrapper around bar, I put it in /usr/local/bin.
Re: sh(1) and ksh(1) default PATH
Le Wed, Aug 17, 2022 at 09:56:02PM +, David Holland a écrit :
> 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.
But this is already taken care of at /etc/ level (I still use
sendmail(8)) and the way it is now, one knows what the system uses as
the MTA/MDA for example.
I have to deal with the myriad of Linuces (because there is no such
thing as "Linux"; it is just a kernel) for kerTeX, and what I do
appreciate by comparison is that NetBSD is a _system_: it is a minimal,
coherent whole yet giving a functionnal base. It has rules (and thus,
there are always exceptions, but few). And this is due to your good
work and the good work of the other NetBSD developers. Not every "OS"
around is a system (coherent).
Relying on pkgsrc to not have a package doing something wrong
(installing a base utility taking the place of a core provided one) by
letting /usr/pkg/{sbin,bin} take precedence other /{sbin,bin} and
/usr/{sbin,bin}, when comparing the size of pkgsrc, the complexity of
numerous packages, the contributed aspect of pkgsrc vs. NetBSD by
itself, seems to me unreasonable.
Make the common case fast: when a user adds functionnalities, software,
this is available because the utilities are placed in hooks (/usr/pkg/,
/usr/local) that are searched by default but finally. Overriding core
functionnalities is a very special case and needs to be a special
and thus more difficult case (it is not an ordeal; but the user has
to know a little and must take the responsability and the small effort
is the sign fo the responsability).
A little more than 2 cents,
--
Thierry Laronde
http://www.kergis.com/
http://kertex.kergis.com/
http://www.sbfa.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: sh(1) and ksh(1) default PATH
On Wed, 17 Aug 2022 21:56:02 +, David Holland wrote: > 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; [...] > > Except that the whole reason for installing e.g. bind or sendmail from > pkgsrc is to replace the corresponding functionality in base. Bad example -- neither will (have to) be in PATH. And sendmail is even special-cased by mailer.conf. Cheerio, Hauke -- Hauke Fath Linnéweg 7 64342 Seeheim-Jugenheim Germany
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: 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: sh(1) and ksh(1) default PATH
Le Tue, Aug 16, 2022 at 02:14:29AM +, David Holland a écrit : > On Mon, Aug 15, 2022 at 08:28:28AM +0200, tlaro...@polynum.com wrote: > > > (If there are no bins with duplicate names, it doesn't matter. If > > > there are, it does. Argument 1: the point of installing something in > > > /usr/local or /usr/pkg that's also in base is to replace the version > > > in base, not for it to be inaccessible to ordinary use. 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 > > > and I suspect it may partly be a leftover response dating from System > > > V installs with world-writable /usr/local.) > > > > Argument 2.1: permissions on /usr/local may be relaxed and malicious > > software could more easily install devious utilities there to precisely > > override safer versions in base. So by default, base version should take > > precedence. > > Except that if you do that you have deliberately misconfigured your > system. I don't think there's any reason the default setup should > cater to this kind of inherently unsafe environment. 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. -- Thierry Laronde http://www.kergis.com/ http://kertex.kergis.com/ http://www.sbfa.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: sh(1) and ksh(1) default PATH
On Mon, Aug 15, 2022 at 08:28:28AM +0200, tlaro...@polynum.com wrote: > > (If there are no bins with duplicate names, it doesn't matter. If > > there are, it does. Argument 1: the point of installing something in > > /usr/local or /usr/pkg that's also in base is to replace the version > > in base, not for it to be inaccessible to ordinary use. 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 > > and I suspect it may partly be a leftover response dating from System > > V installs with world-writable /usr/local.) > > Argument 2.1: permissions on /usr/local may be relaxed and malicious > software could more easily install devious utilities there to precisely > override safer versions in base. So by default, base version should take > precedence. Except that if you do that you have deliberately misconfigured your system. I don't think there's any reason the default setup should cater to this kind of inherently unsafe environment. -- David A. Holland dholl...@netbsd.org
Re: sh(1) and ksh(1) default PATH
On Mon, 15 Aug 2022, Hauke Fath wrote: On Sun, 14 Aug 2022 09:04:21 + (UTC), RVP wrote: Linux has a pam_env.so which reads /etc/environment and /etc/environment.d/* for this kind of thing. I was looking for something like that on NetBSD a while back... login.conf(5) can set PATH. Yeah, I looked into that for someone a while ago, and that doesn't work in all cases. For example: 1. xdm The `setenv' capability doesn't work in xdm (the code just won't work as it stands); and in any case, xdm prefers a different method for setting PATH and env. (the `DisplayManager.*' resource settings). 2. su The default PAM variant does honour `setenv', but, the non-PAM one doesn't look like it does (it only does PATH). 3. sudo/doas/... 3rd-party programs don't seem to grok `setenv' OTOH, all of these, if they use PAM, do seem to call pam_getenvlist() and use properly the returned variables. -RVP
Re: sh(1) and ksh(1) default PATH
Robert Elz wrote in
<8853.1660590...@jacaranda.noi.kre.to>:
|Date:Mon, 15 Aug 2022 10:45:59 -0400
|From:Jan Schaumann
|Message-ID: <20220815144559.go11...@netmeister.org>
|
|| I think it's short-sighted and unfair to equate lack
|| of experience with idiocy.
|
|Then why did you jump to that conclusion? That is neither
|what I said, nor what I meant.
|
|There is no problem with inexperienced users, who are capable
|enough to know they are inexperienced (which of itself says
|very little) and who are willing to learn, and to recognise
|that learning means work.
|
|The best way for such users to become experienced, is by doing
|things, and that should start with the small things, of course,
|for which solutions can fairly easily be discovered.
|
|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.
And the golden path is enabling.
Yeah, do not make turtle soup, let the turtles do smalltalk.
I just did
--- a/home/.shrc
+++ b/home/.shrc
@@ -99,6 +99,7 @@ eval "___isinc=\$___SHRC$$"
shopt -s expand_aliases
elif [ "${OSTYPE}" = netbsd ]; then
set -o cdprint -o emacs -o tabcomplete
+ (set -o promptcmds) >/dev/null 2>&1 && set -o promptcmds
fi
export HISTSIZE HISTFILE
last saturday after creating my NetBSD 9.3 VM, because i was given
a hand. (Iirc: again, and again, and again...-)
P.S.: i want to add i was sitting and saying your first two
sentences this afternoon (in German).
Thanks, and Ciao from Germany. (That unfortunately sends lots of
military planes to your home country.)
--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
Re: sh(1) and ksh(1) default PATH
Date:Mon, 15 Aug 2022 10:45:59 -0400 From:Jan Schaumann Message-ID: <20220815144559.go11...@netmeister.org> | I think it's short-sighted and unfair to equate lack | of experience with idiocy. Then why did you jump to that conclusion? That is neither what I said, nor what I meant. There is no problem with inexperienced users, who are capable enough to know they are inexperienced (which of itself says very little) and who are willing to learn, and to recognise that learning means work. The best way for such users to become experienced, is by doing things, and that should start with the small things, of course, for which solutions can fairly easily be discovered. 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. After this the user is a bit more experienced than they were, they feel they have accomplished something (and they have) and while looking for the answers to the immediate question, probably also came across other information they weren't aware of - they won't necessarily understand all of that, because of not having an immediate need, or reason to test it - but they will remember that they saw something about whatever when they do need that information. In this "man page" can be replaced by web searches, or various other mechanisms (including NetBSD intro documentation - some areas of which we probably need more of, but lack people willing to write it), | > In all of this we need to resist the temptation to argue for what works | > best for ourselves | | ...yet that appears to your basis of argument. Not at all - I could easily contribute my environmemt, in which lots of things "just work", but a user experiencing that would never have the motivation to find out how any of it works, or what can be altered to suit their own tastes. There's a proverb something about giving a fish vs teaching fishing that is probably relevant here. kre
Re: sh(1) and ksh(1) default PATH
Robert Elz wrote: > 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. I think it's short-sighted and unfair to equate lack of experience with idiocy. It's fine for the project to say that it doesn't cater to inexperienced users, but the language above is condescending and alienates at least some experienced users as well. However, even if the NetBSD project does explicitly _not_ want inexperienced users, how does it expect to gain experienced users? The overwhelming majority of users who learned and gained experience one one of the other systems will see no reason to switch. > In all of this we need to resist the temptation to argue for what works > best for ourselves ...yet that appears to your basis of argument. Anyway, I don't intend to enter a long discussion on this, but I really do think that it's in the project's interest to strike a better balance and to consider usability by non-experts. -Jan
Re: sh(1) and ksh(1) default PATH
Hauke Fath wrote in <20220815111506408018.2367a...@espresso.rhein-neckar.de>: |On Sun, 14 Aug 2022 09:04:21 + (UTC), RVP wrote: |> Linux has a pam_env.so which reads /etc/environment and |> /etc/environment.d/* for this kind of thing. I was looking |> for something like that on NetBSD a while back... | |login.conf(5) can set PATH. And pam_env does a whole lotta things more, really. We have the very same discussion on #crux-devel, but there it was about the sole decision to create a /etc/profile with all sorts of XDG directories (.. i had written pam_xdg for those (also available on FreeBSD) but the one hates me ..), and the terrible -if [ "$UID" = "0" ]; then - export PATH="/sbin:/usr/sbin:/opt/sbin:/bin:/usr/bin:/opt/bin" -else - export PATH="/bin:/usr/bin:/opt/bin" -fi +export PATH="/sbin:/usr/sbin:/opt/sbin:/bin:/usr/bin:/opt/bin" change that _i_ hate. I also hate pam_env which came up here for the XDG variables (imagine this!), but it does _so much more_ that i personally would really hate to see that thing enabled _on each and every installation by default_. login.conf, yes! Or heck write a very simple PAM module (the NetBSD site contains fully fledged examples even) that only reads _one_ global configuration file at maximum, and sets some environment variables accordingly. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: sh(1) and ksh(1) default PATH
Date:Mon, 15 Aug 2022 12:41:49 +0300 From:Valery Ushakov Message-ID: | As you do the caretaking of our sh(1), please, can you drop a small | note in syspath() as to why it uses sysctl() directly instead of | confstr(). Sorry, no, 2003 changes are a bit before my time. I have no idea, other than what I see in confstr(3) about how it is obsoleted by sysctl().Nor do I know from whence that interface originated, nor why it is so peculiar in its return values (POSIX specifies it that way, but that will be because that is how it worked wherever it came from). kre
Re: sh(1) and ksh(1) default PATH
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.
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-t...@netbsd.org 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
Re: sh(1) and ksh(1) default PATH
On Sun, 14 Aug 2022 09:04:21 + (UTC), RVP wrote: > Linux has a pam_env.so which reads /etc/environment and > /etc/environment.d/* for this kind of thing. I was looking > for something like that on NetBSD a while back... login.conf(5) can set PATH. Cheerio, Hauke -- Hauke Fath Linnéweg 7 64342 Seeheim-Jugenheim Germany
Re: sh(1) and ksh(1) default PATH
On Sun, Aug 14, 2022 at 09:13:23 +0700, Robert Elz wrote: > The normal default path for sh comes from sysctl user.cs_path As you do the caretaking of our sh(1), please, can you drop a small note in syspath() as to why it uses sysctl() directly instead of confstr(). (I'm not sure I can properly summarize the sarcasm of confstr comments and you probably know the lore behind this too anyway :). -uwe
Re: sh(1) and ksh(1) default PATH
On Sun, 14 Aug 2022 21:41:08 +, David Holland 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.
Cheerio,
Hauke
--
Hauke Fath
Linnéweg 7
64342 Seeheim-Jugenheim
Germany
Re: sh(1) and ksh(1) default PATH
Hello, Le Sun, Aug 14, 2022 at 09:41:08PM +, David Holland a écrit : > On Sat, Aug 13, 2022 at 08:59:07PM +, nia wrote: > > A problem many new NetBSD users encounter is that a default shell > > without an initialized home directory containing a ~/.profile > > does not include some system PATH entries that would otherwise be > > provided from /etc/skel/.profile. > > [...] > > 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. > > (If there are no bins with duplicate names, it doesn't matter. If > there are, it does. Argument 1: the point of installing something in > /usr/local or /usr/pkg that's also in base is to replace the version > in base, not for it to be inaccessible to ordinary use. 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 > and I suspect it may partly be a leftover response dating from System > V installs with world-writable /usr/local.) > Argument 2.1: permissions on /usr/local may be relaxed and malicious software could more easily install devious utilities there to precisely override safer versions in base. So by default, base version should take precedence. > But if we're going to paste new copies of the default path into more > places we should really try to straighten this out first, or have a > setting for the order somewhere. > > There's already too many copies as it is, and they aren't all the > same. The one in etc/login.conf is missing /usr/local/sbin, for > example. > > I am not clear on why has both _PATH_DEFPATH and > _PATH_STDPATH and why they're different (one potentially has RESCUEDIR > in it, whatever that is, and the other has sbin dirs; and neither has > /usr/X11R7/bin) but probably that should be clarified and then all the > others derived directly from there rather than repasted. > > (Also, being a system header, paths.h shouldn't be trafficking in > symbols like RESCUEDIR that belong to the application namespace. I am > guessing that RESCUEDIR is sometimes set to /rescue? This should get > sanitized.) Best, -- Thierry Laronde http://www.kergis.com/ http://kertex.kergis.com/ http://www.sbfa.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: sh(1) and ksh(1) default PATH
On Sun, Aug 14, 2022 at 09:13:23AM +0700, Robert Elz wrote: > It is also certainly wrong to add /usr/X11R7/bin to $PATH unless the > user is actually in an X environment, that ought be added in the X11 > startup scripts, not in the shell, or in user.cs_path A profile > file can check if DISPLAY is set, doing that in the shell isn't appropriate. 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); (2) it's not common but far from unheard-of to log in somewhere without a DISPLAY and then start X programs on some otherwise existing display. (Examples of this being useful include (a) starting a new window manager if the original one has cored and left you without window focus; (b) starting xlock remotely when you accidentally went home without locking your session; (c) screendumping or otherwise salvaging what you were doing when PR 44712 strikes and you can't switch back to your display.) 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. (3) it is entirely moot if you installed X from pkgsrc, in which case all the X bins are on the path (or not) regardless. (4) it's far from the case that the only things that require an X display live in /usr/X11R7/bin. So I think it's an unnecessary complication to worry about this issue. -- David A. Holland dholl...@netbsd.org
Re: sh(1) and ksh(1) default PATH
On Sat, Aug 13, 2022 at 08:59:07PM +, nia wrote: > A problem many new NetBSD users encounter is that a default shell > without an initialized home directory containing a ~/.profile > does not include some system PATH entries that would otherwise be > provided from /etc/skel/.profile. > [...] 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. (If there are no bins with duplicate names, it doesn't matter. If there are, it does. Argument 1: the point of installing something in /usr/local or /usr/pkg that's also in base is to replace the version in base, not for it to be inaccessible to ordinary use. 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 and I suspect it may partly be a leftover response dating from System V installs with world-writable /usr/local.) But if we're going to paste new copies of the default path into more places we should really try to straighten this out first, or have a setting for the order somewhere. There's already too many copies as it is, and they aren't all the same. The one in etc/login.conf is missing /usr/local/sbin, for example. I am not clear on why has both _PATH_DEFPATH and _PATH_STDPATH and why they're different (one potentially has RESCUEDIR in it, whatever that is, and the other has sbin dirs; and neither has /usr/X11R7/bin) but probably that should be clarified and then all the others derived directly from there rather than repasted. (Also, being a system header, paths.h shouldn't be trafficking in symbols like RESCUEDIR that belong to the application namespace. I am guessing that RESCUEDIR is sometimes set to /rescue? This should get sanitized.) -- David A. Holland dholl...@netbsd.org
Re: sh(1) and ksh(1) default PATH
On Sun 14 Aug 2022 at 07:36:17 +, nia wrote: > Display managers do not create login shells, and xdm was used. I've ~always found that weird, and ~always changed all my xterms to be login shells. Probably since the 1980's (before NetBSD). xterm.vt100.LoginShell: on -Olaf. -- ___ "Buying carbon credits is a bit like a serial killer paying someone else to \X/ have kids to make his activity cost neutral." -The BOFHfalu.nl@rhialto signature.asc Description: PGP signature
Re: sh(1) and ksh(1) default PATH
Linux has a pam_env.so which reads /etc/environment and /etc/environment.d/* for this kind of thing. I was looking for something like that on NetBSD a while back... -RVP
Re: sh(1) and ksh(1) default PATH
n...@netbsd.org (nia) writes: >There are a few remaining cases where the sh(1) defaults are Bad: It's not "Bad" but just does not fit your personal expectations. >1. We can't assume XDM. Lots of desktop environments have their own > preferred login manager which may have inconsistent behaviour > and not preserve PATH or editing settings. If these login managers are inconsistent, then for a reason and if you want to configure their behaviour than just do that. >2. There are other situations where login shells are not > created, for example, frequently when working with > scripts to manage chroots. And that's fully intentional, in particular _when_ working with chroots. >3. There are plenty of ways to mess up creating user accounts > (don't pass -m to useradd and create the home directory > afterwards) where "why are commands suddenly missing from > my shell" is a thing new users can easily stumble into. I am very sure that users will complain about their missing home directory first, especially when the other login manager just bombs out for not being able to write to $HOME/.local.
Re: sh(1) and ksh(1) default PATH
On Sun, Aug 14, 2022 at 09:58:46AM +0200, Martin Husemann wrote: > On Sun, Aug 14, 2022 at 07:36:17AM +, nia wrote: > > Display managers do not create login shells, and xdm was used. > > Adapt the default /etc/X11/xdm/Xsession instead? Maybe make it extract > PATH from /etc/sh.rc ? > > Martin Actually, I already did this in CURRENT a while ago - nobody has complained yet ;) There are a few remaining cases where the sh(1) defaults are Bad: 1. We can't assume XDM. Lots of desktop environments have their own preferred login manager which may have inconsistent behaviour and not preserve PATH or editing settings. 2. There are other situations where login shells are not created, for example, frequently when working with scripts to manage chroots. 3. There are plenty of ways to mess up creating user accounts (don't pass -m to useradd and create the home directory afterwards) where "why are commands suddenly missing from my shell" is a thing new users can easily stumble into.
Re: sh(1) and ksh(1) default PATH
On Sun, Aug 14, 2022 at 07:36:17AM +, nia wrote: > Display managers do not create login shells, and xdm was used. Adapt the default /etc/X11/xdm/Xsession instead? Maybe make it extract PATH from /etc/sh.rc ? Martin
Re: sh(1) and ksh(1) default PATH
On Sun, Aug 14, 2022 at 12:33:39AM +0200, Joerg Sonnenberger wrote: > On Sat, Aug 13, 2022 at 08:59:07PM +, nia wrote: > > A problem many new NetBSD users encounter is that a default shell > > without an initialized home directory containing a ~/.profile > > does not include some system PATH entries that would otherwise be > > provided from /etc/skel/.profile. > > Garbage In, Garbage Out. We should most definitely not hard-code all > those directories in the shell. > > Joerg Which ones in particular do you object to, and why is hard coding all of those directories worse than hard-coding /bin:/sbin:/usr/bin:/usr/sbin? It's extremely confusing to get some commands but not all commands in PATH, and there are already systems consuming NetBSD code that don't follow that old unix directory structure.
Re: sh(1) and ksh(1) default PATH
On Sat, Aug 13, 2022 at 10:41:14PM +, Jeremy C. Reed wrote: > On Sat, 13 Aug 2022, nia wrote: > > > A problem many new NetBSD users encounter is that a default shell > > without an initialized home directory containing a ~/.profile > > does not include some system PATH entries that would otherwise be > > provided from /etc/skel/.profile. > > How did the new user, new home not have the dot file? > > (I'd like to fix that versus code change at first.) > > Even without the dot files, also login should set the default path (to > _PATH_DEFPATH which has the /usr/pkg/bin/ the article author needed) and > sshd sets it too (to _PATH_STDPATH which also has it). I wonder why the > default path wasn't seen? > Display managers do not create login shells, and xdm was used.
Re: sh(1) and ksh(1) default PATH
Date:Sat, 13 Aug 2022 20:59:07 + From:nia Message-ID: | This patch synchronizes the defaults for sh(1) and ksh(1) | with /etc/skel/.profile. In addition to what Joerg & Jeremy said, that would be the wrong fix for /bin/sh (I don't know ksh well enough to say, but if it isn't already wrong there, ksh should be altered so it would be). 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). It is hard to believe that you looked at the code and did not see that. The list of directories in the shell is only for when that fails, or when the shell cannot allocate memory, both of which happen never (or not at shell startup, it is of course possible to exhaust memory while the shell is running with a badly written, or simply deliberate, script). It is also certainly wrong to add /usr/X11R7/bin to $PATH unless the user is actually in an X environment, that ought be added in the X11 startup scripts, not in the shell, or in user.cs_path A profile file can check if DISPLAY is set, doing that in the shell isn't appropriate. kre
Re: sh(1) and ksh(1) default PATH
On Sat, 13 Aug 2022, nia wrote: > A problem many new NetBSD users encounter is that a default shell > without an initialized home directory containing a ~/.profile > does not include some system PATH entries that would otherwise be > provided from /etc/skel/.profile. How did the new user, new home not have the dot file? (I'd like to fix that versus code change at first.) Even without the dot files, also login should set the default path (to _PATH_DEFPATH which has the /usr/pkg/bin/ the article author needed) and sshd sets it too (to _PATH_STDPATH which also has it). I wonder why the default path wasn't seen?
Re: sh(1) and ksh(1) default PATH
On Sat, Aug 13, 2022 at 08:59:07PM +, nia wrote: > A problem many new NetBSD users encounter is that a default shell > without an initialized home directory containing a ~/.profile > does not include some system PATH entries that would otherwise be > provided from /etc/skel/.profile. Garbage In, Garbage Out. We should most definitely not hard-code all those directories in the shell. Joerg
sh(1) and ksh(1) default PATH
A problem many new NetBSD users encounter is that a default shell
without an initialized home directory containing a ~/.profile
does not include some system PATH entries that would otherwise be
provided from /etc/skel/.profile.
This came up during the recent El Reg "review" of NetBSD 9.3.
This patch synchronizes the defaults for sh(1) and ksh(1)
with /etc/skel/.profile.
Index: bin/sh/eval.c
===
RCS file: /cvsroot/src/bin/sh/eval.c,v
retrieving revision 1.188
diff -u -p -u -r1.188 eval.c
--- bin/sh/eval.c 5 Jan 2022 15:25:44 - 1.188
+++ bin/sh/eval.c 13 Aug 2022 20:58:10 -
@@ -815,7 +815,7 @@ syspath(void)
{
static char *sys_path = NULL;
static int mib[] = {CTL_USER, USER_CS_PATH};
- static char def_path[] = "PATH=/usr/bin:/bin:/usr/sbin:/sbin";
+ static char def_path[] =
"PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R7/bin:/usr/pkg/bin:/usr/pkg/sbin:/usr/games:/usr/local/bin:/usr/local/sbin";
size_t len;
if (sys_path == NULL) {
Index: bin/ksh/config.h
===
RCS file: /cvsroot/src/bin/ksh/config.h,v
retrieving revision 1.53
diff -u -p -u -r1.53 config.h
--- bin/ksh/config.h30 Jun 2017 04:22:22 - 1.53
+++ bin/ksh/config.h13 Aug 2022 20:58:10 -
@@ -68,9 +68,9 @@
/* Default PATH */
#ifdef RESCUEDIR
-#define DEFAULT_PATH RESCUEDIR ":/bin:/usr/bin:/sbin:/usr/sbin"
+#define DEFAULT_PATH RESCUEDIR
":/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R7/bin:/usr/pkg/bin:/usr/pkg/sbin:/usr/games:/usr/local/bin:/usr/local/sbin"
#else
-#define DEFAULT_PATH "/bin:/usr/bin:/sbin:/usr/sbin"
+#define DEFAULT_PATH
"/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R7/bin:/usr/pkg/bin:/usr/pkg/sbin:/usr/games:/usr/local/bin:/usr/local/sbin"
#endif
/* Include ksh features? */
