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

[David Holland <dholland-bugs%netbsd.org@localhost>]

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

From: David Holland <dholland-bugs%netbsd.org@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: Sat, 27 Aug 2022 22:11:40 +0000

 On Mon, Aug 22, 2022 at 12:50:02PM +0000, Robert Elz wrote:
  >    |  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.
 
 Indeed. That's probably why, yes, and I'm sure there are extant .cshrc
 files whose ancestry is that old, too.
 
  >  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 - 
 
 It seems like a convenient thing to support, given that sh doesn't
 have any equivalent of .cshrc that's adequate for the purpose of
 setting things up. And it seems like there's no downside and no
 particular reason it should be illegal, other than being semantically
 untidy from some points of view. It's not like there's a path that
 will invoke it when not desired and thereby create unexpected behavior.
 
 -- 
 David A. Holland
 dholland%netbsd.org@localhost