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.
Related
I use the Simba ODBC driver (2.3.2) to connect Stata to BigQuery from my macOS laptop. I recently upgraded to Big Sur (11.2.1) and lost the ability to do this.
I am using iODBC and I am able to test the DSN successfully. I was also able to get everything to work in macOS 10.15.7 just fine (on a different machine).
The problem appears to be that Stata is not seeing the DYLD_LIBRARY_PATH environment variable that I have defined in my .bash_profile profile according to the driver configuration instructions.
In Stata, I get this error:
. odbc list
The ODBC file libiodbc.dylib could not be found on this system.
Setting the unix LD_LIBRARY_PATH environment variable may correct this error.
r(680);
I am able to set this in bash:
$ echo $DYLD_LIBRARY_PATH
:/usr/lib/:/usr/local/
But that does not seem to work since:
$ printenv | grep 'DYLD'
is empty. I suspect something in Big Sur is preventing this environment variable from being set.
Happy to try anything to fix this.
To fix this, you need to disable SIP, which keeps the $DYLD_LIBRARY_PATH environment variable from being defined without issuing a warning.
To disable SIP:
Restart your computer in Recovery mode by holding down Command(⌘)-R once it powers off. Press that until you see the Apple icon and a progress bar.
From the Utilities menu, select Terminal.
At the prompt, type the following command and then press return: csrutil disable
Terminal should display a message that SIP was disabled.
From the Apple menu, select Restart.
Now you need to define an environment variable that points to the folder with libiodbc.dylib. To figure out where that folder is, type this in Terminal:
find / -name libiodbc.dylib 2>&1 | grep -v "find: "
Using your favorite text editor (like pico, emacs, or vi), you need to edit your .zshenv file. Open this file (or create it if it does not exist) with
pico ~/.zshenv
Using the first folder from above, define an environment variable by typing this in the file:
export DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:<FOLDER-PATH-HERE>
Save and exit the text editor.
To apply the changes to the current shell, type source .zshenv.
This should make Stata and BQ play nice again.
zsh is the default shell starting with Catalina, so if you use another shell, you should modify things accordingly. I use bash myself, but I hope my translation for zsh works.
You may need to start Stata from the command line for this to fully work.
Here's the output of the command after the fix above:
I got this to work on Apple Silicon/ Monterey. At some point Apple rolled out SIP (https://support.apple.com/en-us/HT204899) and the env variable LD_LIBRARY_PATH is no longer accessible, so STATA is unable to find the .dylib file.
Instead of disabling SIP, which is strongly discouraged by Apple, load STATA from the command line and set LD_LIBRARY_PATH in the same command.
Something like this (your paths and STATA version may vary)
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/homebrew/lib/ && \
/Applications/Stata/StataIC.app/Contents/MacOS/StataIC &
For some reason, wget has started printing all of its messages in Russian, but only when run from within PyCharm's terminal. Why is this happening and how can I change it back to English?
I am on OSX 10.13, and am using wget 1.19.4_1 installed using Homebrew. I have used wget on this computer before, and the text was in English. I cannot understand Russian, so nothing on this computer has ever been set to use Russian.
When I run ...$ locale, this is the result:
LANG=
LC_COLLATE="C"
LC_CTYPE="en_US.UTF-8"
LC_MESSAGES="C"
LC_MONETARY="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_ALL=
Here's what I've found so far
This only happens for terminals in JetBrains IDEs -- I have tried both PyCharm and JGrasp, and they are both affected. When run in the OSX Terminal app, wget outputs English text. It would still be nice to know why this is happening and how to fix it.
This problem seems to affect only wget
Reinstalling wget using brew does not seem to have any effect.
There is no en_US locale in /usr/local/Cellar/wget/1.19.4_1/share/locale/, but I do not know if this could be the cause of my problem.
Copying .../en_GB/ (where ... is wget's locale folder) into a new folder called .../en_US/ does not get rid of the Russian text. Nor does replacing .../ru/ with .../en_GB/. I'm not sure exactly how a locale is defined, so this may or may not mean anything.
This just happened to me, except in french.
My fix: force in the lang values in the terminal
export LC_ALL=en_US.UTF-8
export LANG=en_US.UTF-8
This has wget happy; I've added them to ~/.profile now to see if it keeps them away forever.
jGRASP is using a pty to connect to external programs, and some other IDEs are probably doing the same. So it's possible that new ptys created the way these IDEs are doing it are defaulting to the wrong locale.
From jGRASP or another IDE you can compile and run a Java or C program to print the default locale to verify this. For Java it is java.util.Locale.getDefault() .
The source for the jGRASP pty connection is in .../jGRASP.app/Contents/Resources/jgrasp/src/wedge.c . You can see how the pty is created there. You can also modify and recompile to .../jgrasp/jbin/osx_run if it will help to trace down the problem. Compiling on OS X requires no special parameters, just: cc -o ../jbin/osx_run wedge.c .
I'm running zsh with oh-my-zsh on OS X. Every time I use zsh's awesome tab-completion, formatting on the current command line prompt gets really screwed up. For example:
I'll be typing cd fo and try to tab-complete for the 'foo' directory; zsh prompts for completion but changes the command line to cd fo cd fo while it's waiting for me to complete. It's not a big deal but very annoying. Any suggestions?
I had the same issue on PopOS and Arch linux. I tried a bunch of solutions from various places but the only solution that worked for me was this suggestion by romkatv on an issue on the oh-my-zsh github repository.
The solution is to make a copy of the .zsh-theme file of whatever theme you're using in oh-my-zsh and surround all non-ASCII characters (like emojis) with %{%G<CHARACTER>%}
For example, the default oh-my-zsh theme robbyrussel contains 2 non-ASCII characters. The '➜' character in the prompt
PROMPT="%(?:%{$fg_bold[green]%}➜ :%{$fg_bold[red]%}➜ )"
and the '✗' character in the prompt for git directories
ZSH_THEME_GIT_PROMPT_DIRTY="%{$fg[blue]%}) %{$fg[yellow]%}✗"
Using %{%G<character>%} around the 2 non-ASCII characters like this
PROMPT="%(?:%{$fg_bold[green]%}%{%G➜%} :%{$fg_bold[red]%}%{%G➜%} )"
and this
ZSH_THEME_GIT_PROMPT_DIRTY="%{$fg[blue]%}) %{$fg[yellow]%}%{%G✗%}"
solved the issue for me.
I have faced the same problem before, my solution was disabling some zsh plugins. The second probability is that your colour theme may contain a bug which causing this.
# Custom plugins may be added to ~/.oh-my-zsh/custom/plugins/
# Example format: plugins=(rails git textmate ruby lighthouse)
plugins=(git)
This is the final version of my plugin section in the ~/.zshrc file. Any other plugin between parenthesis may be the reason of your situation.
If your problem still continues you need to post your ~/.zshrc to let us check what is in there.
I had the same issue. Interestingly, I saw the problem only iterm2 while the prompt is correctly displayed in the standard terminal of OS X (after reverse-i-search/tab-completion). The reason seems to be that iterm2 defaults to Unicode (UTF-8) default encoding, which however is not correctly interpreted if the corresponding language variable is not set in the shell.
Solution: add the following to your .zshrc
export LC_ALL=en_US.UTF-8
The prompts will be displayed correctly.
I'm on OS X Mountain Lion, running the included ZSH shell (4.3.11) with Oh-My-ZSH installed over the top.
When using tab completion with commands such as homebrew, when ZSH lists the available commands, it is also duplicating the command. For example:
$ brew {tab}
will result in:
$ brew brew
[list of homebrew commands]
I'm unsure what is causing this error, as when I resize the terminal window, the first instance of the command name disappears.
If I hit backspace when the duplicates are displayed, I can only delete the second instance of the command, zsh won't let me backspace any further. Also, if I do remove the duplicate with backspace, zsh then acts as if there is no command typed at all.
My .zshrc along with all my other .configuration files can be found at https://github.com/daviesjamie/dotfiles
UPDATE: I found this post about someone having the same problem on Ubuntu. However, I don't understand the given solution, and I'm not even sure if it applies to my set up?
This effect also could be reproduced if you use any of fancy UTF-8 characters like arrow, "git branch" character and so on.
Just remove this chars from prompt and duplication will not occur.
Also adding
export LC_ALL=en_US.UTF-8
export LANG=en_US.UTF-8
to ~/.profile can help
The problem is likely to arise from misplaced %{ %} brackets that tell zsh that text inside has zero width. The only things that should be enclosed in them are escape sequences that change color or boldness of the text. If you are using new zsh (>=4.3.{unknown version}) I would even suggest to use %F{color}...%f, %K{color}...%k, %B...%b instead of %{${fg[green]}%} or what you have there.
The problem with them is that there is no way to query the terminal with a question like “Hey, I outputted some text. Where is the cursor now?” and zsh has to compute the length of its prompt by itself. When you type some text and ask zsh to complete zsh will say terminal to move cursor to specific location and type completed cmdline there. With misplaced %{%} brackets this specific location is wrong.
If you use iTerm on Mac, be sure to check "Set locale variables automatically" in your profile preferences. I had it unchecked for an SSH connection and it resulted in the same bug and I fixed it by leaving that option checked.
It's an old thread but I faced similar issue in my zsh setup with oh-my-zsh configuration.
Setting export LC_ALL=en_US.UTF-8 fixed the issue.
A lot of answers in a lot of places suggest the export LC_ALL=en_US.UTF-8 solution. This, however did not work for me. I continued to have this issue using oh-my-zsh on both Arch linux and PopOS.
The only solution that worked for me was this suggestion by romkatv on an issue on the oh-my-zsh github repository.
It turns out, at least in my case, that the autocomplete duplication issue would only show up if there was a non-ASCII character somewhere on the line (like an emoji). And ZSH would incorrectly assume that this non-ASCII character needs to take up 2 character spaces instead of 1.
So the solution that worked was to open up the .zsh-theme file of whatever theme you're using, find all non-ASCII characters and use %{%G%} to tell ZSH to only use one character width for that character
For example, the default oh-my-zsh theme robbyrussel contains 2 non-ASCII characters. The '➜' character in the prompt
PROMPT="%(?:%{$fg_bold[green]%}➜ :%{$fg_bold[red]%}➜ )"
and the '✗' character in the prompt for git directories
ZSH_THEME_GIT_PROMPT_DIRTY="%{$fg[blue]%}) %{$fg[yellow]%}✗"
Using %{%G<character>%} around the 2 non-ASCII characters like this
PROMPT="%(?:%{$fg_bold[green]%}%{%G➜%} :%{$fg_bold[red]%}%{%G➜%} )"
and this
ZSH_THEME_GIT_PROMPT_DIRTY="%{$fg[blue]%}) %{$fg[yellow]%}%{%G✗%}"
is what finally fixed the issue for me.
So all you need to do is make a copy of the theme file you want to use and edit all the non-ASCII characters as shown above and you should hopefully never see the duplication issue again.
My solution to make both local and ssh work is something like a combination of #Marc's and #neotohin's answers:
Set export LANG=en_US.UTF-8 (simply uncomment that part in the template .zshrc; exporting LC_ALL, as in #neotohin's answer, instead of LANG may also work, I didn't try)
Uncheck "Set locale environment variables on startup" in the Terminal profile's "Advanced" section (reason: that setting sets LC_CTYPE=UTF-8 instead of en_US.UTF-8, which brakes the locale for me in ssh)
When using the terminal in emacs (M-x term) under MacOS for some reason it always posts the characters 4m before every line in zsh and always prints 2 lines containing the user info such as
4m--(jesus#laptop:/dir)----
4m--(jesus#laptop:/dir)----
prompt>
It's more of an annoyance than anything but I was just wondering if there's a way to fix this. I also seem to have issues in Zsh in Mac OS emacs terminal mode when a lot of output is written to it it seems to reduce it all to one line and constantly overwrite the same line (may be related as the 4m is possibly just a special character that emacs is treating differently which can affect formatting).
If need be I can post my .zshrc and .emacs files.
You don't have eterm-color terminfo.
First, you try to add following S-exp in your configuration file and evaluate.
;; Use Emacs terminfo, not system terminfo
(setq system-uses-terminfo nil)
If problem is not resolved previous setting, you should create eterm-color terminfo
by using following command. (terminfo path may different from your system)
# If you use Cocoa Emacs or Carbon Emacs
tic -o ~/.terminfo /Applications/Emacs.app/Contents/Resources/etc/e/eterm-color.ti
I needed to set the following environment variables in my ~/.zshrc
export LANG=en_US.UTF-8
export LC_ALL=en_US.UTF-8
export TERM=xterm-256color
This installed eterm-color.ti for me on OSX Mavericks 10.9.5:
Upload eterm-color.ti to /tmp on the remote OSX server.
Run the command sudo tic -o /usr/share/terminfo /tmp/eterm-color.ti on the server.
In my case, this put a file eterm-color in the directory /usr/share/terminfo/65/