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.
