add info: `.SHLVL` not working in Poweshell/pwsh (Windows & Linux)

[GsakuL]

Code of Conduct

• [X] I agree to follow this project's Code of Conduct

What would you like to see changed/added?

i use .SHLVL to hint at nested shells (sometimes needed, especially under Windows when developing PowerShell Modules (.psm1) to verify Import-Module.

$ENV:SHLVL (powershell syntax for env vars) is null/not set:

Under Linux (NixOS 24.11) $ENV:SHLVL is always 1, because zsh is my default shell. Then starting pwsh keeps the env vars

There is currently an open issue about this. However this would not affect Windows PowerShell (ie the old pre-installed Version in Windows) https://github.com/PowerShell/PowerShell/issues/9613

there are workarounds involving $Pofile like this (see pwsh issue):

$ENV:__ShellDepth = [int] $ENV:__ShellDepth + 1

# or

$env:SHLVL = [int]$env:SHLVL + 1

($null + 1 would be 1, so this is fine)

---

since i have been using this hack in my pre-omp powershell promt, I think it would be "nice to know" for some less powershell-experienced users.

Perhaps a hint for .SHLVL on e.g. https://ohmyposh.dev/docs/configuration/templates#global-properties that points to this issue or an extra Sub-Entry/Page on PowerShell/Windows explaining this situation.

But to note: setting $ENV:SHLVL = 2 would not make it available via .SHLVL under Windows:

Using the hack above and some .ENV. templating should be easy enough from there on out.

my theme (without powershell-workaround): https://github.com/GsakuL/mynix/blob/main/modules/home/programs/shells/ohmyposh/config.toml

Personally, I've been using $ENV:__ShellDepth for several years (pre-omp) and didn't have any mayor problems. Using $ENV:SHLVL may also be just fine, however I cannot confirm that. But depending on the outcome of the PowerShell-Issue, this env var might be set automatically, and overwriting it may cause "unexpected side effects" like counting mismatch or whatever, depending on what they will consider "one level". Also, if I'm reading things correctly (sorry, not really familiar with golang) .SHLVL is just a shortcut for .Env.SHLVL (but not for windows (currently)), so multi-shell templates could just use the .Env version with $env:SHLVL under pwsh as "the simplest solution for now"

---

Edit: .Env. returns strings, since it's accessed directly. one should use one of sprigs casting functions, like atoi/int/int64

[JanDeDobbeleer]

@GsakuL I will only add that this is not supported on pwsh, as all hacks forget that you can't assume it starts at 1 or 0. You either always subshell, or don't, but choosing one also breaks the other scenario.

[GsakuL]

fair point. since I know issues in Microsoft repos may take a long time (this one was opened in 2019), and it's currently unknown if this will be implemented at all; and since I have no further input than what I wrote above: feel free to close this, and someone could open a new issue if pwsh ever gets this on-par with unix shells. Adding some explicit hint to the docs would be nice, but I guess users should find this issue now with correct keywords.

[JanDeDobbeleer]

@GsakuL I have it added, just need to PR still.