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

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

    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