Add executeCommand Prompt
-
PR Description
-
Please check if the PR fulfills these requirements
- [x] Cheatsheets are up-to-date (run
go generate ./...) - [x] Code has been formatted (see here)
- [ ] Tests have been added/updated (see here for the integration test guide)
- [ ] Text is internationalised (see here)
- [ ] If a new UserConfig entry was added, make sure it can be hot-reloaded (see here)
- [ ] Docs have been updated if necessary
- [x] You've read through your own file changes for silly mistakes etc
@marakalwa could you explain the use-case behind this PR?
Hmm I was looking at a way to get the result of a command into an input initialValue, would this somehow allow that since initialValue could be "{{.Form.field}}" where field is the output of executeCommand ?
@marakalwa could you explain the use-case behind this PR?
Oh my, I did not want to create a pull request for this PR yet. Must have done that very sleepy, either very early or very late 😅
Hmm I was looking at a way to get the result of a command into an input initialValue, would this somehow allow that since initialValue could be
"{{.Form.field}}"wherefieldis the output ofexecuteCommand?
This is exactly the use case for this PR. Running a command without user interaction and saving the result for use in further inputs is imo absolutely vital for building powerful custom commands.
I will just use the relevant part of the customCommand that led me to create this change:
- key: 'i'
context: 'commits'
description: 'Change the commit date of this and all subsequent commits'
prompts:
- type: 'executeCommand'
command: |
date -r {{.SelectedLocalCommit.UnixTimestamp}} +"%a %b %d %H:%M:%S %Y %z" | tr -d "\n"
key: 'CurrentTimeStamp'
- type: 'input'
title: 'What is the new timestamp? Old: {{.Form.CurrentTimeStamp}}'
initialValue: '{{.Form.CurrentTimeStamp}}'
key: 'TimeStamp'
As you can see I used an excecuteCommand prompt here to format the UnixTimeStamp of the SelectedLocalCommit in such a way that it is human readable/editable (and can later be read by git in the 'command' part). Without executeCommand this would (afaik) be impossible in this form and require at least two custom commands and the use of the clipboard to get anything close to this.
I have been running lazygit with this change for over a month with various customCommands using multiple executeCommand prompts without issue.
I will try to now finish this PR asap. Lmk if you think I did something wrong here :) and thank you for this awesome tool @jesseduffield
Okay that makes sense, sounds reasonable. I'll review the code once you've completed the PR
Only stumbled upon this just now, I haven't been paying attention before.
Isn't the solution of adding an executeCommand prompt type an unnecessary indirection? We now have #4438 which adds a "runCommand" function to be used in any template, isn't that more flexible? It has the downside that you need to run the same command twice if you want to have it both in title and in initialValue, but apart from that it seems clearer and easier to me.
@marakalwa @jwickers Please have a look if this would fit your needs.
@marakalwa @jwickers #4438 has been merged to master. Can we close this?
@marakalwa @jwickers #4438 has been merged to master. Can we close this?
If one can persist values with this new option, then this would indeed be no longer necessary. Are you aware if there is some sort of sandboxing/new shell between running terminal commands?
@marakalwa @jwickers #4438 has been merged to master. Can we close this?
If one can persist values with this new option, then this would indeed be no longer necessary. Are you aware if there is some sort of sandboxing/new shell between running terminal commands?
No, there's no way to persist values, or communicate between commands. In the example above, if you want to use the result of a command twice (in title and in initialValue) you'll have to run the command twice. It's a bit of duplication, but doesn't seem too bad to me. Can you think of examples where this wouldn't be possible?