Tmux borders display as xq instead of strings?

Question

I'm having trouble getting tmux to display strings for borders. They are created using x and q. This is the debian squeeze server, and the locale is set to en_US UTF8. I also tried to add

# instructs tmux to expect UTF-8 sequences setw -g utf8 on set -g status-utf8 on 

lines .tmux.conf. Nothing is working. I am not sure if this is a locale problem or not. It displays correctly on other servers, but not on debian. I appreciate any advice you could offer! Thank...

Answer 1

There is some inconsistency between your terminal emulator and the terminfo database entry used by tmux (the one indicated by the TERM environment variable when starting / connecting to the tmux server).

---

In VT100 User's Guide, Table 3-9: Special graphic characters , when “special graphic set” is selected, x used to draw “Vertical Panel” and q used to draw “Horizontal Line - Scan 5”.

In terminfo terms, VT100 special graphic characters are available as part of the alternate character set function; see the “Line Graphics” section on the terminfo page (5) .

---

Probably (on your Debian server) an effective terminfo database entry indicates that ACS is available, but your terminal emulator does not actually respond to the specified escape sequences.

The tmux CHANGES file indicates that some terminal emulators (such as Putty) do not follow ACS escape sequences when they are in UTF-8 mode. Thus, tmux 1.4 has a change that always uses UTF-8 characters instead of ACS sequences when the binding client indicates that it can handle UTF-8 (i.e. when attaching, -u was specified or UTF-8 present in LC_ALL, LC_CTYPE or LANG, the utf8 window option is what tmux should be expected from running programs, not what it can send to the connected client).

Debian "squeeze" only includes tmux 1.3 , so your tmux probably does not have the "preferred UTF-8 line display" function (unless it pulls with <source href = "http://backports-master.debian.org/" > backports).

If you cannot fix the terminal emulator or upgrade it to at least tmux 1.4, you can use the tmuxs terminal-overrides parameter to disable ACS-related features so that tmux returns to the ASCII line drawing. In .tmux.conf (on a Debian system):

 set-option -ga terminal-overrides ',*:enacs@:smacs@:rmacs@:acsc@' 

Answer 2

I had the same problem with PuTTY and Windows 8 when connecting to tmux running on a Debian Squeeze machine. Even when setting the encoding on UTF-8 in PuTTY (in the settings in the section "Window"> "Translation"> "Remote character set"), I did not get the correct line drawing.

Setting the remote character set to Use Font Encoding did the trick for me.

Answer 3

Try to set the character set in "UTF-8" and "Use Unicode Code Codes" in the "Window → Translation" window in the putty settings.

Answer 4

I had the same problem with Putty when running tmux on Linux 12.04. Even setting the encoding in UTF-8 to PuTTY (in the settings in the "Window"> "Translation"> "Remote Character Set" section) did not solve the problem.

Running tmux with the -u option did the trick ( tmux -u )

Answer 5

I ran through a gamut of offers, including:

• confirmation of language settings and UTF-8 in PuTTY
• export NCURSES_NO_UT8_ACS = 1
• manually try different fonts and translation options PuTTY

Above did not work. Dialog displays displayed qqqq ... and xxxx with different angle characters.

Changing all the dialog calls to include -ascii lines was an option, but there would be many script changes in it.

The best recommendation was to change the deleted character set to use font encoding.

PuTTY change settings → Window → Translation → Remote character set → Use font encoding

Other PuTTY settings are left by default.

Answer 6

I changed the setting in Putty for the terminal to Latin-1 and this seems to fix the problem.

Answer 7

If you use KiTTY , under the Windows tab → Translation there is a checkbox called "Allow ACS line drawing in UTF". This needs to be checked:

Answer 8

under the windows / putty the font you use should contain the characters to display set the translation to “UTF-8” and “Use Unicode code codes” and the font for “courier-new” and most of these problems go away

Answer 9

For me, the problem was that I forgot to make the locale.conf file when installing this Linux archive. Below in the line the problem is fixed, substitute your language. A reboot was not required for me.

 echo "LANG=en_US.UTF-8" > /etc/locale.conf 

Answer 10

It seems that font selection is a confusing factor here:

• Lucida sans does not display the UTF-8 line, only - + | (Pipe) replacement
• New Bold courier makes horizontal lines but | vertical replacement
• New Normal courier does them all.