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: tech-userlevel%netbsd.org@localhost
Subject: Re: xsrc/54851 (.profile is not read by sh when using xdm or other login managers)
Date: Sun, 28 Aug 2022 14:31:38 +0700

     Date:        Sat, 27 Aug 2022 22:15:02 +0000 (UTC)
     From:        David Holland <dholland-bugs%netbsd.org@localhost>
     Message-ID:  <20220827221502.ACB101A923B%mollari.NetBSD.org@localhost>
 
   |   >  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.
 
 It has $ENV - but something has to have set ENV first.
 
 But everyone seems to agree that allowing it (login shells with
 scripts or -c) will be OK, so that's what I will do (I'm a little
 preoccupied at the minute with non computer issues, so it is taking
 longer than I had expected to actually finish this - and with this
 I'll need to revise the man page changes a bit (the code change
 required is trivial).
 
   | 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.
 
 What I have been slightly concerned about is the possibility of
 people starting scripts with
 
 	#!/bin/sh -l
 
 or similar, and people's .profile being run (undoing env settings
 that they may have made for this script to use this time, and perhaps
 running things like stty or tset, and mesg, which .profile files often contain).
 
 But based upon something Mouse said in an off list reply, I will add
 a sh variable, which will be initialised with info that will allow the
 profile script to tell (if it needs to) why it is being run (that is,
 how the shell was invoked) so it can decide what it should do (much
 the same way that in $ENV one can use $- to determine whether the
 shell is interactive or not).   ($- (alone) isn't up to the task
 required here).
 
 If the profile wants, it will be able to unset (or alter) the variable,
 after it has finished testing it, so it can also detect when something (like
 the user most often) explicitly does ". ~/.profile" to process it again.
 Of course, if a user wants, they will be able to set the var to anything
 they like (unless the profile makes it read only, which it could do, even
 if the var is unset).  This will just be an ordinary shell variable,
 just one init'd by the shell at startup, but unlike most similar sh vars
 init'd after the environment is read, not before, so when the profile
 files start executing (as part of sh startup), it will be guaranteed the
 var correctly indicates what kind of sh invocation this is.
 
 No specifics on this yet, as in var name, or contents, as it isn't
 implemented, but this will appear at the same time as -l appears.
 Anyone who wants to make suggestions, then by all means, go ahead.
 
 kre