Re: interactive shell detection in shrc

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

    Date:        Fri, 27 Sep 2024 13:48:17 -0700
    From:        "Greg A. Woods" <woods%planix.ca@localhost>
    Message-ID:  <m1suHsv-0036s2C@more.local>

  | But that was my point!  "m" is not in $- either!

That's very odd, and not 'j' (the old option letter, in some shells,
that is now 'm') either?

(That is, in a shell which supports job control of course, but still
using one that doesn't would be a strange choice to make.)

The m option is supposed to be able to be turned on and off (unlike 'i'
which isn't required to be able to function that way), so really needs
to be in $- so the script can see its current state.

But any current POSIX compat sh should have 'i' in $- if it is interactive.
That is required.

  | However it seems my own test conflates the condition of being a "login
  | shell" with being "interactive".

I saw, but that's not a bad idea, login shells tend to be interactive!

  | So there's nothing in POSIX about login(1) tacking a leading hyphen on
  | and using that to trigger the shell to become a login shell.

In general no, but that's because POSIX has no real concept of "login".
They assume you're starting in a posix environment with a shell ready
to take your commands - how you get to that point is beyond the scope.

But there hasn't been a shell created (since way before 7th edition)
where the **argv == '-' method won't detect a (genuine) login shell.
That's universal.   The "(genuine)" is because some shells (incl ours)
now have other ways to be treated as a login shell (but one invoked
in such a way wouldn't necessarily be interactive, whereas one made
a login shell via the '-' in argv[0] will almost always be.)

  | Indeed from what I can tell POSIX has nothing whatsoever to say about
  | "login shells" nor /etc/profile or $HOME/.profile.

That's mostly right, but I think (at least in Issue 8) there is something
somewhere in some (non-normative) rationale about this.

  | I guess to be entirely POSIX compatible my test should include:
  |
  | 	tty >/dev/null 2>&1 && tty <&1 >/dev/null 2>&1 &&

The second of those would need to be testing (the pre-redirected)
stderr, not stdout, interactive shells don't care where stdout has
been sent (though the user probably does).

But as Steffen (kind of) indicated, "test -t 0 && test -t 2" is
probably an easier way than using tty.

kre