Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should lazygit be aware of the current user's shell? #1642

Closed
ghost opened this issue Dec 27, 2021 · 6 comments
Closed

Should lazygit be aware of the current user's shell? #1642

ghost opened this issue Dec 27, 2021 · 6 comments

Comments

@ghost
Copy link

ghost commented Dec 27, 2021

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

image

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

@ghost ghost added the discussion label Dec 27, 2021
@diktomat
Copy link

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.

@jesseduffield
Copy link
Owner

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"

@ghost
Copy link
Author

ghost commented May 6, 2022

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.

@Ryooooooga
Copy link
Contributor

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.

@mark2185
Copy link
Collaborator

mark2185 commented Aug 8, 2022

Related: #2096

stefanhaller added a commit that referenced this issue Aug 17, 2024
- **PR Description**

When executing an interactive custom command, use the user's shell
rather than "bash", and pass the -i flag. This makes it possible to use
shell aliases or shell functions which are not available in
non-interactive shells.

In previous attempts to solve this, concerns were brought up: [this
one](#2096 (comment))
is addressed by using the interactive shell only for custom commands but
not anything else. [This
one](#2096 (comment))
is a little dubious and unconfirmed, so I'm not very worried about it.

Supersedes #2096 and #3299. Fixes #770, #899, and #1642.
@stefanhaller
Copy link
Collaborator

Fixed by #3793.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants