Powerlevel9k: locale being overridden

Created on 1 Aug 2017  路  11Comments  路  Source: Powerlevel9k/powerlevel9k

Hi,

I've just spent a loooong time trying to find the reason my system locale was being overridden to en_US and finally tracked it down to this line: https://github.com/bhilburn/powerlevel9k/blob/master/functions/icons.zsh#L21

This declaration of local is not in fact localised see: http://zsh.sourceforge.net/Doc/Release/Functions.html#Anonymous-Functions

Fonts bug help wanted master

Most helpful comment

I tried to fix it, it was not really well tested, but here the patch that works for me :

diff --git a/functions/icons.zsh b/functions/icons.zsh
index d8661e6..6300d64 100755
--- a/functions/icons.zsh
+++ b/functions/icons.zsh
@@ -13,6 +13,7 @@

 # Initialize the icon list according to the user's `POWERLEVEL9K_MODE`.
 typeset -gAH icons
+() {
 case $POWERLEVEL9K_MODE in
   'flat'|'awesome-patched')
     # Awesome-Patched Font required! See:
@@ -528,6 +529,7 @@ esac
 if [[ "$POWERLEVEL9K_HIDE_BRANCH_ICON" == true ]]; then
     icons[VCS_BRANCH_ICON]=''
 fi
+}

 # Safety function for printing icons
 # Prints the named icon, or if that icon is undefined, the string name.

All 11 comments

I guess that a

local LC_ALL="" 
local LC_CTYPE="en_US.UTF-8"

would fix this issue, am I right?

That won't work unfortunately. My understanding from the ZSH documentation is that outside of a function local applies globally. This is what I'm seeing as the following in my .zshrc

source $ZSH/oh-my-zsh.sh
source /etc/profile.d/locale.sh

still results in LC_CTYPE=en_US.UTF-8 and LC_ALL=

(for completeness, here's my ~/.config/locale.conf)

LANG=en_GB.UTF-8
LC_CTYPE=en_GB.UTF-8
LC_NUMERIC=en_GB.UTF-8
LC_TIME=en_GB.UTF-8
LC_COLLATE=en_GB.UTF-8
LC_MONETARY=en_GB.UTF-8
LC_MESSAGES=en_GB.UTF-8
LC_PAPER=en_GB.UTF-8
LC_NAME=en_GB.UTF-8
LC_ADDRESS=en_GB.UTF-8
LC_TELEPHONE=en_GB.UTF-8
LC_MEASUREMENT=en_GB.UTF-8
LC_IDENTIFICATION=en_GB.UTF-8
LC_ALL=en_GB.UTF-8

and /etc/profile.d/locale.sh

#!/bin/sh

if [ -z "$LANG" ]; then
  if [ -n "$XDG_CONFIG_HOME" ] && [ -r "$XDG_CONFIG_HOME/locale.conf" ]; then
    echo "found $XDG_CONFIG_HOME/locale.conf"
    . "$XDG_CONFIG_HOME/locale.conf"
  elif [ -n "$HOME" ] && [ -r "$HOME/.config/locale.conf" ]; then
    echo "found $HOME/.config/locale.conf"
    . "$HOME/.config/locale.conf"
  elif [ -r /etc/locale.conf ]; then
    echo "found /etc/locale.conf"
    . /etc/locale.conf
  fi
fi

LANG=${LANG:-C}
export LANG
[ -n "$LC_CTYPE" ]          && export LC_CTYPE
[ -n "$LC_NUMERIC" ]        && export LC_NUMERIC
[ -n "$LC_TIME" ]           && export LC_TIME
[ -n "$LC_COLLATE" ]        && export LC_COLLATE
[ -n "$LC_MONETARY" ]       && export LC_MONETARY
[ -n "$LC_MESSAGES" ]       && export LC_MESSAGES
[ -n "$LC_PAPER" ]          && export LC_PAPER
[ -n "$LC_NAME" ]           && export LC_NAME
[ -n "$LC_ADDRESS" ]        && export LC_ADDRESS
[ -n "$LC_TELEPHONE" ]      && export LC_TELEPHONE
[ -n "$LC_MEASUREMENT" ]    && export LC_MEASUREMENT
[ -n "$LC_IDENTIFICATION" ] && export LC_IDENTIFICATION

Again from the docs, it seems all that would be necessary is wrapping that bit of code in icons.zsh in an anonymous function

This has been annoying me too. I get a locale config that I think works, put it in my zshrc, and next time I use it on another similar machine the warnings start up again.

It would appear I accidentally neglected this bug. Sorry, @wengole!

@wengole - Your suggestion of wrapping the locale / icon definitions in an anonymous function is a good one, but unfortunately I don't think it will solve the problem. The icon code points are not reset with every prompt-draw - they are only set once, when P9k initializes. If the locale is wrong, each time P9k goes to ask your font for an icon (i.e., during each prompt draw), I think the font will come back with something crazy.

I think what we need to do is find a way to define the locale for P9k, only, for every draw, while not affecting the rest of your terminal. This may mean sticking it in an anonymous function in powerlevel9k_prepare_prompts? Thoughts, @dritter?

I don't have any meaningful to add. I'm experiencing the same bug. Just wanted to bump the issue (no updates in a year!).

I tried to fix it, it was not really well tested, but here the patch that works for me :

diff --git a/functions/icons.zsh b/functions/icons.zsh
index d8661e6..6300d64 100755
--- a/functions/icons.zsh
+++ b/functions/icons.zsh
@@ -13,6 +13,7 @@

 # Initialize the icon list according to the user's `POWERLEVEL9K_MODE`.
 typeset -gAH icons
+() {
 case $POWERLEVEL9K_MODE in
   'flat'|'awesome-patched')
     # Awesome-Patched Font required! See:
@@ -528,6 +529,7 @@ esac
 if [[ "$POWERLEVEL9K_HIDE_BRANCH_ICON" == true ]]; then
     icons[VCS_BRANCH_ICON]=''
 fi
+}

 # Safety function for printing icons
 # Prints the named icon, or if that icon is undefined, the string name.

OMG. Just stumbled upon this Issue.

@bhilburn Good point. Not sure what happens, if you set LC_CTYPE to a non-utf8 value.. But this fix should work for all folks that use utf8 with a different locale.

Good catch @wengole ! Could any of you provide a fix for that? I could have sworn that we already had a fix for that, but obviously (d9374412e6841828c226b3529e0483d1a9aa65e9) we never had..
Wrapping the icons in an anonymous function should be sufficient.

@dritter - Happy to hear that you think @wengole's solution will do the job! Additionally, @benjarobin's evidence that wrapping it did indeed worked is great!

@benjarobin - Can you submit a PR with that change against master? :)

@bhilburn I am not an user of powerlevel9k, I was just helping an user of Arch Linux. And since I did not test it well, I prefer not to submit a PR. Sorry.

@benjarobin - Oh! That was very kind of you. Thanks for hopping in!

@dritter - I'm going to take @benjarobin's patch and turn it into a PR.

@bhilburn Let me know if I can help out.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

jpdoria picture jpdoria  路  5Comments

xufab picture xufab  路  4Comments

Who23 picture Who23  路  4Comments

iiison picture iiison  路  3Comments

dritter picture dritter  路  5Comments