Re: interactive shell detection in shrc

On Fri, Oct 4, 2024 at 1:43 PM Greg A. Woods <[email protected]> wrote:

> At Mon, 30 Sep 2024 22:52:18 +0200, [email protected] wrote:
> Subject: Re: interactive shell detection in shrc
> >
> > 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.
>
> This thread started to discuss detecting an interactive shell in the
> likes of ~/.shrc, i.e. in the script file referenced by the expansion of
> $ENV, specifically for NetBSD sh(1).
>
> This is of particular importance for NetBSD's sh(1) (and also NetBSD
> ksh(1)) because it(they) always source the expansion of $ENV even for
> non-interactive shells.
>

okay. I'm glad you're getting in the weeds because I depend on the
OS to present the right thing.

to simplify my world, I set all site env in skel/.profile before adding
users.
which includes purging everything from sh-like rc files
except ". $HOME/.profile" and a comment explaining
to use that file for user configs, to prevent rc sprawl.
I am also careful about exporting functions and variables.
this keeps $SHELL conditionals together in one file, too.

As for interactive shortcuts, I have several carefully chosen ones,
the ones here are very handy, I use them all the time....

  alias    g='grep'    # grep the regex
  alias    v='grep -v' # grep -v the regex
  alias    h='fc -l'   # list commands previously entered in shell.
  alias    j='jobs -l' # list background jobs
  alias    s='less -R' # less
  b() { cd "$OLDPWD" ;} # previous directory
  f() { local n="${1##*/}" ; shift || true
      ( set -x ; find -E . -iname "*${n}*" ${@} ) ;}

that last one will return all the yml files below the current directory with
f yml
or files with mod times today with
f . -type f -mtime -1
more complicated variations are in my env, the set -x enables
easy adjustment of longer find invocations, with copy/paste.


> Also because of a long-standing "oversight" in NetBSD sh(1) some shells
> we might ignore the stderr part of the test and just consider stdin (as
> that's really all that matters for "interactivity", right?).
>

Thanks for pointing that out.
I didn't say that, but I did notice it earlier today,
and it is an important security concern. eg a multiphase
attack could start with redirecting stderr to /dev/null
and users would assume no error in their shell,
when there was.

I've already switched to
test -t 0 && test -t 2 || return 0
but in bash I use
export PS1="\${?%0} \u@\h:\w "
which is very handy to always know err state.

-George

-- 
George Georgalis, (415) 894-2710, http://www.galis.org/