On Fri, Oct 4, 2024 at 1:43 PM Greg A. Woods <wo...@planix.ca> wrote:
> At Mon, 30 Sep 2024 22:52:18 +0200, tlaro...@kergis.com 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/
