Re: interactive shell detection in shrc

Steffen Nurpmeso <[email protected]>
Newsgroups gmane.os.netbsd.devel.userlevel
Message-ID <20240930224316.uca8HTT0@steffen%sdaoden.eu>
RVP wrote in
 <[email protected]>:
 |On Mon, 30 Sep 2024, [email protected] 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)
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.