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

Add option to specify other shell(Arg) #3299

Closed
wants to merge 8 commits into from

Conversation

J-Kappes
Copy link

@J-Kappes J-Kappes commented Feb 2, 2024

  • PR Description

  • if os.shell is not empty it replaces the default "bash" shell and os.shellArg replaces the default "-c" argument.

  • started writing test but don't know how to check stdout or command log.

  • Please check if the PR fulfills these requirements

  • Cheatsheets are up-to-date (run go generate ./...)
  • Code has been formatted (see here)
  • Tests have been added/updated (see here for the integration test guide)
  • Text is internationalised (see here)
  • Docs (specifically docs/Config.md) have been updated if necessary
  • You've read through your own file changes for silly mistakes etc

Copy link
Contributor

@karimkhaleel karimkhaleel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the PR. I tested it out, and it seems to work as advertised. Left a couple of comments that I think could help.

pkg/gui/gui.go Outdated
Comment on lines 538 to 542
shell := gui.UserConfig.OS.Shell
if shell != "" {
osCommand.Platform.Shell = shell
osCommand.Platform.ShellArg = gui.UserConfig.OS.ShellArg
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it be better to move this logic into NewOsCommand? We want all os commands to inherit that setting, right? Or do we only want the command runner for custom commands to use the shell and shellArgs from the userconfig?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good. I don't know how to access config.OS from there, though 😕

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On second thought, I think it would make more sense to pass the OSConfig struct into oscommands.GetPlatform and get that function to extract the shell and shellArg values from there and use them there directly.

Sounds good. I don't know how to access config.OS from there, though 😕

You would be able to access the config through the Common struct that's passed into NewOsCommand function.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure, but perhaps an integration test is not the right thing for this feature? Maybe this should just be a unit test in pkg/commands/oscommands/os_test.go

},
"shell": {
"type": "string",
"description": "Shell and ShellArg are the shell and corresponding argument to be used for executing custom commands.\nSee https://github.com/jesseduffield/lazygit/blob/master/docs/Config.md#custom-command-for-copying-to-clipboard"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The URL here needs to point to the "Custom Shell for executing arbitrary commands" section of the Config.md file.

Copy link
Contributor

@karimkhaleel karimkhaleel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking good. Just one last comment.

Comment on lines +20 to +23
if osConfig.Shell != "" {
platform.Shell = osConfig.Shell
platform.ShellArg = osConfig.ShellArg
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think at this point, we should probably just consider setting bash and -c as default parameters for Shell and ShellArg in the user_config file. That way, we can just directly take the values from osConfig and use them in the Platform literal.

@yam-liu
Copy link
Contributor

yam-liu commented Aug 2, 2024

@J-Kappes Hi there,

I hope you're doing well. I wanted to check on the status of your PR for the feature we've been eagerly awaiting. Are you still able to work on it?

If you're too busy, I'd be happy to help move it forward. No pressure either way - just let me know what works best for you.

Thanks for your efforts on this!

@J-Kappes
Copy link
Author

J-Kappes commented Aug 2, 2024

Oh, yes, I'm fine.

I'm happy with the feature itself but I don't intend on finishing the test tbh.

@stefanhaller
Copy link
Collaborator

I just looked at this for the first time in more detail.

I like the feature and would like to have it myself. As I said in #3749 though, I'd prefer it if we could have this automatically with no user config, like in #2096. If people want to spend more effort on this topic, I think it would be a good idea to first spend some more time to research what was the problem with #2096 (I don't remember, and don't have time to invest in that right now myself).

Another thought: currently, the NewShell function that is being modified here is used for a ton of things, including opening files in an editor, opening links, cop&paste, updating the window title on Windows, and others. I think it could be a good idea to use the -i shell only for invoking custom commands, but not for any of the others. I'm not totally sure we really need to make this distinction, just feels better to me. Opinions welcome (ping @jesseduffield).

And finally: if we do take the approach of this PR, then I would like to wait with finishing the PR until #3787 is done, and find ways to make the new config hot-reloadable, which it currently isn't. See d3c91ac.

@jesseduffield
Copy link
Owner

Another thought: currently, the NewShell function that is being modified here is used for a ton of things, including opening files in an editor, opening links, cop&paste, updating the window title on Windows, and others. I think it could be a good idea to use the -i shell only for invoking custom commands, but not for any of the others. I'm not totally sure we really need to make this distinction, just feels better to me. Opinions welcome (ping @jesseduffield).

I agree: custom commands typically commands you would otherwise run in your shell, so using -i makes sense. It sucks that it's then inconsistent with how we invoke commands in other contexts, but I think it's a good tradeoff (obvious downside of -i is that it can slow things down)

@stefanhaller
Copy link
Collaborator

@yam-liu I opened a new PR that solves this without a config setting: #3793. Can you please check if this addresses your needs?

@J-Kappes Since your PR description doesn't say why you opened this PR or what problem it solves, I'm not totally sure if this addresses your needs. Can you please check?

@yam-liu
Copy link
Contributor

yam-liu commented Aug 4, 2024

@stefanhaller I tested it. It's just what I want.👍🏼

@J-Kappes
Copy link
Author

J-Kappes commented Aug 4, 2024

@J-Kappes Since your PR description doesn't say why you opened this PR or what problem it solves, I'm not totally sure if this addresses your needs. Can you please check?

I haven't tried it but the description sounds exaclty like what I want: being able to use my fish abbreviations.

stefanhaller added a commit that referenced this pull request 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

Closing, superseded by #3793.

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

Successfully merging this pull request may close these issues.

5 participants