I just upgraded this package in Arch Linux. Every time I open a new terminal I get the following message.
powerlevel9k_init:41: command not found: segment_in_use
prompt_vcs:6: command not found: vcs_info
In addition, for every new prompt/command (in the same window) I get the second line, prompt_vcs….
I tried reverting from v0.5.0.r0.gc4fdc8f-1 to v0.3.1.r178.g520eed1-1, and I no longer get this message.
Thanks for the bug report, @protist!
I'm not an Arch user myself, and so it's not easy for me to debug this. @shibumi is the packager for Arch, though, so perhaps he has some insight. If we need to tag a v0.5.1 bug release, I can do that ASAP.
So looking at the error, there appears to be an issue with the segment_in_use function, which was just merged into master as part of the v0.5.0 release. You can find the function here: https://github.com/bhilburn/powerlevel9k/blob/c4fdc8f70804fea6f543e6bbf3964301e2537e36/functions/utilities.zsh#L130
@shibumi - Do you see this error on your machine? I'm wondering if I did something that broke things on Arch somehow, or if perhaps the utilities.zsh file wasn't updated in the package?
Hello @bhilburn , @protist
I am running: zsh-theme-powerlevel9k-git v0.5.0.r0.gc4fdc8f-1 here. I don't have any problem.
But I had before a similiar problem that some other function the 'print_icon' function wasn't found.
I have fixed it with the right locale-settings:
https://github.com/bhilburn/powerlevel9k/issues/313
btw: the -git package is not from me. The -git package is from a guy called florian:
https://aur.archlinux.org/packages/zsh-theme-powerlevel9k-git/
https://aur.archlinux.org/packages/zsh-theme-powerlevel9k/
@bhilburn I'm not using the tagged release, but using the latest git version. I was trying to imply this with the link to the package and version numbers, but was clearly not explicit enough. This bug was introduced in commit c4fdc8f for me.
@shibumi I'm not even sure what systemd-locale is, but I haven't changed locale for several years, and certainly not since I installed powerlevel9k. I'm happy to investigate this further, but not sure where to go.
@protist
You can modify systemd-localed with: localectl
Here is my output:
System Locale: LANG=en_US.UTF-8
VC Keymap: us
X11 Layout: us
I can remember when I had German system locale I broke zsh-powerlevel9k, because the hardcoded utf-8 symbols had destroyed the shellscript. A solution could be to remove all comments that include utf-8 symbols in the script or to set your system-locale to US layout
I suspect that this is probably not the case here, because I've never used a non–English-language locale. However, here is the output for localectl status and locale.
$ localectl status
System Locale: LANG=en_AU.UTF-8
VC Keymap: n/a
X11 Layout: n/a
$ locale
LANG=en_AU.UTF-8
LC_CTYPE="en_AU.UTF-8"
LC_NUMERIC="en_AU.UTF-8"
LC_TIME="en_AU.UTF-8"
LC_COLLATE="en_AU.UTF-8"
LC_MONETARY="en_AU.UTF-8"
LC_MESSAGES="en_AU.UTF-8"
LC_PAPER="en_AU.UTF-8"
LC_NAME="en_AU.UTF-8"
LC_ADDRESS="en_AU.UTF-8"
LC_TELEPHONE="en_AU.UTF-8"
LC_MEASUREMENT="en_AU.UTF-8"
LC_IDENTIFICATION="en_AU.UTF-8"
LC_ALL=
@protist
Can you try to set a locale like mine? I just want to exclude the locale as problem.
Sure. First, here are the previous locale settings.
powerlevel9k_init:41: command not found: segment_in_use
prompt_vcs:6: command not found: vcs_info
$ localectl status
System Locale: LANG=en_AU.UTF-8
VC Keymap: n/a
X11 Layout: n/a
prompt_vcs:6: command not found: vcs_info
$ locale
LC_CTYPE="en_AU.UTF-8"
LC_NUMERIC="en_AU.UTF-8"
LC_TIME="en_AU.UTF-8"
LC_COLLATE="en_AU.UTF-8"
LC_MONETARY="en_AU.UTF-8"
LC_MESSAGES="en_AU.UTF-8"
LC_PAPER="en_AU.UTF-8"
LC_NAME="en_AU.UTF-8"
LC_ADDRESS="en_AU.UTF-8"
LC_TELEPHONE="en_AU.UTF-8"
LC_MEASUREMENT="en_AU.UTF-8"
LC_IDENTIFICATION="en_AU.UTF-8"
LC_ALL=
prompt_vcs:6: command not found: vcs_info
Then, I'll set the new locale.
powerlevel9k_init:41: command not found: segment_in_use
prompt_vcs:6: command not found: vcs_info
$ localectl set-locale LANG=en_US.utf8
prompt_vcs:6: command not found: vcs_info
$ sudoedit /etc/locale.conf
I changed /etc/locale.conf from LANG=en_AU.utf8 to LANG=en_US.utf8. I also needed to change the locale in KDE Plasma's system settings. I restarted, then checked the locale again.
powerlevel9k_init:41: command not found: segment_in_use
prompt_vcs:6: command not found: vcs_info
$ localectl status
System Locale: LANG=en_US.utf8
VC Keymap: n/a
X11 Layout: n/a
prompt_vcs:6: command not found: vcs_info
$ locale
LANG=en_US.utf8
LC_CTYPE="en_US.utf8"
LC_NUMERIC="en_US.utf8"
LC_TIME="en_US.utf8"
LC_COLLATE="en_US.utf8"
LC_MONETARY="en_US.utf8"
LC_MESSAGES="en_US.utf8"
LC_PAPER="en_US.utf8"
LC_NAME="en_US.utf8"
LC_ADDRESS="en_US.utf8"
LC_TELEPHONE="en_US.utf8"
LC_MEASUREMENT="en_US.utf8"
LC_IDENTIFICATION="en_US.utf8"
LC_ALL=
prompt_vcs:6: command not found: vcs_info
$
prompt_vcs:6: command not found: vcs_info
I hit enter a few times and I still get prompt_vcs:6: command not found: vcs_info, so it doesn't appear to have fixed it.
Can you try to set VC keymap and X11 Layout also?
Also, I wonder if it might be worth trying @shibumi's AUR package rather than florian's?
This could be a solution. My package is the stable package (not the git branch). Current stable version is 0.5.0
The stable package (0.5.0-1) also fails for me.
I made the three locale changes that I mentioned in my earlier post, then did the following.
$ localectl set-keymap us
prompt_vcs:6: command not found: vcs_info
$ localectl set-x11-keymap us
prompt_vcs:6: command not found: vcs_info
$ localectl status
System Locale: LANG=en_US.utf8
VC Keymap: us
X11 Layout: us
prompt_vcs:6: command not found: vcs_info
I restarted, but the problem is still present.
powerlevel9k_init:41: command not found: segment_in_use
prompt_vcs:6: command not found: vcs_info
$ locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=
prompt_vcs:6: command not found: vcs_info
$ localectl
System Locale: LANG=en_US.utf8
VC Keymap: us
X11 Layout: us
prompt_vcs:6: command not found: vcs_info
FWIW I tried to cd to a git directory, and the git-related status fails.
Just for being sure. You did restart the Terminal after your locale changes, or?
I restarted the entire computer.
Hi @protist - thanks for debugging this with us. It's pretty strange, and I do want to make sure we get it resolved.
Okay, so, a few things:
grep your source, I'm positive you would see the "missing" functions in your source tree (e.g., segment_in_use). I'm thinking it has to be a parsing issue of the code which results in the function not being found. If you go into your source tree, git revert c4fdc8f, then restart your terminal, is the problem solved?A few additions:
Oh… man… I am _so_ sorry. It turns out that it's a really stupid mistake on my behalf.
I tried creating a new user with a fresh zshrc to see if the problem still persisted. I copied over the powerlevel9k settings… and then realised that some of the paths were wrong. I'd previously had a user-level install of zim, which contained a user-level git clone of powerlevel9k. However, I'd since moved to a system-level install of both. However, my zshrc was still pointing to the user-level powerlevel9k, which hadn't been updated. I don't exactly understand why, but I guess the problem must have been from a conflict with the two installs.
Anyway, I fixed the path, and it's all fine now. I tested both the stable and -git PKGBUILDs, and both work perfectly. Thank you for your help and comments, and apologies again for wasting your time!
@protist - Not a problem. I'm really happy you're up and running!
It's also very useful for me (and @shibumi) to know what the solution was. If someone files a similar bug report in the future, we'll know another potential cause!
Don't worry! Nice that you found the reason for this behaviour.
Most helpful comment
@protist - Not a problem. I'm really happy you're up and running!
It's also very useful for me (and @shibumi) to know what the solution was. If someone files a similar bug report in the future, we'll know another potential cause!