doesn't detect bash on win32

[Darrel O'Pry]

dopry@Quasar MINGW64 ~
$ python
Python 3.10.8 (tags/v3.10.8:aaaf517, Oct 11 2022, 16:50:30) [MSC v.1933 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import shellingham
>>> shellingham.detect_shell()
('cmd', 'C:\\Windows\\System32\\cmd.exe')
>>>

[Darrel O'Pry]

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.

[Tzu-ping Chung]

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.

[Darrel O'Pry]

@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?

[Tzu-ping Chung]

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

1. Write a command in a bat file and run it in Powershell
2. Run cmd in Powershell, and run a command in that nested shell

which is one of the reasons bat files is disliked.

[Darrel O'Pry]

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..

[Tzu-ping Chung]

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.

[Darrel O'Pry]

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.