sarugaku / shellingham

Tool to Detect Surrounding Shell
ISC License
221 stars 32 forks source link

Dash prefix does not always imply login shell #86

Open bwoodsend opened 4 months ago

bwoodsend commented 4 months ago

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.

https://github.com/sarugaku/shellingham/blob/3e7ca6055a8a54930cb6e0fb62605cbb17dd0585/src/shellingham/posix/__init__.py#L88-L89

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

uranusjr commented 4 months ago

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