RVP wrote in <c662293e-f56e-d619-30b1-3937ee361...@sdf.org>: |On Mon, 30 Sep 2024, tlaro...@kergis.com 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)
