Does not detect shell when called from within Far Manager

[tivnet]

https://www.farmanager.com/download.php?l=en

C:\tmp>pipenv shell
Traceback (most recent call last):
  File "c:\python36\lib\runpy.py", line 193, in _run_module_as_main
"__main__", mod_spec)
...
...
File "c:\python36\lib\site-packages\pipenv\shells.py", line 29, in detect_info
raise ShellDetectionFailure
pipenv.vendor.shellingham.ShellDetectionFailure

The same under regular command prompt works fine:

C:\tmp>pipenv shell
Launching subshell in virtual environment…
Microsoft Windows [Version 10.0.16299.461]
(c) 2017 Microsoft Corporation. All rights reserved.

@uranusjr FYI

[uranusjr]

I learn a new thing today! To work around this you can set PIPENV_SHELL to avoid shell detection (in case anyone reading this issue doesn’t know). Maybe I should add an error message here.

[tivnet]

@uranusjr Just curious, can you check the COMSPEC env instead of using the nt module?

C:\tmp>echo %COMSPEC%
C:\WINDOWS\system32\cmd.exe

[techalchemy]

Comspec always has that value

[tivnet]

Comspec always has that value

and so, it can be used to run the shell, can't it?

[uranusjr]

COMSPEC is always cmd.exe even if you are running another shell, e.g. Powershell. It would be very surprising to users if a cmd.exe is launched when the outer shell is not cmd.exe.

[tivnet]

OK, then you can still use it if you failed to get the real shell from the nt module, probably?

[techalchemy]

@tivnet if you think you have a solution we would be interested in reviewing a PR or an example of what you mean, we've spent a considerable amount of effort looking at this problem and didn't come to a consistent and acceptable answer

[uranusjr]

PR is up. (This is actually fixed in Pipenv; Shellingham is only interested in shell detection, it’s up to the callee to handle the failure and choose a reasonable fallback.)

[uranusjr]

Sorry, shouldn’t close this—I should look into Far Manager and see if Shellingham can detect it.