Detect the user's shell for running custom commands

[mark2185]

This makes it possible to use any shell, and by adding the -i flag it
makes it interactive (running aliases and functions is possible now)

Should close #770 .

Tests are still TODO

[jesseduffield]

couple thing

[jesseduffield]

what does the i flag do and how many shells support it?

[mark2185]

It makes the shell interactive which in turn reads startup files (among other things), which allows you to use aliases, functions and variables defined in your e.g. .zshrc.

I tried it with bash, zsh and fish and all of them support the i flag.

[jesseduffield]

Wow very cool. I wonder if this will slow things down for users that have extensive e.g. zshrc files.

[jesseduffield]

This logic isn't quite right:
If shell != default shell, we return shell
if shell == default shell, we return default shell which is really just shell

So we're returning shell either way.

I would instead say that if SHELL is blank string, we default to bash

[mark2185]

We presume the shell is bash.

If we read the environment variable SHELL (which actually returns the absolute path, my bad) and it turns out to be zsh (!= bash), we return zsh which... yeah, okay

So we're returning shell either way.

Well, when you put it that way... 😅

[mark2185]

cc @Ryooooooga for additional input, on #1642 they said:

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.

[cfurrow]

An interesting side-effect of applying these changes that I've seen was that upon returning from committing, the lazygit app gets suspended. Here's the example output I see after committing something from within lazygit:

+ /bin/zsh -ic git commit -m "Move shell assignment up"

[pr-2096 3791988d] Move shell assignment up
 1 file changed, 2 insertions(+), 1 deletion(-)

Press enter to return to lazygit[1]  + 82736 suspended (tty input)  bin/lazygit

When I bring the app back to the foreground with fg, it's blank and the current terminal is unresponsive. This "unresponsive" and "blank" behavior is common when using lazygit with Warp, which was why I was testing your PR in the first place to see if it would fix the issues users have seen with lazygit and Warp: warpdotdev/Warp#1511. (it does not fix it).

I don't know if the underlying issue is with the go terminal UI library (gocui?) and Warp, as a root cause is not currently known. I'm simply posting these details to relate the filed issue for Warp with this PR in case someone figures out what's wrong with how Warp handling the lazygit response. Being that Warp does not quite play by the same rules as other terminals and shells.