Can't infer shell in shim call in v1.37.0

[sky96111]

fnm env --use-on-cd | Out-String | Invoke-Expression and fnm completions | Out-String | Invoke-Expression shows

❯ fnm env --use-on-cd | Out-String | Invoke-Expression
error: Can't infer shell!
fnm can't infer your shell based on the process tree.
Maybe it is unsupported? we support the following shells:
* bash
* zsh
* fish
* powershell
* cmd
Invoke-Expression: Cannot bind argument to parameter 'Command' because it is an empty string.

environment: fnm version: v1.37.0 OS: Windows 11 x86_64 OS Version: 23H2 22631.3672 Shell: PowerShell 7.4.2

[Schniz]

please re-run fnm env --use-on-cd with the following env var: RUST_LOG=fnm=debug and post the output 🙏

[sky96111]

sure!

~
❯ $env:RUST_LOG="fnm=debug"

~
❯ fnm env --use-on-cd
[2024-05-30T14:18:21Z DEBUG fnm::shell::infer] binary is not a supported shell: "fnm"
[2024-05-30T14:18:21Z DEBUG fnm::shell::infer] binary is not a supported shell: "fnm"
error: Can't infer shell!
fnm can't infer your shell based on the process tree.
Maybe it is unsupported? we support the following shells:
* bash
* zsh
* fish
* powershell
* cmd

Maybe it is a problem caused by shim? I installed fnm by scoop

[sky96111]

Confirm absolute path call without shim works. And v1.36.0 works with shim

[Schniz]

what "shim"?

[Schniz]

I'm not a Windows user, can you please explain the terms you use? 😅

[sky96111]

https://github.com/ScoopInstaller/Shim shim is a small wrapper in scoop installation. it avoids the need to add the program bin directory to the system path.

In scoop, fnm in path is shim wrapper which actually call fnm installed in C:\Users\sky96111\scoop\apps\fnm\current\fnm.exe

~
❯ where.exe fnm
C:\Users\sky96111\scoop\shims\fnm.exe

~
❯ cat C:\Users\sky96111\scoop\shims\fnm.shim
path = "C:\Users\sky96111\scoop\apps\fnm\current\fnm.exe"

[bjohnso5]

you can work around this issue by using the following setup in your powershell profile:

fnm env --use-on-cd --shell power-shell | Out-String | Invoke-Expression

[sky96111]

Yes, this fixes the bug. While since 1.36.0 doesn't have this problem, I think it might be a regression error.

you can work around this issue by using the following setup in your powershell profile:

fnm env --use-on-cd --shell power-shell | Out-String | Invoke-Expression

[sky96111]

I think it might be caused by https://github.com/Schniz/fnm/commit/a1afe8436afb29960b71e14e221441398f6a48ca#diff-c42cf7f1bff071dab6b57a73c8718054d07376e6f8a417621a85a2d297f12439

[alexewsv]

same issue

[Schniz]

I’ll try to revert the changes for this module asap

Sent from my iPhone

On Fri, 31 May 2024 at 9:55 Alex @.***> wrote:

same issue

— Reply to this email directly, view it on GitHub https://github.com/Schniz/fnm/issues/1153#issuecomment-2141345039, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAPVU5CBKTWAPCLJR3V4O3LZFANFBAVCNFSM6AAAAABIQ7KD76VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNBRGM2DKMBTHE . You are receiving this because you commented.Message ID: @.***>

[Schniz]

Feel free to debug this though instead of reverting to an older dependency version, I have no windows machine to test it on right now

[alexewsv]

you can work around this issue by using the following setup in your powershell profile:

fnm env --use-on-cd --shell power-shell | Out-String | Invoke-Expression

thank you, it works

[ekarious]

Got the same problem. I use cmder most of the time so here the workaround for the fnm_init.cmd file.

:: %CMDER_ROOT%\bin\fnm_init.cmd
@echo off
FOR /f "tokens=*" %%z IN ('fnm env --use-on-cd --shell cmd') DO CALL %%z

Just need to specify the shell.

[Schniz]

specifying a shell is always a good idea, it also boots up faster