Wrong cursor position and folder colors over SSH

[y0ast]

In the screenshot you can see that the cursor is 2 blocks to the left, it messes up autocompletion too. Also the folders have weird colors:

I have no idea what causes this, as locally these problems don't exist and everything works smoothly

Here is a screenshot from a local prompt.

I Remove %B and %b to make the colors work in my solarized scheme. As it is working locally too, this is not the cause of the problem.

[ColinHebert]

Have you tried another prompt?
Did you try to disable some modules to check if it isn't one of them that might be responsible?

[y0ast]

With 'Nicoulaj' the colors in LS are still wrong, the cursor error is fixed.

If I disable 'utility' module colours are turned off, so ls does not show the weird behaviour anymore. This does not explain the weird difference when logged in over SSH.

If I disable git module it is fixed. The icons on the right in the Sorin prompt are gone, which I think are the cause of it. I guess Zsh computes the line width wrong, but I don't know why it only happens over SSH.

Edit: I realized the LS colors are because the "auto" color settings on ubuntu are just not as beautiful as on OSX. I turned it off in general now, that works much better :). Or I could use something like this: https://github.com/seebi/dircolors-solarized. Now just the git problem remains.

[sorin-ionescu]

This seems to be a terminal issue.

[y0ast]

After hours of debugging I found out that LANG wasn't properly set...

export LANG="en_US.UTF-8" solved it.

[sorin-ionescu]

The language should be set by Prezto. Did you install zshenv properly?

[y0ast]

LS output is this:
.zshenv -> /home/joost/dotfiles/zshenv

cat .zshenv shows the correct output. The editor/visual/pager seems correctly set, but LANG not.

[swsnr]

@sorin-ionescu .zshenv attempts to set $LANG from locale, which is pretty much useless.

Without arguments, locale just dumps the “current locale environment” (see locale(1)), which is essentially the contents of $LANG and all $LC_* variables. If $LANG is unset, locale doesn't output anything useful:

$ env | grep '\(LANG\|LC_.*\)'
LANG=de_DE.UTF-8
$ locale
LANG="de_DE.UTF-8"
LC_COLLATE="de_DE.UTF-8"
LC_CTYPE="de_DE.UTF-8"
LC_MESSAGES="de_DE.UTF-8"
LC_MONETARY="de_DE.UTF-8"
LC_NUMERIC="de_DE.UTF-8"
LC_TIME="de_DE.UTF-8"
LC_ALL=
$ unset LANG
$ env | grep '\(LANG\|LC_.*\)'
$ locale
LANG=
LC_COLLATE="C"
LC_CTYPE="C"
LC_MESSAGES="C"
LC_MONETARY="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_ALL=

So whatever this line was conceived for, it definitely does not set $LANG.

You can't set $LANG automatically. The user has to do so manually, in order to choose the proper language and encoding. At best, the locale environment can be passed from the surrounding environment (e.g. Desktop session) to the terminal, but that's the terminal's responsibility. For instance, $LANG is correct inside an OS X Terminal not because Prezto sets it in .zshenv, but because Terminal.app itself exports correct $LANG and $LC_ALL for the Desktop language settings.

[sorin-ionescu]

@lunaryorn locale output is not empty on Mac OS X.

[swsnr]

@sorin-ionescu Now try hard and guess what system that example is from…

locale is empty, if $LANG and $LC_ALL are unset, on every Unix-like system. That's a POSIX requirement:

When locale is invoked without any arguments, it shall summarize the current locale environment for each locale category as determined by the settings of the environment variables defined in XBD Locale.
And OS X—being certified—won't certainly do any different here.

Your locale is probably not empty, because—as I already said—Terminal.app sets the locale environment based on your system settings. In Terminal.app, go to “Preferences“ → “Settings”. Select your profile, select the “Advanced” tab and de-select “Set locale variables at startup” at the bottom. Restart Terminal.app, and type locale. It'll be empty:

$ locale
LANG=
LC_COLLATE="C"
LC_CTYPE="C"
LC_MESSAGES="C"
LC_MONETARY="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_ALL=

[sorin-ionescu]

@lunaryorn, Can you open a new issue with this? Thank you.

[swsnr]

@sorin-ionescu Done, see #398

[fuadsaud]

@y0ast did you change your LSCOLORS?

[y0ast]

My LSCOLORS is: exfxcxdxbxGxDxabagacad

If anyone has a dircolors file that produces the same output, I would love to have it :)

[fuadsaud]

Hmm, same as mine.

This is th output of ls here:

It's using bold colours. It may be related to terminal (I'm using Terminal.app). Anyone guess how I can make it use light colours?

[masterjedy]

I had such problem. It was a terminal problem, switching terminal font to monospace fixed it.
Find out what terminal you currently using, open its settings and switch font to monospace in that settings.