Closed dopry closed 1 year ago
I've dug into this a bit more... I'm using pyenv which has a shim that wraps the call to python in a .bat script which uses cmd.exe.
For posix compliant shells, even those ported to windows, you can probably check os.getenv('SHELL') before doing the process tree lookup.
Shellingham detects the surrounding shell, while the SHELL
environment variable denotes the default shell. It is indeed used as a fallback, but any shell that's actually detected in the process tree has precedence. The rest is essentially #65 and a consequence of using a bat file.
@uranusjr I understand the need for detecting the surrounding shell. I think it would be nice to have a detect_interactive_shell as well that tries to get the first interactive shell. Both poetry and pipenv use shellingham to detected the user shell when launching a 'virtualenv shell'. In the case of launching a shell on behalf of the user, I think targeting the interactive is best. It would be nice if that functionality could be implemented once in shellingham, rather than in both downstream projects. Thoughts?
The problem with .bat is it provides no way to distinguish whether the cmd.exe is user-invoked or not. As far as I know, there’s no detectable differences between
cmd
in Powershell, and run a command in that nested shellwhich is one of the reasons bat files is disliked.
yeah... it may be hard to do all cases... but at least for the posix shells on windows $SHELL should be authoritative, and then windows users could be direction to set SHELL env:Shell, etc to set their preferred interactive shell even if they're using powershell or cmd, then fallback to the resolution. For the ptree lookup, it could be switched to pick up the outermost shell instead of the innermost shell..
As I said, we want the surrounding shell, not the default shell, and $SHELL
is the wrong answer for the more logically standard scenario the user manually launches a shell inside a shell. You can use zsh in MSYS without changing $SHELL
, for example.
I was specifically talking about an proposed implementation of detect_interactive_shell that tries to identify the user shell, but not the surrounding shell... but it sounds like you're not interested in implementing that feature.