After updating my distribution with Xfce 4.14, I am unable to copy and paste some characters into xfce4-terminal. For example, I can paste "test" but not "test α".
This is highly frustrating. I would prefer if the unknown character was replaced with a question mark, or anything really. Is there a way around this?
This was answered on SuperUser. Paraphrasing that answer:
Is the locale blank? It must be set to xxx.UTF-8 for the terminals to support non-ASCII characters. To enable Unicode support,
Add a line to /etc/locale.gen en_US.UTF-8 UTF-8
Run locale-gen
Add LANG=en_US.UTF-8 to /etc/locale.conf
Log out and log in again
The following must be set in xfce4-terminal:
preferences -> advanced -> default character encoding = UTF-8
The LANG environment variable in the shell does not matter, for example mine is set to LANG=en_US, but it's still working.
Terminal and iterm2 applications on my Mac don't display Telugu characters properly. The characters get all jumbled up. I see the same issue with other languages like Kannada and Sanskrit. Some characters seem fine but some others are getting jumbled (as if one character is being super-imposed on another).
I set my text-encoding of Terminal to utf-8, did export LC_CTYPE=en_US.UTF-8 as suggested by other answers but nothing seems to work. Here is my locale:
$ locale
LANG="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_CTYPE="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_ALL=
Enabling "double width" setting did not solve the problem either. I also checked "set locale environment variable on startup". That did not work either.
Note that the characters are being displayed properly in other applications like browsers, word processors, etc. So the problem is local to terminal apps like Terminal and iterm2.
This is how the word "Telugu" is being displayed
How come when I change my locale in a Dockerfile using this...:
ENV LANG en_US.UTF-8
ENV LANGUAGE en_US:en
ENV LC_ALL en_US.UTF-8
...so that I can achieve a change in locale from this...
LANG=
LANGUAGE=
LC_CTYPE="POSIX"
LC_NUMERIC="POSIX"
LC_TIME="POSIX"
LC_COLLATE="POSIX"
LC_MONETARY="POSIX"
LC_MESSAGES="POSIX"
LC_PAPER="POSIX"
LC_NAME="POSIX"
LC_ADDRESS="POSIX"
LC_TELEPHONE="POSIX"
LC_MEASUREMENT="POSIX"
LC_IDENTIFICATION="POSIX"
LC_ALL=
..to this..
LANG=en_US.UTF-8
LANGUAGE=en_US:en
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=en_US.UTF-8
Then I get issues, such as this with no commands executing:
root#820760edeb77:/# irb
bash: irb: command not found
But if I take those changes to the locale, and leave them as they are after a rebuilt container, then everything works as expected??:
# ENV LANG en_US.UTF-8
# ENV LANGUAGE en_US:en
# ENV LC_ALL en_US.UTF-8
root#820760edeb77:/# irb
2.3.1 :001 >
I'm not too sure what would be causing this issue, whereby the changed locale inhibits commands from working, but suspect this could just be a side effect of such a change in Locale within the Docker container, and possibly not the real issue?
So I just figured it out, turns out I was using the wrong locale type for Docker, which is related to this issue here.
A small, but critical distinction C vs en_US:
WRONG
ENV LANG en_US.UTF-8
ENV LANGUAGE en_US:en
ENV LC_ALL en_US.UTF-8
RIGHT
ENV LANG C.UTF-8
ENV LANGUAGE C.UTF-8
ENV LC_ALL C.UTF-8
Can anyone tell me why Docker uses C as a locale, vs en_US, or any other?
Now Ruby/irb is successfully working (albeit, with 4 hours of my life lost.....)
I would like install R on my laptop Mac OS X version 10.7.3
I downloaded the last version and I double click on it and it was installed, when i start up I get the following error, I searched in internet but I could not solve the problem, any help would be appreciated
the errors are
During startup - Warning messages:
1: Setting LC_CTYPE failed, using "C"
2: Setting LC_COLLATE failed, using "C"
3: Setting LC_TIME failed, using "C"
4: Setting LC_MESSAGES failed, using "C"
5: Setting LC_PAPER failed, using "C"
[R.app GUI 1.50 (6126) x86_64-apple-darwin9.8.0]
WARNING: You're using a non-UTF8 locale, therefore only ASCII characters will work.
Please read R for Mac OS X FAQ (see Help) section 9 and adjust your system preferences accordingly.
[History restored from /Users/nemo/.Rapp.history]
Open Terminal
Write or paste in: defaults write org.R-project.R force.LANG en_US.UTF-8
Close Terminal (including any RStudio window)
Start R
For someone runs R in a docker environment (under root), try to run R with below command,
LC_ALL=C.UTF-8 R
# instead of just `R`
Setting locales in terminal resolved the issue for me. Open the terminal and
Check if locale settings are missing
> locale
LANG=
LC_COLLATE="C"
LC_CTYPE="UTF-8"
LC_MESSAGES="C"
LC_MONETARY="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_ALL=
Edit ~/.profile or ~/.bashrc
export LANG=en_US.UTF-8
export LC_ALL=en_US.UTF-8
Run . ~/.profile or . ~/.bashrc to read from the file.
Open a new terminal window and check that the locales are properly set
> locale
LANG="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_CTYPE="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_ALL="en_US.UTF-8"
Just open the R(software) and copy and paste
system("defaults write org.R-project.R force.LANG en_US.UTF-8")
Hope this will work fine or use the other method
open(on mac): Utilities/Terminal copy and paste
defaults write org.R-project.R force.LANG en_US.UTF-8
and close both terminal and R and reopen R.
I found slightly different problem running R on through mac terminal, but connecting remotely to an Ubuntu server, which prevented me from successfully installing a library.
The solution I have was finding out what "LANG" variable is used in Ubuntu terminal
Ubuntu > echo $LANG
en_US.TUF-8
I got "en_US.TUF-8" reply from Ubuntu.
In R session, however, I got "UTF-8" as the default value and it complained that LC_TYPEC Setting LC_CTYPE failed, using "C"
R> Sys.getenv("LANG")
"UTF-8"
So, I tried to change this variable in R. It worked.
R> Sys.setenv(LANG="en_US.UTF-8")
I got same issue on Catalina mac. I also installed the R from the source in following diretory.
./Documents/R-4.0.3
Now from the terminal type
ls -a
and open
vim .bash_profile
type
export LANG="en_US.UTF-8"
save with :wq
then type
source .bash_profile
and then open
./Documents/R-4.0.3/bin/R
./Documents/R-4.0.3/bin/Rscript
I always have to run "source /Users/yourComputerName/.bash_profile" before running R scripts.
Tks Ramon Gil Moreno.
Pasting in Terminal and then restarting R Studio did the trick:
write org.rstudio.RStudio force.LANG en_US.UTF-8
Environment:
MAC OS High Sierra 10.13.1 //
RStudio version 3.4.2 (2017-09-28) -- "Short Summer"
Ennio De Leon
On my Mac r is installed in /usr/local/bin/r, add line below in .bash_profile solved the same problem:
alias r="LANG=en_US.UTF-8 LC_ALL=en_US.UTF-8 r"
Okay, so I finally got myself a MacBook Air after 15 years of linux. And before I got it my big concern was UTF-8 support because no matter if I get files sent to me from windows or mac-clients theres always issues with encoding, while on ubuntu I can be sure that all output no matter what program will produce perfect utf-8 encoded data.
And now on my second day (today) with OS X Im tearing my hair of by frustration. Why?
When I open Nano and type some swedish characters like ÅÄÖ in it, it puts out blank characters at the end of the line (which i guess is the other byte in each character)
When I open python and try using swedish characters, it does not output anything at all
When I connect to a Ubuntu server trough SSH I cant type åäö in bash, tough it works in VIM (still trough SSH). And in nano backspace does not work, but if check the box "Delete sends ctrl+H" in the Terminal preferences, backspace starts working in nano but stops working in VIM.
I've tried unchecking all other encodings then UTF-8 in terminal preferences but that does not seem to work either.
I'm sure that every non US-person must have the same issues, so hove do I fix them? I just want full UTF-8 support... :'(
For me, this helped:
I checked locale on my local shell in terminal
$ locale
LANG="cs_CZ.UTF-8"
LC_COLLATE="cs_CZ.UTF-8"
Then connected to any remote host I am using via ssh and edited file /etc/profile as root - at the end I added line:
export LANG=cs_CZ.UTF-8
After next connection it works fine in bash, ls and nano.
Go to Terminal -> Preferences -> Advanced (Tab) go down to International and select Unicode (UTF-8) as Character Encoding.
And tick Set locale environment variables on startup.
Unfortunately, the Preferences dialog is not always very helpful, but by tweaking around you should be able to get everything working.
To be able to type Swedish characters in Terminal, add the following lines to your ~/.inputrc (most likely you must create this file):
set input-meta on
set output-meta on
set convert-meta off
This should do the work both with utf8 and other codings in bash, nano and many other programs. Some programs, like tmux, also depends on the locale. Then, adding for instance export LC_ALL=en_US.UTF-8 to your ~/.profile file should help, but keep in mind that a few (mainly obscure) programs require a standard locale, so if you have trouble running or compiling a program, try going back to LC_ALL=C.
Some references that may be helpful:
http://homepage.mac.com/thgewecke/mlingos9.html#unicode
http://hints.macworld.com/article.php?story=20060825071728278
The following is a summary of what you need to do under OS X Mavericks (10.9). This is all summarized in
http://hints.macworld.com/article.php?story=20060825071728278
Go to Terminal->Preferences->Settings->Advanced.
Under International, make sure the character encoding is set to Unicode (UTF-8).
Also, and this is key: under Emulation, make sure that Escape non-ASCII input with Control-V is unchecked (i.e. is not set).
These two settings fix things for Terminal.
Make sure your locale is set to something that ends in .UTF-8. Type locale and look at the LC_CTYPE line. If it doesn't say something like en_US.UTF-8 (the stuff before the dot might change if you are using a non-US-English locale), then in your Bash .profile or .bashrc in your home directory, add a line like this:
export LC_CTYPE=en_US.UTF-8
This will fix things for command-line programs in general.
Add the following lines to .inputrc in your home directory (create it if necessary):
set meta-flag on
set input-meta on
set output-meta on
set convert-meta off
This makes Bash be eight-bit clean, so it will pass UTF-8 characters in and out without messing with them.
Keep in mind you will have to restart Bash (e.g. close and reopen the Terminal window) to get it to pay attention to all the settings you make in 2 and 3 above.
Short versatile answer (fits to other national languages, even Lithuanian or Russian)
open Terminal
edit .profile in home directory - nano .profile or in Catalina or newer nano .zshenv
add line export LC_ALL=en_US.UTF-8
press Ctrl+x and Y (exit and save)
This solved for me even small country rare national characters. You may need to close and open Terminal to make changes effective.
Also if you like Linux behavior (use lot of Alt shortcuts like Alt+. or Alt+, in mc) then you should disable Mac style Option key function:
Terminal->Preferences->Profiles->Keyboard and check box:
Use Option as Meta key
To make nano work as you want it to, try:
export LANG="UTF-8"
Or get a newer version of nano via MacPorts:
# cf. http://www.macports.org/install.php
port info nano
port variants nano
sudo port install nano +utf8 +color +no_wrap
With respect to ssh & UTF-8 issues comment out SendEnv LANG LC_* in /etc/ssh_config.
See: Terminal in OS X Lion: can't write åäö on remote machine
My terminal was just acting silly, not printing out åäö. I found (and set) this setting:
Under Terminal -> Preferences... -> Profiles -> Advanced.
Seems to have fixed my problem.
Check whether nano was actually built with UTF-8 support, using nano --version. Here it is on Cygwin:
nano --version
GNU nano version 2.2.5 (compiled 21:04:20, Nov 3 2010)
(C) 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007,
2008, 2009 Free Software Foundation, Inc.
Email: nano#nano-editor.org Web: http://www.nano-editor.org/
Compiled options: --enable-color --enable-extra --enable-multibuffer
--enable-nanorc --enable-utf8
Note the last bit.
Since nano is a terminal application. I guess it's more a terminal problem than a nano problem.
I met similar problems at OS X (I cannot input and view the Chinese characters at terminal).
I tried tweaking the system setting through OS X UI whose real effect is change the environment variable LANG.
So finally I just add some stuff into the ~/.bashrc to fix the problem.
# I'm Chinese and I prefer English manual
export LC_COLLATE="zh_CN.UTF-8"
export LC_CTYPE="zh_CN.UTF-8"
export LC_MESSAGES="en_US.UTF-8"
export LC_MONETARY="zh_CN.UTF-8"
export LC_NUMERIC="zh_CN.UTF-8"
export LC_TIME="zh_CN.UTF-8"
BTW, don't set LC_ALL which will override all the other LC_* settings.
Try
Having a Powerline compatible font installed https://github.com/powerline/fonts
Setting these ENV vars in .zshrc or .bashrc:
LANG="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_CTYPE="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_ALL="en_US.UTF-8"
Just add a file on remote server
$ sudo nano /etc/environment
LANG=en_US.utf-8
LC_ALL=en_US.utf-8
PS: Top answer has a suggestion to change /etc/profile file on remote server, it works, but this file is often overwritten by system, and doesn't help for long.
/etc/profile file contains disclaimer:
It's NOT a good idea to change this file unless you know what you are doing. It's much better to create a custom.sh shell script in /etc/profile.d/ to make custom changes to your environment, as this will prevent the need for merging in future updates.
In my case, simply using the uxterm command instead of xterm solved the problem. It's available in /opt/X11/bin/uxterm by installing the XQuartz package provided by Apple.