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

[Robert Elz <kre%munnari.OZ.AU@localhost>]

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

From: Robert Elz <kre%munnari.OZ.AU@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: Mon, 22 Aug 2022 19:48:50 +0700

     Date:        Sun, 21 Aug 2022 23:05:02 +0000 (UTC)
     From:        David Holland <dholland-bugs%netbsd.org@localhost>
     Message-ID:  <20220821230502.AEDD61A923A%mollari.NetBSD.org@localhost>
 
   |  As I posted or said somewhere a couple days ago (can't remember which
   |  of the many related threads or discussions) it is/was standard
   |  practice with csh to set the path in .cshrc. You'll notice that our
   |  skeleton .cshrc file does exactly that.
 
 Do remember that csh originated in 6th edition unix (it was on the
 (original) 2BSD tape from CSRG).   The environment, as a concept
 didn't exist until version 7.
 
 There was no other way to have every csh get a desired path setting,
 other than doing it in .cshrc.
 
 Once it starts out that way, it is hard to overcome inertia, and get
 people to change.
 
 
   |   >  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).
   |  
   |  This could be construed as a bug, so we could always just fix csh.
 
 Since people seem to want it (and also it would occasionally make
 testing of the shell early startup sequences easier), I have just
 added -l to /bin/sh (not committed yet, not even tested beyond compile
 time yet).
 
 My inclination (and what I have implemented now) is to force +l
 if either -c or a script name is given.   That's even if argv[0]
 starts with a '-' (giving either -l or +l will make that test
 redundant, it is still used to set or clear -l when when neither
 of those is given).   The setting of -l (at shell invocation time)
 is now what is used to control sourcing of the profile files at
 startup time.
 
 This is actually a (minor) change in behaviour - previously a login
 shell (one whose argv[0] starts with '-' - which is the method of
 indicating login shells dating back to the dark ages, options to
 do it are post reformation inventions) would run the profile files
 regardless of what it was going to do after that.
 
 If people feel that we should continue to allow shells running scripts
 or shells invoked with -c to be considered login shells (either with
 the -l or **argv=='-' methods) now would be a good time to say - making
 that change (for either or both of those cases) means deleting one
 (new) line of code for each (ie: the decision doesn't need to be the
 same for both).
 
 My inclination would be to not request a pullup of this change to -9,
 I consider it more than just a bug fix or minor enhancement.
 
   |  It's not like the default session embedded in xdm needs to work with
   |  anyone else's csh.
 
 It probably wants to work for tcsh though.
 
   |   >  All that shouldn't change the fact that we should fix sh to enable
   |   >  line editing by default.
   |  
   |  Right.
 
 I am considering a suitable way to do that, without having the shell
 endorse emacs ("never!") or vi editing modes (I'd probably be lynched)
 and I might have a way to do that.   A subsequent change.
 
 kre
 
 ps: the commit to update the shell to include -l will not reference
 this PR, the original subject had nothing to do with login shells.