I have a ARM based machine with ubuntu distro on it and it often feeds me with this while running various commands:
Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LANG = "pl_PL.UTF-8"
This is output of the locale command
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=pl_PL.UTF-8
LC_CTYPE="pl_PL.UTF-8"
LC_NUMERIC="pl_PL.UTF-8"
LC_TIME="pl_PL.UTF-8"
LC_COLLATE="pl_PL.UTF-8"
LC_MONETARY="pl_PL.UTF-8"
LC_MESSAGES="pl_PL.UTF-8"
LC_PAPER="pl_PL.UTF-8"
LC_NAME="pl_PL.UTF-8"
LC_ADDRESS="pl_PL.UTF-8"
LC_TELEPHONE="pl_PL.UTF-8"
LC_MEASUREMENT="pl_PL.UTF-8"
LC_IDENTIFICATION="pl_PL.UTF-8"
LC_ALL=
What should I do to stop it from popping now and then and configure it properly for the ąęśćźńół [important characters of mine]?
OK, I found it
In some ubuntu distros on non 32bit x86 architectures it is misconfigured.
I needed to
sudo apt-get install language-pack-pl
or
sudo apt-get install --reinstall language-pack-pl if already installed
pl is the language code. Change to Yours.
and then
cd /usr/lib/locale
sudo ln -s pl_PL.utf8 pl_PL
and it's fixed
Of course installing the needed locales (sudo dpkg-reconfigure locales) is the best option, if you can.
But I do disable them sometimes, like follows:
unset $(locale|cut -d= -f1)
Try:
sudo dpkg-reconfigure locales
And select locales which You want use.
Next select default and finish.
Related
I am using linuxbrew to install node. That works well, unless, for the fact that I can only use node after I do the following path export.
export PATH="/home/ericel/.linuxbrew/bin:$PATH"
If I close that terminal and open a new terminal, I will still have to do the same PATh export in order to get my node working.
Is there anyway to fix this permanently?
I do brew doctor, I get the following instructions:
ericel#ericel-X401A:~$ brew doctor
Please note that these warnings are just used to help the Homebrew maintainers
with debugging if you file an issue. If everything you use Homebrew for is
working fine: please don't worry and just ignore them. Thanks!
Warning: /usr/bin occurs before /home/ericel/.linuxbrew/bin
This means that system-provided programs will be used instead of those
provided by Homebrew. The following tools exist at both paths:
xzmore
unlzma
lzcmp
brew
xzegrep
lzgrep
lzdiff
lzless
lzma
pkg-config
xzfgrep
xzdiff
xz
lzfgrep
lzcat
lzegrep
unxz
xzgrep
xzcat
xzless
lzmore
lzmainfo
xzcmp
Consider setting your PATH so that /home/ericel/.linuxbrew/bin
occurs before /usr/bin. Here is a one-liner:
echo 'export PATH="/home/ericel/.linuxbrew/bin:$PATH"' >> ~/.bash_profile
Warning: Homebrew's bin was not found in your PATH.
Consider setting the PATH for example like so
echo 'export PATH="/home/ericel/.linuxbrew/bin:$PATH"' >> ~/.bash_profile
Warning: You have a non-Homebrew 'pkg-config' in your PATH:
/usr/bin/pkg-config
`./configure` may have problems finding brew-installed packages using
this other pkg-config.
Warning: Homebrew's share was not found in your XDG_DATA_DIRS but you have
this variable set to include other locations.
Some programs like `vapigen` may not work correctly.
Consider setting the XDG_DATA_DIRS for example like so
echo 'export XDG_DATA_DIRS="/home/ericel/.linuxbrew/share:$XDG_DATA_DIRS"' >> ~/.bash_profile
But even after doing that, node will work just for that one terminal. I am using ubuntu 16.**
Just had the same error. I think it was, because I installed linuxbrew at first from official page instructions and then i used apt-get.
So I removed the apt-get installation
sudo apt remove linuxbrew-wrapper
and then just added the path to
nano ~/.bashrc
as written in official documentation
echo 'export PATH="$HOME/.linuxbrew/bin:$PATH"' >>~/.bash_profile
then you need to open new terminal for it to take effect.
I am having issue when creating a cookbook, like shown below:
What could this be related to? I have the chef-dk installed. I am new to chef, so please do not hesitate if you need more information about my environment.
root#chef-work:/home/ubuntu/chef-repo/cookbooks# chef generate cookbook learn_chef_apache2
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LC_PAPER = "nb_NO.UTF-8",
LANG = "en_US.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
Can't open generate: No such file or directory.
Can't open cookbook: No such file or directory.
Can't open learn_chef_apache2: No such file or directory.
Check your $PATH, type -a chef. I'm guessing you have multiple chef executables installed, and the one from ChefDK is not first. You can move the chef shell-init to the bottom of your shellrc file.
I just bought a VPS and I'm playing it it using SSH.
After a few software packages installations I saw that I had a problem with locales (I need to have en_US.UTF-8 but I have Latin1. I googled it but even after I think I've changed locales then they keep returning to the original ones and I still get problems with software installation.
So, I get:
root#myname:~# locale
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=pt_PT.UTF-8
LANGUAGE=
LC_CTYPE="pt_PT.UTF-8"
LC_NUMERIC="pt_PT.UTF-8"
LC_TIME="pt_PT.UTF-8"
LC_COLLATE="pt_PT.UTF-8"
LC_MONETARY="pt_PT.UTF-8"
LC_MESSAGES="pt_PT.UTF-8"
LC_PAPER="pt_PT.UTF-8"
LC_NAME="pt_PT.UTF-8"
LC_ADDRESS="pt_PT.UTF-8"
LC_TELEPHONE="pt_PT.UTF-8"
LC_MEASUREMENT="pt_PT.UTF-8"
LC_IDENTIFICATION="pt_PT.UTF-8"
LC_ALL=
But before, I have done:
locale-gen en_US.UTF-8
export LANG=en_US.UTF-8
export LANGUAGE=en_US:en
export LS_ALL=en_US.UTF-8
So, I can I solve this forever?
PS: I'm doing all this using SSH.
That's because my locale in my local machine is set to Portuguese, which SSH forwards to and tries to use on the server, but the server does not have it installed.
I could have stopped forwarding the locale environment variable from my local machine to the server. To do that I would have commented the SendEnv LANG LC_* line in the local /etc/ssh/ssh_config file.
Instead I decided to:
1) Generate the locale - Generate the English locale on the server with sudo locale-gen en_US.UTF-8
2) Stop accepting locale environment variable from my local machine to the server. To do that I commented the AcceptEnv LANG LC_* line in the remote /etc/ssh/sshd_config file. Note that for this I had to install the nano package to edit the file (after sudo apt-get install nano I just did nano filename when I was in the file directory).
3) Set the server locale to English - by adding the following lines to my remote ~/.bashrc or ~/.profile files using nano filename again (don't forget they are hidden files inside your home directory so they won't appear in a simple ls search; you need to use ls -la command):
export LANGUAGE="en"
export LANG="C"
export LC_MESSAGES="C"
export LANG=en_US.UTF-8
export LANGUAGE=en_US:en
export LS_ALL=en_US.UTF-8
I also restarted the VM and before that I closed my SSH session and reenter to see if changes were working.
I'm trying to run rqworker as an attached-daemon in UWSGI. To do this I add to the config.ini file:
attach-daemon = /path/to/rqworker
Then UWSGI tries to launch rqworker when it should but I get the following error in the logs:
RuntimeError: Click will abort further execution because Python 3 was
configured to use ASCII as encoding for the environment. Either switch
to Python 2 or consult http://click.pocoo.org/python3/ for mitigation
steps.
I can run rqworker fine from bash but the encoding seems to be not set correctly for the daemon.
From the linked page in that message:
You are dealing with an environment where Python 3 thinks you are
restricted to ASCII data. The solution to these problems is different
depending on which locale your computer is running in.
For instance, if you have a German Linux machine, you can fix the
problem by exporting the locale to de_DE.utf-8:
export LC_ALL=de_DE.utf-8 export LANG=de_DE.utf-8 If you are on a US
machine, en_US.utf-8 is the encoding of choice. On some newer Linux
systems, you could also try C.UTF-8 as the locale:
export LC_ALL=C.UTF-8 export LANG=C.UTF-8
To set the encoding in the UWSGI config.ini file you can use "env" to set environment variables and in turn the locale. On a US machine this configuration would work:
env = LC_ALL=en_US.utf-8
env = LANG=en_US.utf-8
attach-daemon = /path/to/rqworker
On other machines, various other encodings could be used.
I installed Antergos (easy version of Arch) with the Japanese environment.
But I wanted to chaned the language to English, so I reffer the wiki article then run some commands after uncomment #en_US.UTF-8 UTF-8 in /etc/locale.gen and edit /etc/locale.conf into following:
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=
The problem starts from here.
I restarted my computer and found that gnome-terminal doesn't work.
I substituted eshell on Emacs and run gnome-terminal command, then got error messages:
(process:1202): Gtk-WARNING **: Locale not supported by C library.
Using the fallback 'C' locale.
Error constructing proxy for org.gnome.Terminal:/org/gnome/Terminal/Factory0: Error calling StartServiceByName for org.gnome.Terminal: GDBus.Error:org.freedesktop.DBus.Error.Spawn.ChildExited: Process org.gnome.Terminal exited with status 8
The output of locale command is following:
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC=ja_JP.utf8
LC_TIME=ja_JP.utf8
LC_COLLATE="en_US.UTF-8"
LC_MONETARY=ja_JP.utf8
LC_MESSAGES="en_US.UTF-8"
LC_PAPER=ja_JP.utf8
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT=ja_JP.utf8
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=
What changes some part of locale setting into Japanese? Or other reasons which terminate gnome-terminal exist?
I have tried solutions sugestted here https://bbs.archlinux.org/viewtopic.php?id=180103 .
Thank you.
I had the same problem some time ago. I fixed my locale config running this command
sudo localedef -f UTF-8 -i en_US en_US.UTF-8
The meaning of status code 8 is documented on gnome's website here:
The environment that gnome-terminal-server is started with does not
correctly set the locale to a UTF-8 locale. Consult your
distribution's documentation on how to fix this. Note that is it not
relevant to check the locale settings from a different terminal (e.g.
xterm); what counts is the environment that the session dbus-daemon
passes to the processes it starts.
So you're right, this is probably due to locale settings. I don't quite understand all the details, but if I set ~/.xinitrc to exec gnome-session and then run startx, I get a similar error to yours.
However, if instead of running startx, I start the gdm display manager (via systemctl start gdm.service on Arch), I can spawn a gnome-terminal correctly. So if you're okay with using gdm, that may be a solution. Lightdm also works, though SLiM doesn't (from my experience).
In the past, I also had to install the vte3 package for gnome-terminal to work, so make sure that's installed as well. And FWIW, sudo gnome-terminal seems to always work.
Did you think to regenerate your locales after you had edited your /etc/locale.gen file ?
locale-gen
I think in your explanation you mixed the /etc/locale.gen and the /etc/locale.conf files. Be sure you edited the correct file with the correct values.
Ok this is how I solved it;
sudo locale-gen --purge --no-archive
Then; sudo update-initramfs -u
Nothing with locale worked for me. Once changed back the default python version (3.5 on ubuntu16), terminal worked just fine.