Re: xsrc/54851 (.profile is not read by sh when using xdm or other login managers)

[Valery Ushakov <uwe%stderr.spb.ru@localhost>]

The following reply was made to PR xsrc/54851; it has been noted by GNATS.

From: Valery Ushakov <uwe%stderr.spb.ru@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: xsrc/54851 (.profile is not read by sh when using xdm or other
 login managers)
Date: Thu, 18 Aug 2022 04:13:50 +0300

 On Wed, Aug 17, 2022 at 22:05:01 +0000, nia wrote:
 
 >  I'm not sure what you mean by random user - it sources the ~/.profile
 >  from the user who has just logged in. Nothing is read before login.
 
 Sorry, it ended up ambiguous.  I meant "random (user's script)" not
 "(random user)'s script".
 
 The suggested solution to this problem cannot rely on every user to
 have an up-to-date ~/.profile that sets these things up - even when
 their shell is not sh(1).
 
 Also note that login sh(1) reads /etc/profile automatically and then
 reads ~/.profile (which doesn't have to source /etc/profile) so any
 system-wide customization made by an administrator to /etc/profile
 will not be picked up by your change.
 
 
 >  Reducing the problem down to just the PATH seems to be Missing The
 >  Point slightly. It's also about locales, editing modes, etc.
 
 The editing mode is not relevant here.
 
 I don't know what is the official way for users to set up their locale
 in a way that it's picked up by any which way a user may "log in" to
 the system.  But system-wide default PATH is system-wide, and locale
 is per-user, so you cannot lump these two problems together.
 
 Actually, the very fact that you bring them up in the same context is
 a sign that you might be missing the point here.  Host-wide PATH,
 user-specific locale and sh(1)'s interactive experience are three
 quite separate issues and have to be considered separately.  Even the
 last two don't belong together, b/c locale is something you want to
 set up in your .profile or .login once for all child processes to
 inherit and things like functions/aliases, editing preferences, etc
 need to be set up in the sh's $ENV file, or .bashrc, or .cshrc for
 each interactive shell to pick up.
 
 
 >  Without ~/.profile read on startup, the default shell is pretty
 >  unusable regardless of PATH settings.
 
 Do you mean by "unusable" the fact that line editiing is not on by
 default?  Again, this is not relevant.  A process chain of, say xdm ->
 user's X session -> window manager menu -> emacs - is supposed to
 start emacs with the right PATH in its environment.  Whether sh(1) is
 "usable" (in your opinion) as an interactive shell is not pertinent
 even if your interactive shell happens to be sh(1) - which might not
 be the case.
 
 
 -uwe