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: Tue, 16 Aug 2022 15:02:40 +0300

 On Mon, May 02, 2022 at 15:14:12 +0000, nia%NetBSD.org@localhost wrote:
 
 > State-Changed-Why:
 > I fixed this in my commit to
 > external/mit/xdm/dist/config/Xsession.in
 > on 25 December 2021
 
 That fix (sourcing ~/.profile from Xsession) seems pretty suspicious
 to me, if not outright wrong.  I haven't used xdm in a small eternity,
 but xdm provides the resources to customize this and we set the
 defaults for them in src/external/mit/xorg/bin/xdm/Makefile The PATH
 is set in userEnv in xsrc/external/mit/xdm/dist/greeter/verify.c
 
 So the real problem is that we have xdm defaults that miss the
 directories that the system default path (sysctl user.cs_path /
 getconf PATH) actually does have.
 
 xdm comes from the era when NFS-shared home in a heterogenous
 environment were quite common, so the same ~/.profile would be
 interpreted on SunOS, Ultrix, SVR3 and what not.  And these systems
 had their own path quirks: X's own bin location (X11R[45], I don't
 remember if I had anything with R3; cf. X11R[67] we had in NetBSD),
 /usr/ucb, /usr/xpg4, /usr/gnu was quite common, etc.  That machine's
 xdm would take care to set up system's idea of the default path for
 you that included those systems-specific things.
 
 So the machinery for this is all in place and working around our own
 wrong xdm defaults by sourcing a random user's script that in the big
 scheme of things should not hardcode system-specific PATH pecularities
 - is not the right thing to do.
 
 -uwe