Do you have a ~/.profile
file?
A little bit of explanations.
If I put such variable in the ~/.bashrc
file, I’m able to reproduce the issue.
So what I’m looking for is: where on your system such variable is defined?
(And for the records, if I put LANG=en_US.UTF-8
in bashrc, it works normally).
env | grep -i lang
Thanks
oops … face-palm …
Sorry about that.
Sorry for being late, the forum banned me from replying for 16 hours
The LANG=en_US.UTF-8
is in a file called locale.conf
, the path of the file is : /etc/locale.conf
Mmm no
The problem is that LANG variable is not en_US.UTF-8 but only en_US
Alright! some progress!
The terminal now gives this error if I tried to run it normally:
$ gnome-terminal -v
# Warning: DESKTOP_STARTUP_ID not set and no fallback available.
# Error creating terminal: Could not activate remote peer: startup job failed.
But it works if I used sudo
EDIT:
When I restart the DE the variables resets to en_US, is there is a way to prevent this?

variables resets to en_US
Indeed this is what I was looking for: where such variable is defined?
localectl
looks good. LANG is not in bashrc, bash_profile nor /etc/profiles

Do you have a
~/.profile
file?
Or is it defined in a file under /etc/profile.d?
Otherwise I’m out of ideas.

Otherwise I’m out of ideas.
How to track changes in environment variables? has no answer after 256 views.
It is too often difficult to track down the source of some random bad setting in the environment.
Setting the LANG
to “read-only” in /etc/locale.conf
by adding the line typeset -r LANG
might be informative but may break things: Set read-only environment varable . In the worst case you might have to boot a live USB to revert the read-ony setting.
It looks like it is set in,
etc/profile.d/lang.sh
so maybe try:
env -i bash --noprofile --norc
env
verify nothing is set.
source /etc/profile.d/lang.sh
env
See if the variable is set to the wrong value?
Actually on my system I see /etc/locale.conf contains
$ cat /etc/locale.conf
LANG="en_US.UTF-8"
and it seems that /etc/profile.d/lang.sh simply makes changes based on that value but does not actually export the value it sets.
I don’t yet know what actually gets the value from locale.conf and sets it into the environment. I do see that
$ 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=
shows all those that are set.
It is set here from reading the value in the locale.conf:
for config in /etc/locale.conf "${HOME}/.i18n"; do
if [ -f "${config}" ]; then
# NOTE: We are using eval & sed here to avoid invoking of any commands & functions from those files.
if [ -x /usr/bin/sed ]; then
eval $(/usr/bin/sed -r -e 's/^[[:blank:]]*([[:upper:]_]+)=([[:print:][:digit:]\._-]+|"[[:print:][:digit:]\._-]+")/export \1=\2/;t;d' ${config})
else
#but if we don't have sed, let's go old way and source it
[ -f "${config}" ] && . "${config}"
fi
fi
done

I don’t yet know what actually gets the value from locale.conf and sets it into the environment. I do see that
From man locale.conf
LOCALE.CONF(5) locale.conf LOCALE.CONF(5)
NAME
locale.conf - Configuration file for locale settings
SYNOPSIS
/etc/locale.conf
DESCRIPTION
The /etc/locale.conf file configures system-wide locale settings. It is
read at early boot by systemd(1).
The systemd program also needs the locale settings before the user is logging in.
I don’t have a .profile
file, I only have .bashrc
and .bash_profile

$ 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=
I don’t have the same values here
$ locale
LANG=en_US
LC_CTYPE="en_US"
LC_NUMERIC=en_US.UTF-8
LC_TIME=en_US.UTF-8
LC_COLLATE="en_US"
LC_MONETARY=en_US.UTF-8
LC_MESSAGES=C.UTF-8
LC_PAPER=en_US.UTF-8
LC_NAME="en_US"
LC_ADDRESS="en_US"
LC_TELEPHONE="en_US"
LC_MEASUREMENT=en_US.UTF-8
LC_IDENTIFICATION="en_US"
LC_ALL=
This is my output

The /etc/locale.conf file configures system-wide locale settings. It is read at early boot by systemd
This is the reason why I suspect that some of these variables are somewhere defined in the user session and hence they take precedence over the system defined ones.
When @computersavvy showed his locales, I figured out that the solution is to make my locales similar to his.
@alciregi mentioned the ~/.profile
file but I don’t have one, instead I have the ~/.bash_profile
flle.
So I declared the locales of @computersavvy in the ~/.bash_profile
file.
Some people mentioned that having a ~/.profile
and a ~/.bash_profile
files at the same time is a bad idea, that’s why I didn’t create a ~/.profile
file : bash - What is the difference between .profile and .bash_profile and why don't I have a .profile file on my system? - Unix & Linux Stack Exchange
So I simply edited the ~/.bash_profile
, added the locales and it made gnome terminal work again!
before editing .bash_profile
:
# .bash_profile
# Get the aliases and functions
if [ -f ~/.bashrc ]; then
. ~/.bashrc
fi
# User specific environment and startup programs
After the edit:
# .bash_profile
# Get the aliases and functions
if [ -f ~/.bashrc ]; then
. ~/.bashrc
fi
# User specific environment and startup programs
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=
Glad you found a workaround. Anyway, we didn’t find why the system wide locale set by localectl
(/etc/locale.conf
) was not used, that is where else the LANG variable was defined.
Setting the LOCALE variables in .bashrc hides the underlying problem. You may encounter other cases where the incorrect LANG setting causes problems, and other users may encounter the issue, so it would be helpful to know the root cause.