Updated PR to latest ripgrep release.

Standards checklist:

• [x] The PR title is descriptive.
• [x] The PR doesn't replicate another PR which is already open.
• [x] I have read the contribution guide and followed all the instructions.
• [x] The code follows the code style guide detailed in the wiki.
• [x] The code is mine or it's from somewhere with an MIT-compatible license.
• [x] The code is efficient, to the best of my ability, and does not waste computer resources.
• [x] The code is stable and I have tested it myself, to the best of my abilities.

Changes:

• allow for customization of RPROMPT (exit code and timestamp)

• improve code and comments

Perhaps this would warrant a separate version of the plugin? One which works with the old version of Docker, and a new one for the new version. Optionally, the older (and currently only existing) plugin could check if the Docker version is new enough to support the new syntax and suggest that the user "upgrades" to the new version of the plugin. Eventually, the old plugin can be removed as more and more people upgrade their Docker installation.

Is your feature request related to a particular plugin or theme? If so, specify it. the git plugin

Is your feature request related to a problem? Please describe. gpr is easier to remember and type, than gup.

Describe the solution you'd like add an alias gpr for "git pull -r"

Describe alternatives you've considered n/a

Additional context Add any other context, screenshots or discord conversations about the feature request here. Also if you have any PRs related to this issue that are already open that you would like us to look at.

Related Issues no

merged into master

@hjpotter92 How is this looking after an omz update?

did a git pull, the recent master branch still has the lockfile generation code: https://github.com/ohmyzsh/ohmyzsh/blob/master/plugins/ssh-agent/ssh-agent.plugin.zsh

he reverted the merge

i don't think the revert got merged back: https://github.com/ohmyzsh/ohmyzsh/compare/revert-6309-ssh

By the way @robbyrussell, you can go to "Files changed" and request changes instead of closing PRs.

I don't really understand what this PR does; could you explain?

I think it would be better if you mentioned ONLY show http code and discard the rest. People might be expecting otherwise. Otherwise, LGTM!

he reverted the merge

this leads to infinite loop on termux since the sandbox doesn't have access to /tmp and the path had been hardcoded.

+/data/data/com.termux/files/home/.oh-my-zsh/oh-my-zsh.sh:107> plugin=ssh-agent   +/data/data/com.termux/files/home/.oh-my-zsh/oh-my-zsh.sh:108> [ -f /data/data/com.termux/files/home/.oh-my-zsh/custom/plugins/ssh-agent/ssh-agent.plugin.zsh ']'   +/data/data/com.termux/files/home/.oh-my-zsh/oh-my-zsh.sh:110> [ -f /data/data/com.termux/files/home/.oh-my-zsh/plugins/ssh-agent/ssh-agent.plugin.zsh ']'          +/data/data/com.termux/files/home/.oh-my-zsh/oh-my-zsh.sh:111> source /data/data/com.termux/files/home/.oh-my-zsh/plugins/ssh-agent/ssh-agent.plugin.zsh            +/data/data/com.termux/files/home/.oh-my-zsh/plugins/ssh-agent/ssh-agent.plugin.zsh:1> lockdir=/tmp/oh-my-zsh-ssh-agent.lock                                        +/data/data/com.termux/files/home/.oh-my-zsh/plugins/ssh-agent/ssh-agent.plugin.zsh:3> true                                                                         +/data/data/com.termux/files/home/.oh-my-zsh/plugins/ssh-agent/ssh-agent.plugin.zsh:4> mkdir /tmp/oh-my-zsh-ssh-agent.lock                                          +/data/data/com.termux/files/home/.oh-my-zsh/plugins/ssh-agent/ssh-agent.plugin.zsh:9> sleep 0.1                                                                    +/data/data/com.termux/files/home/.oh-my-zsh/plugins/ssh-agent/ssh-agent.plugin.zsh:3> true                                                                         +/data/data/com.termux/files/home/.oh-my-zsh/plugins/ssh-agent/ssh-agent.plugin.zsh:4> mkdir /tmp/oh-my-zsh-ssh-agent.lock                                          +/data/data/com.termux/files/home/.oh-my-zsh/plugins/ssh-agent/ssh-agent.plugin.zsh:9> sleep 0.1

Standards checklist:

<!-- Fill with an x the ones that apply. Example: [x] -->

• [ ] The PR title is descriptive.
• [ ] The PR doesn't replicate another PR which is already open.
• [ ] I have read the contribution guide and followed all the instructions.
• [ ] The code follows the code style guide detailed in the wiki.
• [ ] The code is mine or it's from somewhere with an MIT-compatible license.
• [ ] The code is efficient, to the best of my ability, and does not waste computer resources.
• [ ] The code is stable and I have tested it myself, to the best of my abilities.

Changes:

Created alias for pip commands to create requirements.txt file, install packages from requirements.txt file, update and uninstall all packages.

Ref: https://github.com/ohmyzsh/ohmyzsh/pull/9405

I understand what you're saying, but I think we should be steering people towards properly setting up their system rather than encouraging a setup that only works some of the time, and inevitably leads to confusion when it stops working.

Maybe a reasonable compromise is to check whether pyenv is set up correctly in the plugin (maybe just check if PYENV_ROOT is set). If it isn't, we can print a message explaining what needs to be added to your .profile. If you really insist on not breaking anything, then we can do the setup for them under that guard.

This way, for the people that have correctly set up their systems, the pyenv plugin won't do anything. For the people that were relying on the old behaviour, the pyenv plugin will continue to work and will print a message explaining how to improve their setup.

I don't think such a dogmatic approach is helping here. The pyenv plugin was working fine for lots of people. The last pyenv release does not change anything in the way we should discover where pyenv is installed - only where pyenv itself installs Python versions and shims.

If you remove the path discovery for pyenv itself, as this PR currently tries to do, it will break e.g., for everybody using macOS and homebrew or custom install locations or any of the other options that are covered in the code you are removing. This means the omz pyenv plugin is useless and can be disabled/removed all together. This is the same mechanism that countless other omz plugins utilize to discover their own binaries as well - most of them with multiple options to account for different Linux distributions, macOS, custom and non-standard paths as fallback.

If pyenv needs to work in non-interactive shells too, then most of its setup needs to happen in .profile.

Yes, ideally the path for the shims (as generated by pyenv init --path) would be placed into a file that is loaded for both interactive and non-interactive shells. I feel like this is out of scope of a omz plugin (and always has been). The current pyenv plugin works perfectly fine for interactive sessions, and even for any zsh-based scripts that you launch from your typical terminal. If you need full non-interactive sessions to work, then yes, go ahead and add the correct paths to your .profile - but why do you want to break a working system for everybody else?

If I understand your PR correctly, you are just removing all logic for changing the PATH to find the pyenv binary itself - this is independent of the shims and installed python versions.

If that logic belongs anywhere, it's in your .profile.

that's what pyenv init --path is for.

That line, which should also be in your .profile, makes the Python shims accessible.

The change you are proposing renders the pyenv plugin almost useless as there will be no init at all if the plugin can't find the pyenv binary.

That's because most of what is being done in the pyenv plugin is being done in the wrong place. If pyenv needs to work in non-interactive shells too, then most of its setup needs to happen in .profile.

Please read the corresponding issue thread. I was as confused as you are until someone corrected my understanding.

If I understand your PR correctly, you are just removing all logic for changing the PATH to find the pyenv binary itself - this is independent of the shims and installed python versions. That's what pyenv init --path is for. The change you are proposing renders the pyenv plugin almost useless as there will be no init at all if the plugin can't find the pyenv binary.

Standards checklist:

<!-- Fill with an x the ones that apply. Example: [x] -->

• [x] The PR title is descriptive.
• [x] The PR doesn't replicate another PR which is already open.
• [x] I have read the contribution guide and followed all the instructions.
• [x] The code follows the code style guide detailed in the wiki.
• [x] The code is mine or it's from somewhere with an MIT-compatible license.
• [x] The code is efficient, to the best of my ability, and does not waste computer resources.
• [x] The code is stable and I have tested it myself, to the best of my abilities.

Changes:

• In line with recent changes to pyenv, pyenv init --path must be run before pyenv init -.

Other comments:

Without this, I get the following warning when using the latest pyenv version:

WARNING: `pyenv init -` no longer sets PATH.
Run `pyenv init` to see the necessary changes to make to your configuration.

Totally agreed @NeilGirdhar - this fix works for some use cases but clearly not for all. I've done a bit of reading since putting this together, but didn't get around to checking back here. Closing this now

@Kriechi No, because the PATH should be set in your .profile, which is sourced by your .zsh_profile. This is explained in the thread. That fix will wreck pynev for non-interactive shells.

This fix is incorrect. Please read the corresponding issue thread carefully. If this fix is accepted, pyenv will only work for interactive shells.

IMO https://github.com/ohmyzsh/ohmyzsh/pull/9909 is a more correct fix.

@robbyrussell @untoreh I don't know if it's related, but since this was merged, whenever I source ~/.zshrc, I now get:

[oh-my-zsh] plugin 'thefuck,' not found

🤔

I had last successfully loaded the plugin 4 hours ago.

@robbyrussell Maintainer added in the README 👍