Skip to content
This repository has been archived by the owner on Apr 24, 2020. It is now read-only.

locale being overridden #587

Closed
wengole opened this issue Aug 1, 2017 · 11 comments · Fixed by #1065
Closed

locale being overridden #587

wengole opened this issue Aug 1, 2017 · 11 comments · Fixed by #1065

Comments

@wengole
Copy link

wengole commented Aug 1, 2017

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

@shibumi
Copy link

shibumi commented Aug 1, 2017

I guess that a

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

would fix this issue, am I right?

@wengole
Copy link
Author

wengole commented Aug 2, 2017

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

@lawrencedark
Copy link

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.

@bhilburn
Copy link
Member

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?

@bhilburn bhilburn added the Fonts label Aug 26, 2017
@bhilburn bhilburn self-assigned this Aug 26, 2017
@ASMfreaK
Copy link

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!).

niklas-heer added a commit to niklas-heer/dotfiles that referenced this issue Sep 18, 2018
@benjarobin
Copy link

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.

@dritter
Copy link
Member

dritter commented Nov 5, 2018

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 (d937441) we never had..
Wrapping the icons in an anonymous function should be sufficient.

@bhilburn
Copy link
Member

bhilburn commented Nov 5, 2018

@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 bhilburn added the master label Nov 5, 2018
@benjarobin
Copy link

@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.

@bhilburn
Copy link
Member

bhilburn commented Nov 6, 2018

@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.

@dritter
Copy link
Member

dritter commented Nov 13, 2018

@bhilburn Let me know if I can help out.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants