Context
GNU bash 4.4.12(1)-release
Powerline 2.5.2-1
Powerline installed from arch linux packages, not from pip.
PS1 Script
update-ps() {
export PS1="$(powerline shell aboveleft)"
export PS2="$(powerline shell left)"
}
export PROMPT_COMMAND="update-ps;$PROMPT_COMMAND"
Powerline config
config.json
colors.json
colorschemes/shell/default.json
themes/shell/default.json
Problem
I have the same problem as him, when I write a few chars the line wraps and I start writing in the same line, overwriting what I already wrote (including ps1).
I am aware that this could be a non-printable character problem, but doesn't it means that it's a powerline bug? What other problems can it be?
For me changing in ~.bashrc:
from:
. /usr/local/lib/python2.7/dist-packages/powerline/bindings/shell/powerline.sh
to
. /usr/local/lib/python2.7/dist-packages/powerline/bindings/bash/powerline.sh
resolved the issue
This can occur when the locale is incorrect, or when glibc is built with "C" locale, which does not support unicode characters. Powerline uses non-breaking spaces (2-byte) and also uses 2-byte unicode characters for the triangles. For each one of these characters, the shell (not powerline) thinks that 1 extra character has been printed. If you have 5 spaces and 3 triangles in the prompt, then the prompt will wrap 8 characters before it hits the end of the line. From there everything behaves incorrectly. This only relates to Powerline in the sense that Powerline uses unicode characters in the prompt.
The fix is to correct the locale so the shell understands 2-byte unicode. You can run "locale" to see if the shell is using "C", in which case it needs to be fixed. For my application, we were running Powerline in a Docker image running Centos Linux. We had to fix the locale in /etc/yum.conf to use the lowercase form of utf8 like so:
sed -i 's/UTF-8/utf8/' /etc/yum.conf
Then rebuild glibc-common with the fix:
yum reinstall glibc-common
After that, new terminals behaved and the prompt wrapped correctly. We then modified our Docker image to fix yum.conf before installing glibc. However, we found one of our modules was changing the locale back to C (LANG="C"), so we used the LC_ALL env var to override it:
LC_ALL=en_US.UTF_8
After that, all new terminals behaved correctly.
Related
I ran up an Ubuntu 12.04 Vagrant instance on OSX (iterm2) and am having trouble with Vim's NERDTree plugin. Seeing these garbage characters in and out of tmux. Tried setting various "term" variables on bash and in vim, but no effect.
It looks like your terminal cannot properly display the Unicode characters (▾▸) that NERD_Tree uses for the tree. As a workaround (unless you can configure your terminal to properly show those), you can revert to ASCII-style characters:
let g:NERDTreeDirArrows = 0
You should ensure the LC_ALL environment variable is configured to use UTF-8:
export LC_ALL=en_US.UTF-8
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)
I can't get certain characters, like ’ and ‘, to display properly in vim. They show up like <?>#~X. They work fine on SnowLeopard, but not on Ubuntu 10.10. The vim config is mirrored on the two systems, and contains:
set fileencoding=utf-8
set encoding=utf-8
set termencoding=utf-8
The ’ ‘ signs work in my terminal on ubuntu. Vim on ubuntu is version 7.3 p112, Vim on osx is 7.2 p108.
Any suggestions?
Am I missing anything in my config?
tx,
-aktiv
I have tried an unchanged vim on Ubuntu 10.04 and both of ticks are displayed as expected. The version I have tried was 7.2.330. If it helps, I can try 10.10 later, too.
Some remarks to track the problem down:
Debian/Ubuntu is completely UTF-8 based/aware for some time now. So there is no need to set it on your own, but it should not hurt, too.
For example the back tick (`) is an ASCII character and should "always" be available. It is an important character, e.g. for Shell or Perl programming.
So I do not expect that you are missing something in your configuration. Quite the opposite:
Perhaps you have added something in your configuration that treats the back tick special, e.g. tries to change the color or something like that.
So I would like to suggest, that you remove your custom configuration from the system and tries if the ticks and other characters are working. If this is the case you can add some of the configurations again. At some point the ticks should stop working. Then you have a small number of customizations that make these ugly characters.
Recently, I switched from Visual Studio to Eclipse CDT. I've set it up beautifully such that the G++ compiler from my Cygwin installation can locate and compile my code without ado.
There is a minor grievance, however. Each time G++ reports a warning or error, the curly single quotes ‘ and ’ appear as ‘ respectively ’. It seems like a character encoding problem; G++ or Cygwin is spitting out a character encoding that either CDT or Eclipse doesn't like.
This is only relevant Google result I could find, but setting the C++ environment variable LANG in Eclipse's preferences to C.UTF-8 or en_US.UTF-8 has no effect.
Running C++ from Cygwin directly reveals the curly single quotes. Is there any way of disabling these altogether? Is there some environment variable I can set or an argument I can pass?
In images
Eclipse shows hieroglyphs in various places:
Cygwin shows the correct symbols (ignore the fatal error):
Yep, you either have to get Eclipse to display UTF-8, or to stop Cygwin gcc from using it. I don't know how to do the former, but you can do the latter by making sure that gcc is run with something like LANG=en_US.ISO-8859-1.
According to gcc 4.0 release notes http://gcc.gnu.org/gcc-4.0/changes.html:
English-language diagnostic messages will now use Unicode quotation marks in UTF-8 locales. (Non-English messages already used the quotes appropriate for the language in previous releases.) If your terminal does not support UTF-8 but you are using a UTF-8 locale (such locales are the default on many GNU/Linux systems) then you should set LC_CTYPE=C in the environment to disable that locale. Programs that parse diagnostics and expect plain ASCII English-language messages should set LC_ALL=C. See Markus Kuhn's explanation of Unicode quotation marks for more information.
It worked for me too. The environment variable need to be set in the Eclipse preferences window under C/C++/Build/Environment. You need to add a new variable by clicking on the Add button. The variable name should be set to LANG and the value to en_US.ISO-8859-1. Does anyone know what is the cause of the problem? Cygwin, Eclipse, gcc???
Answer 2 worked best for me when using gcc in a cygwin rxvt terminal.
Within my .bash_profile added:
# Disable unicode quotation marks for gcc
export LC_CTYPE=C