Re: interactive shell detection in shrc

[Steffen Nurpmeso <steffen%sdaoden.eu@localhost>]

RVP wrote in
 <c662293e-f56e-d619-30b1-3937ee361c7d%SDF.ORG@localhost>:
 |On Mon, 30 Sep 2024, tlaronde%kergis.com@localhost wrote:
 |> But, if I'm not mistaken, the discussion was about testing if a shell
 |> is interactive, that is, "inheriting" whatever has been set and
 |> testing it. Since SHELL is not set by all login programs (your
 |> example of xterm) and since the variable, if redefined or undefined,
 |> is not set automatically by all shells, it can not be used neitherto
 |> identify the shell and nor to use reliably to verify that it is
 |> an interactive session.
 |>
 |
 |If you're talking about checking for "interactivity" in arbitrary shells
 |running under arbitrary programs, then I have no clue, Thierry :).
 |
 |But, for POSIX (Bourne) shells, they should set `i' in `$-'.  Not sure why
 |one would additionally want to examine $SHELL here. (I've not read all the
 |emails in this thread, so may have missed that part.)

i have also no clue, but for shell detection i look at $0 and
*ksh*, *bash*, *yash*, esac, and later also $NETBSD_SHELL if
nothing triggered.  Unfortunately *that* is almost undoable
i think, and things like

  (set +o emacs-usemeta) >/dev/null 2>&1 && set +o emacs-usemeta

are unavoidable.
Having said that, i then settled on mksh, later back to bash, and
the others only show up occasionally, and for that it works good
enough.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)