sarugaku / shellingham

With macOS's Terminal.app, the -$shell prefix applies to the default shell configured in the terminal application's settings rather than that configured by $SHELL or chsh.

In my case, I have fish as my default shell in Terminal's settings but never bothered to run chsh -s fish (there's really not a lot of point on macOS) so $SHELL still points to the default of /bin/zsh. shellingham.posix._iter_process_parents() returns

[Process(args=('python',), pid='92236', ppid='91296'), Process(args=('-fish',), pid='91296', ppid='91295')

(note the - in -fish despite fish not being my login shell!) which misleads the following line of code into checking $SHELL.

shellingham/src/shellingham/posix/__init__.py

Lines 88 to 89 in 3e7ca60

    
           if cmd.startswith("-"):  # Login shell! Let's use this. 
        
               return _get_login_shell(cmd)

>>> shellingham.detect_shell()
('zsh', '/bin/zsh')  # <-- Nooooooooo!!!!!

The obvious (but not obviously consequence free) fix I think would be to just .lstrip() away the leading - and then let it continue on to the search for known shell names?

The problem is the dash-prefixed entry does not have complete information (it depends on some login-time PATH resolution or something that’s not very clear to me and not entirely replicatable when shellingham is run). For example a lot of systems (easpecially Linux) would just have -bash but provide no information where the bash command is, and you can’t just use resolve it against PATH because that could have changed since login. One possible improvement might be to compare the final path component of the login shell and the command, and to continue searching instead of use the detected login shell if the names don’t match (in your case fish and zsh).

	if cmd.startswith("-"): # Login shell! Let's use this.
	return _get_login_shell(cmd)

Dash prefix does not always imply login shell