Re: $PPID not updated when the PPID changes (parent killed)

[Peter Stephenson <p.w.stephenson@ntlworld.com>]

On 18 May 2021 at 16:18 Mikael Magnusson <mikachu@gmail.com> wrote:
> On 5/18/21, Bart Schaefer <schaefer@brasslantern.com> wrote:
> > Aside, it's a bit odd that SHLVL isn't read-only.  Even assorted Bash
> > tutorials found by online search treat it as immutable (statements
> > like "$dog is only available at SHLVL 2") despite that it can be
> > arbitrarily messed with.
> 
> I sometimes set it (in practice only to the empty string), such that
> the first shell in a new terminal always ends up with SHLVL=1 (my
> prompt hilights when it is non-1 so that i know i can safely exit
> without having the terminal be closed, eg while testing new zsh builds
> or other things where i want a temporary shell state). I also do some
> window manager development so things like "SHLVL= openbox --replace"
> tend to happen as well.

I do similar stuff to the extent of resetting SHLVL to zero, but I think
there is actually a logical argument for being able to adjust it, i.e.
set it rather than reset it, if you happen to know that's going to have a
useful effect.

For example, if SHLVL=1 before a terminal emulator starts because there's
a shell that spawned the window initialisation (this used to be a lot
more common way back when), then it's 2 in your terminal.  It would
be quite natural to start a new terminal (actually forked from the
current one, but logically at the same level as far as the user is
concerned) prefixed with:

SHLVL=$(( SHLVL - 1 ))

Then your init files in the new terminal behave as they do in the
one you're in.

I'm certainly not saying this is the absolute one true way of doing
things, only that I don't think it should be excluded.  It's fairly
low level; I think it's a case of giving enough rope etc.  I don't
think we have any expectation of or guidance on what people do with this
anyway.

pws