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: Sun, 21 Aug 2022 23:07:33 +0300

 On Thu, Aug 18, 2022 at 04:13:50 +0300, Valery Ushakov wrote:
 
 > 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.
 [...]
 > 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.
 
 So I did a bit more poking around about the "loginness" of Xsession,
 and it's all a mess :)
 
 Even the xdm(1) man page itself has an csh example that exhibit that
 confusion, b/c it emphasizes that the the #!csh line doesn't have `-f`
 flag ("fast", i.e. skip reading .cshrc) "so .cshrc gets run to set
 $PATH", i.e. it supposes that PATH is set in in .cshrc, while normally
 you'd want to do that once in .login
 
 Also consider this question from 1994:
 
   http://www.verycomputer.com/179_42a1457859bf1456_1.htm
 
 | SHORT DESCRIPTION:
 |
 | XDM starts up DEC's session manager (dxsession) in its Xsession
 | script. The default XDM setup in OSF/1 does not start dxsession as a
 | login shell and, therefore, login scripts such at .login, .profile,
 | and /etc/profile are not executed.
 
 and the eventual kludge he ended up with was to inerpose a program
 that inserts login shell before the session:
 
 | execl(pwd->pw_shell, "-", "-c", DXSESSION, 0); 
 
 which I also thought of, but one problem there is that it doesn't work
 with csh.  csh's test for "am I a login shell" is argv[0] starts with
 '-' and there are no arguments or, otherwise, there's single `-l`
 argument.  I.e. you cannot run -csh -c command that executes a command
 as a login shell, after reading csh login files.  (ksh, bash and zsh
 don't have that limitation and grok -l -c; tmux accepts -l, dunno if
 it passes it along with -c emulation).
 
 The answer to the above question from a DEC guy was (quoting it here
 in case that site goes away):
 
 | The .xsession script is the X analog of the .login file.  I quote
 | from the X Window System Administrator's Guide (published by
 | O'Reilly and Assoc. and included in the DEC OSF/1 doc set) -- "you
 | might want to start thinking of the .login file as the startup file
 | for ASCII-based user serssions only."  (Read more about this in
 | section 2.3.3.3 page 33.)
 |
 | I suggest that you not modify the /usr/lib/X11/xdm/Xsession script
 | in this way but rather suggest that each user create a ~/.xsession
 | script to configure his X environment.  A typical .xsession script
 | might define various environment variables and then run dxsession.
 | One trick I use is to define a script of environment variable
 | definitions which is sourced from both my .login and my .xsession.
 
 Which forces everyone to either have an .xsession file or make their
 .cshrc, or .bashrc, or whatever check if the environment was
 customized and source their login script if not.
 
 So we may instead go the other way and make Xsession read /etc/profile
 too to simulate login behaviour of shell at least for sh users (the
 default).  People that use some other shell probably either already
 have .xsession or run terminals with login shells or worked around
 this ancient xdm problem in some other way.
 
 All that shouldn't change the fact that we should fix sh to enable
 line editing by default.
 
 Probably make sh grow -l option too, like ksh, bash, zsh and (albeit
 limited) csh.
 
 -uwe