Re: [PATCHv2] [bug] $SHLVL decremented for the last command of a subshell

[Mikael Magnusson <mikachu@xxxxxxxxx>]

On Tue, Aug 30, 2016 at 7:00 PM, Peter Stephenson
<p.stephenson@xxxxxxxxxxx> wrote:
> On Tue, 30 Aug 2016 17:46:01 +0100
> Stephane Chazelas <stephane.chazelas@xxxxxxxxx> wrote:
>
>> 2016-08-30 14:04:57 +0100, Peter Stephenson:
>> [...]
>> > This is probably fine.  I've been dithering over cases where for
>> > consistency we might want to decrement SHLVL even in a subshell because
>> > we're exec'ing for some other reason (so would need to do it at the last
>> > minute before exiting if the exec is faked), but I suspect this is too
>> > obscure to be worth special treatment.
>> [...]
>>
>> Note that zsh is currently correctly decrementing in
>>
>> zsh -c '(printenv SHLVL)'
>>
>> Where zsh optimises out the fork(s).
>>
>> ksh93 seems to never decrease $SHLVL even in:
>>
>> $ env SHLVL=1 ksh93 -c 'exec printenv SHLVL'
>> 2
>
> When this was introduced in zsh, there was some controversy over whether
> it was the right thing to do.  I decided it was on the basis that the
> "level" is how deep you are in the process hierarchy, rather than how
> many processes have previously been executed to get where you are,
> seeing as the latter isn't really visible in the current context.
> But I'm not aware of any requirement specification [remember those?]
> saying what the purpose of SHLVL is.

For me personally, I just use it in my prompt to indicate whether
typing "exit" will close the terminal or not, eg if I'm inside a
nested actual shell. When I added that I wasn't even aware of any of
the weird rules regarding subshells affecting it. It's not immediately
obvious to me when that is useful... Regarding the link in the
original report, there's no guarantee that a "2" means it _is_ a
subshell either, just doing for example "xterm &" will also increment
it in the new session.

-- 
Mikael Magnusson