search

Powerlevel9k / powerlevel9k

Powerlevel9k was a tool for building a beautiful and highly functional CLI, customized for you. P9k had a substantial impact on CLI UX, and its legacy is now continued by P10k.
https://github.com/romkatv/powerlevel10k
MIT License
13.47k stars 947 forks source link

[Bugfix] prompt_rbenv fails if specified local ruby version is not present #1197

Open ChrisBaker97 opened 5 years ago

ChrisBaker97 commented 5 years ago

There is a bug in prompt_rbenv() that appears when a user enters a directory where a local rbenv setting specifies a version that is not present on the local machine:

image

My rbenv has system and 2.6.1 installed, with 2.6.1 set as the global version. However, the oh-my-zsh custom plugin zsh-autosuggestions has a .ruby-version file in its project directory which specifies ruby version 2.5.3, which is not installed.

prompt_rbenv() invokes rbenv version-name to determine the local ruby version, which works fine when there is a local version that's installed with rbenv or there is no local version specified. However, when a local version is specified that isn't present on the machine, rbenv version-name displays no stdout but does exit with a value of 1 and produces the stderr that's polluting the prompt:rbenv: version '2.5.3' is not installed... Since it doesn't supply any stdout, prompt_rbenv() has no version info to publish and simply shows the ruby logo, which is unhelpful for users trying to figure out what's going on.

First, this fix silences the error that's escaping into the prompt by appending 2>/dev/null to the rbenv version-name call.

Then, because rbenv local will always supply the local version number (even if it's not present) the logical OR function || is used to ensure that it's called, should rbenv version-name error out. It should be noted that rbenv local actually errors out if a local version isn't specified at all, but that's not a problem, since it will only be called if (and only if) rbenv version-name fails, but in that case, rbenv version-name simply returns the global version first.

Similarly, this bug fix adds no additional overhead, since rbenv local will only be called in the relatively rare event that rbenv version-name first fails. However, I do agree with the discussion in #215, in that a way should probably be found to optimize or cache this function, since it is going to invoke at least one instance of rbenv for every prompt, even when there is no ruby project to be found and nothing additional is displayed on the prompt to atone for it.

Finally, I thought it would be nice if there were also an indication that the requested ruby version wasn't installed—rather than just printing it as if everything was normal—so I enclosed the version number in quotes in that instance. It could be a future enhancement to include a warning triangle ⚠️ icon, or change the colors, or something else, but I didn't bother here.

So, after the patch is applied, here's the new behavior:

image
ChrisBaker97 commented 5 years ago

Commit 76c0683 uses the "X" FAIL_ICON prepended to the requested ruby version to indicate a missing ruby version, instead of using parentheses. I think I like this a little better, but pick whichever you prefer to merge.

image