My gnome-terminal is broken, so is zim and many other programs, the xfce-terminal does not show characters like ö ä or ü. All of them show problems with the locale. I think the problems stems from ill-configured locale settings. For typing "locale" the xfce4-terminal prompts
LANG=C
LC_CTYPE="C"
LC_NUMERIC=aa_DJ.UTF-8
LC_TIME=aa_DJ.UTF-8
LC_COLLATE="C"
LC_MONETARY=aa_DJ.UTF-8
LC_MESSAGES="C"
LC_PAPER=aa_DJ.UTF-8
LC_NAME="C"
LC_ADDRESS="C"
LC_TELEPHONE="C"
LC_MEASUREMENT=aa_DJ.UTF-8
LC_IDENTIFICATION="C"
LC_ALL=
This is not what I want. My /etc/locale.conf is set to
LANG=de_DE.UTF-8
My /etc/locale.gen is uncommented such executing "locale-gen" prompts
de_DE.UTF-8... done
de_DE.ISO-8859-1... done
en_US.UTF-8... done
en_US.ISO-8859-1... done
When looking at the environment variables my "locale" produces, it doesn't wonder me too much, that nothing is working as supposed. I don't know why there is "aa_DJ" in these variables, I don't know the language (to be precise, I am not sure which language that is, maybe I speak it ...). However, I really don't know where to change the environment variable permanently (Without putting it in .bashrc) . I tried grepping it in my home folder and after that in root (Recursive on --> grep looked everywhere), but I couldn't find anything.
So my question is: Where or how are these variables defined and how can I change them? I can't find anything that explains it to me. I am aware that there are several people asking similar questions, I tried those solutions but they seem to have different problems (or they solve it with hacking something into .bashrc, which doesn't do the trick here and is not a very meaningful way).
So, the locale you have there seems to be:
Afar - DJIBOUTI (DJ) (aa_DJ)
So, after running locale-gen you need to run localectl list-locales and identify the locale you need.
Finally run:
localectl set-locale LANG=de_DE.UTF-8
NOTE: The German page for locale in Arch linux seems to be outdated
As I found out now, I missed to give an information that might have been useful and which helped me to solve the question. I use the gnome3 desktop env. Gnome3 has its own setting for the locales that overwrites the system standard (and is not saved in plain text I assume, otherwise I should have found it with grep). The solution was to correct the gnome setting via
gsettings get org.gnome.system.locale region 'de_DE.UTF-8'
Related
I became very interested in Linux and wanted to customize my terminal with ZSH and powerlevel10k, but after changing and logging out, the programming tools disappears. I tried very hard to understand the reason but it did not work. I am not very familiar with the $PATH command and I do not know if it works or not. Thanks for your help.
image link => https://i.stack.imgur.com/BLeLe.jpg
Changing default shell to ZSH can help
first find the path of your ZSh shell.
type -a zsh
then change it
chsh -s /bin/zsh
now log out and log in again. One can close the Terminal app and reopen it.
After digging, I finally realized that the files that were installed with SNAP are not displayed. When I installed the file in Deb format, it became known.
I use Sabayon 14.01 Xfce now, and I find a strange problem with the locale.
When open a new xfce-terminal, echo $LANG will output zh_CN.utf8, and command locale will output similar content.
zh_CN.utf8 is a strange locale variable, this leads gVim's menu content empty(in Chinese).
The normal LANG variable should be zh_CN.UTF-8, and gVim work fine with it.
When execute command source /etc/profile, the strange LANG variable return to normal(zh_CN.utf8 -> zh_CN.UTF-8).
But strange LANG variable still survives when login or in a new xfce-terminal.
So, how to set default LANG variable to be the normal one?
-- UPDATE # 2014-01-18 ---
I re-installed Sabayon xfce and found that the UPDATE lead to this problem.
After re-installed, the locale was the right one, zh_CN.utf-8.
After UPDATE, the locale changed to zh_CN.utf8, in Xfce GUI login.
In tty (alt+ctrl + f1), login and locale , the result is the right one.
-- REPLY TO ZermeX --
I have checked that /etc.locale.gen , /etc/env.d/02locale , /etc/profile, ~/.bashrc, ~/.xprofile and so on for times. These are quite fine.
I am certain of this problem caused by the update. lightdm MAYBE the suspect.
verion update of lightdm:
lightdm gtk greeter: 1.3.1-r1 => 1.6.1~0
lightdm base: 1.4.0 => 1.8.5-r1~0
I also found a quite similar bug been reported to debian: Debian Bug report logs - #735251 lightdm: user locale tweaks are clobbered by non-default locale .But the version of lightdm is higher.
Please run eselect locale list and verify that the correct locale is set.
Also check your ~/.bashrc (or whatever shell you use) if you accidentally overwrite the LANG from /etc/profile in your settings.
-- Reply to UPDATE # 2014-01-18 --
For further help i would like to see the output of the following commands
eselect locale list
cat /etc/locale.gen
cat /etc/env.d/02locale
cat /etc/profile
cat ~/.bashrc
Also it would be helpful to know how you start X. Do you use a graphical display manager or do you run the startx command? Depending on what you use it would also be helpful to see the output of cat ~/.xinitrc or cat ~/.xsession and the display managers configuration files.
When I run gvim from MSYS, things go wrong during initialization. Namely, gvim can't find the initialization files that are in 'C:\Documents and Settings\username\vimfiles.
[Specifically, gvim reports the error E117: Unknown function: pathogen#infect during initialization, so it never found autoload\pathogen.vim. Doing :scriptnames also confirms that none of the setup files from vimfiles\ are run.]
I think I've debugged why it goes wrong. When you start MSYS, the MSYS shell inherits the windows enviroment variables, but changes some of them to it's custom values. C:\Documents and Settings\username is the value of $HOME in Windows, but MSYS sets it to something like C:/msys/user name. And of course, Vim uses $HOME to find the right initialization files.
I also notice set shell? has changed to something like shell=C:/msys/bin/sh instead of shell=C:\WINDOWS\system32\cmd.exe, but I hope this isn't important for fixing the initialization problem.
I need to run gvim with the normal windows environment variables. At least I need to be able to manually override a few important ones like $HOME to something I specify (i.e., I'm not concerned about my windows $HOME changing, so it's fine to use a static value).
I tried to reset $HOME manually in my vimrc, but by then it is too late.
Is there some trick to specifying $HOME early on during initialization, or as an extra command line parameter?
Alternatively, is there some trick with running commands from msys differently? I know almost nothing about how the shell C:/msys/bin/sh works, but I could conceive of some extra arguments that changes the visibile environment for the command (e.g. gvim.exe) you are typing.
---Edit---
Reposting the solution that worked (it achieves the later idea):
Instead of running gvim.exe, run the command HOME="C:\Documents and Settings\username" gvim.exe
In bash and other UNIX shells, you can do:
$ HOME='/path/to/dir' gvim
to temporarily set $HOME to a different value.
I admit I'm not familiar at all with the Windows command line, but it might be worth a try.
I believe you can define $HOME just like any other environment variable.
Try adding this to the start of your .vimrc.
let $HOME="C:\Documents and Settings\username"
I had a similar issue when running Cygwin (which is similar to MSYS).
The easiest solution for me was to simply set the HOME environment variable to an empty string. Otherwise, the Cygwin HOME value would be appended to the Windows USERPROFILE in GVim and it would fail to start correctly. Not explicitly setting the full path of the HOME means that I can use the same start-up files on different systems where the USERNAME may not be the same.
Likewise, the SHELL environment variable should not be inherited from Cygwin Bash. This results in errors when running shell or external programs via !. Again, I set this to be an empty variable since Vim is smart enough to figure out what it should be.
In my .bashrc, I set the following alias for running Windows gvim which starts GVim with the HOME and SHELL variables set to an empty string – just for that command.
gvim="/cygdrive/c/Program Files (x86)/Vim/vim74/gvim"
if [ -x "$gvim" ]; then
alias gvim="HOME= SHELL= \"$gvim\""
fi
unset gvim
I achieved this by making a windows symbol link (Win 7 or higher).
Via a symbol link, you can even make vim and gvim to use the same configuration and plugin.
Recently my bash has often got into strange states I don't understand (debian squeeze system). For example, after starting a new xterm, Control-l prints "^L" on my screen instead of cleaning it. This happens with a "fresh" xterm, with bash as well as with dash (even xterm -e /bin/dash). Also, a reset did never help.
By contrast, after ssh'ing to another box, Control-l does what I expect.
Can somebody make an educated guess for the cause to this very odd behaviour to me (my Unix knowledge can't help out)?
Sorry, I found it out. set -o vi was the culprit, as for bash. As for dash, it's just normal behaviour... Been a hard one.
Check the stty -aoutput and the $TERM variable. $TERM should be "xterm" or "xterm-color"
I would like to enable zsh to autocomplete modules for yast2 (an OpenSuSE control panel), but it seems to already have some things defined. I can run
compctl -k "(hello world)" nonexistantprogram
just fine, but
compctl -k "(hello world)" yast2
doesn't work at all. Some things for yast2 seem to be already defined, namely the "-" options: --fullscreen, --geometry, --list [submodules], etc.
Even if for those who don't use OpenSuSE: Are there any flags to compctl to make it override previous settings? Thanks very much in advance.
Most likely, your system is using the newer compsys system rather than the older compctl system. See man zshcompsys and man zshcompwid (and man zshcompctl).
The completion function for yast2 is probably in this file (or similar path):
/usr/share/zsh/functions/Completion/Linux/_yast