jesseduffield
Ability to use existing shell for commands and git actions
Is your feature request related to a problem? Please describe. If you have a git hook before push/commit and it depends on a certain tool e.g. node then it is best to use the current shell.
For example I have nvm and various node versions. In the git hook it runs tests using node and it expects a certain version. I load the correct version by nvm use v8 but lazygit still complains about wrong version and stops all the commits and pushes. That is because I image it is running in a separate shell like when you run custom commands, and in that shell nvm never switched to required version.
This is the same issue when you run custom commands, it runs bash -c .... Firstly now you need to format your commands for bash instead of default shell/current shell which is very annoying (especially for fish users where syntax is different). And you cannot use local variables, and some time even all commands as you might not have updated .bashrc to include all paths that are there in your current/default shell; since you never use it.
Describe the solution you'd like Run all custom commands and git commands in current shell process.
Describe alternatives you've considered
Alternative is using git directly from current shell and not using lazygit.
I briefly looked into this a while back but couldn't find a way to carry over the state of the shell environment into the program. I think it's a security thing, though my memory is hazy on it. Perhaps there's a way to initialize a new shell from within lazygit, however that wouldn't be able to carry over variables defined on the outside
I think we can get halfway there by letting the user specify which shell to use. It means you won't have access to local variables but you'll get access to your rc file for example (I think)
I wonder if that'll work with nvm because you need to do nvm use but it would certainly be a good step forward to be able to specify a shell. The shells can be hooks like you say to do these actions before running the custom command. This would be a good feature regardless! 💯
It is the hooks that need the custom environment. We chose not to include nvm use etc. in hooks because people use different tools to manager versions. This is sadly true for most other languages. So it is on the user to "be" in the right env for the git hooks.
~~Can we maybe use the same shell for all custom command and hooks? Because then user can do it normally in two commands e.g. nvm use and then Commit action that will run the hooks' tests in same shell which is using the correct version of tool~~ 🤔 ... totally a random idea.
What about lazygit runs the hooks in the same env as the shell it was launched in so the user has the responsibility to do nvm use before launching lazygit. And then hooks should run fine.
Is there an argument to run the custom commands in the same env as well? It would create consistent experience and would remove the need for the feature mentioned above.
I recently ran into that issue so don't mind me just bumping for visibility.
Looks like there is a promising PR on the horizon https://github.com/jesseduffield/lazygit/pull/3299
Hello. I have stumbled upon this thread when I was trying to make lazygit open the file in neovim (which is aliased in my .zshrc file). I built the project from source because I saw that the last release was pretty old. My default shell is zsh, and I also added logs in the code here: https://github.com/jesseduffield/lazygit/blob/05ae0800c3ff3fd7160a5705a8fbac7f50745624/pkg/commands/oscommands/os_default_platform.go#L23-L28
and the correct shell is logged, but the command still uses bash.
As a workaround I've changed the edit command with the full path to nvim in the config file, but I'd like to make this work. I'd appreciate it if someone could help me 🙏
The fix in #3793 only affects commands typed at the : custom command prompt; it doesn't affect your editor commands. This was intentional.
As a workaround I've changed the edit command with the full path to nvim in the config file,
I wouldn't call that a workaround, this seems like the appropriate solution to me. What's wrong with it?
but I'd like to make this work.
What's missing for that?
Oh.
I wouldn't call that a workaround, this seems like the appropriate solution to me. What's wrong with it?
Nothing wrong necessarily but I was hoping I could force lazygit to use zsh and load my .zshrc when using commands such as edit. I share my configs with my linux machine as well and wanted to use the alias for nvim instead of hardcoding the full path to the binary.
@NeaGogu if you export the PATH variable, it should get picked up. for fish i do fish_add_path -P ... and it gets picked up
@lordlycastle @peter-cardenas-ai @PeterCardenas @GeorgiChochev This was fixed in #3793, but we are now considering reverting that PR because it creates problems. We are proposing to do #4385 instead, which requires a bit of setup work for users. Please give your feedback on whether you think this is a viable approach.
i have since worked around this limitation by adding directly to PATH so that sub processes can call commands, and have moved my fish functions for clipboard copy and edit to a directory in my PATH. i would still prefer interactive for simplicity but this could also work so that i can source specific functions while keeping them in the fish functions directory for performance. i will say it's a bit non-intuitive that these functions aren't available. that is, people are going to run into the issue of the function not being available, and most likely will hack it so that it's always available in noninteractive mode in any shell like I did
@PeterCardenas As a fish user you won't have to do anything. If I'm not mistaken, then ~/.config/fish/config.fish is sourced for both interactive and non-interactive shells, so all you have to do is make sure that your function definitions are outside of the if status is-interactive condition in that file, and then it will just work.
hmm i was referencing putting my function in ~/.config/fish/functions to be autoloaded, but it appears these are available in non-interactive mode as well! lgtm then, can't speak for other shells tho