jesseduffield
Should lazygit be aware of the current user's shell?
Topic
Today (12/27/2021), lazygit assumes that bash is present on the user's computer, on linux-based OS's at least (or if this is not the default behavior and I doing something wrong, please let me know ;) ). This discussion is about the implementation of a "env variable search" to get the current user's shell.
Your thoughts
My thoughts on the matter are a favorable to a change in the source code, making it such tha lazygit always get the current shell that it is running in. That will prevent unexpected behavior such as launching a instance of bash to run external command or maybe not executing said command at all if bash is not a executable in the user's machine. This behavior is seen in the edit command for example
This is something that in most use cases will not occur but today, as I know of, lazygit doesn't cover this issue.
Should it be easy enough to implement, I propose this issue be adressed.
(Again, maybe I'm being dumb and again, to my knowledge, lazygit does not handle this edge case.) Ps.: Sorry for any bad English. I'm not a native Englishe speaker.
Wishing fruitfull discussions
Plus one from me, as Bash doesn't know my $PATH and so I can't open or edit unless I provide the whole path to the open/edit commands in config.
Makes sense to me. I can't think of any good reason not to do this. One question: can we rely on each shell being invokable with the -c argument? i.e. zsh -c "echo blah"
I think most of the popular shells implement the -c option, since they aim to be compatible with sh. I suppose the POSIX complaint shells should behave well with the change. I'll do some research on it, though.
If use non-POSIX $SHELL, the string quoting process seems to break.
For example, (when commit.gpgSign=true), bash -c "git commit -m ..." is executed for commit, but fish does not need to escape ` in the commit message.
Absorbing these shell-specific differences can be difficult.
