Does not detect shell when called from within Far Manager
tivnet opened this issue · comments
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
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.
@uranusjr Just curious, can you check the COMSPEC env instead of using the nt module?
C:\tmp>echo %COMSPEC%
C:\WINDOWS\system32\cmd.exe
Comspec always has that value
Comspec always has that value
and so, it can be used to run the shell, can't it?
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.
OK, then you can still use it if you failed to get the real shell from the nt module, probably?
@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
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.)
Sorry, shouldn’t close this—I should look into Far Manager and see if Shellingham can detect it.