Midnight commander does not display pseudo-graphic characters properly

Sometimes changing font in terminal emulator helps (if you access Linux via terminal emulator like Putty).

The simplest solution is not to use them. MC has option -a that disables the use of pseudo graphic characters in line drawing. This is a locale and termcap issue that is difficult to understand. One simple trick to try is  to use this:

• LANG=C mc

# locale
LANG=en_US.UTF-8
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=

In case of Teraterm I noticed that this is often a bug that is corrected in subsequent versions. For example the version 4.91 garble pseudographic characters, 5.92 does not. Putty presents its own set of problems.

Selection of font also matters. For Cygwin, Teraterm and Putty you can use Fixedsys 11

Other "good" from this standpoint fonts include but are not limited to HE_TERMINAL, Lucida Console, Terminal and Lucida Sans Type.

NEWS CONTENTS

• 20100921 : Pseudo-graphic border in MC problem ( Pseudo-graphic border in MC problem, Sep 21, 2010 )
• 20100726 : Getting Midnight Commander line drawing to work with PuTTY andremiller.net ( Getting Midnight Commander line drawing to work with PuTTY andremiller.net, Jul 26, 2010 )
• 210210 : mc (Linux Reviews) ( mc (Linux Reviews), )
• 210210 : windows - How to fix PuTTY showing garbled characters ( Server Fault )
• 210210 : #2339 (mc is not using graphical characters when running on osx (ssh connections)) – Midnight Commander ( #2339 (mc is not using graphical characters when running on osx (ssh connections)) – Midnight Commander, )

Old News ;-)

[Sep 21, 2010] Pseudo-graphic border in MC problem

Should be LANG=C; mc That tip helps if you are using teraterm as emulator

gnome.apps.mc.general

> Please, a small question - I made the new installation (FC3, KDE)
> and run MC (the great SW!!). Everything works, except that borders on
> the panels are drawn by 'a umlaut' instead of pseudo-graphic (lines)

This is a locale and termcap issue which I do not fully understand.
Fortunately I do know a workaround. :) Use this:
LANG=C; mc
to start mc.

[Jul 26, 2010] Getting Midnight Commander line drawing to work with PuTTY andremiller.net

When using Midnight Commander with the default settings of PuTTY connected to my Ubuntu Linux machine the line drawing characters are all messed up.

After some experimentation it turns out that to fix it all you have to do is change your character set in PuTTY to UTF-8 and the problem is fixed. To do this open up the PuTTY settings and go to Window->Translation->Received data assumed to be in which character set: and change it to UTF-8.

After making this change you might have to force a redraw of the mc screen to show the new line drawing characters:

Also not that some fonts might not have the line drawing characters available. The fonts I know work is Courier New and Lucida Console. To change your font go to Window->Appearance, Font settings and click the Change button.

For reference, I was using using Midnight Commander 4.6.1 running on Ubuntu 7.10 and using PuTTY 0.59

mc (Linux Reviews)

-a, --stickchars

Disable usage of graphic characters for line drawing.

windows - How to fix PuTTY showing garbled characters

Server Fault

This is not sufficient in all cases. You should also export the following variable to your environment: NCURSES_NO_UTF8_ACS=1 [more info] – Piotr Jurkiewicz Dec 14 '14 at 22:53

#2339 (mc is not using graphical characters when running on osx (ssh connections)) – Midnight Commander

"... Putty does not ​support VT100 line drawing characters in UTF-8 mode. ..."

Changed 6 years ago by sorin

Putty is already configured to use UTF-8 encoding and it has not problems when doing ssh to other platforms, like Ubuntu or CentOS.

I hope the screenshots are ok. I know that I can start mc with mc -a to improve the experience a little bit but it's harder.

comment:4 Changed 6 years ago by zaytsev

The fact that it shows 7-bit ASCII is correct, but it should normally draw the characters anyway.

Can you try running >>> LC_CTYPE="UTF-8" mc <<< in Putty to see if it works? Just curious.

comment:5 Changed 6 years ago by sorin

LC_TYPE is not an environment variable so you cannot change it this way.

Instead I found a way of changing it by doing export LC_ALL=en_US.UTF-8 - see ​http://jonkinney.com/articles/2009/11/23/change-locale-on-os-x-snow-leopard-for-freetds-functionality

This changed all locale and now the mc runs properly.

Now I have an workaround but we we need to find a solution to make this work by default for all users.

Any ideas? I would consider as an acceptable solution even if mc will fallback to the "mc -a" mode when the LC_CTYPE="C".

Also we should remember updating the FAQ regarding this subject.

comment:6 follow-up: ↓ 7 Changed 6 years ago by zaytsev

The point is, that on my platforms, LC_ALL=C mc does draw the borders correctly. Maybe single-byte people such as andrew_b can reproduce this bug.

And, by the way, can you upgrade to the latest version of mc? It might be that this bug is no longer valid.

comment:7 in reply to: ↑ 6 Changed 6 years ago by andrew_b

Replying to zaytsev:

The point is, that on my platforms, LC_ALL=C mc does draw the borders correctly. Maybe single-byte people such as andrew_b can reproduce this bug.

I don't have any OS X installation in my neighbourhood.

comment:8 Changed 6 years ago by sorin

• Version changed from 4.7.0 to 4.7.0.8

I managed to reproduce this bug the other way, by setting the LC_ALL="C" on another machine (linux) and the behavior was the same: bug appeared.

Can you confirm if newer versions of mc do not reproduce the bug when you set LC_ALL="C"?

I did not had enough time to compile mc on OSX due to some problems related to mac-ports.

Instead I compiled latest release (4.7.0.8) on Ubuntu and when I set LC_ALL="C" the bug reproduces.

In this case the real issue is when LC_ALL is set to "C", on all platforms.

comment:9 Changed 6 years ago by zaytsev

I can't reproduce this on Ubuntu Hardy, 4.7.0.8 package from my PPA. Everything is drawn correctly. mc correctly detects it as 7bits ASCII.

zyv@mypride:~/Desktop$ LC_ALL="C" LANG="C" mc

zyv@mypride:~/Desktop$ locale
LANG=C
LC_CTYPE="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_COLLATE="C"
LC_MONETARY="C"
LC_MESSAGES="C"
LC_PAPER="C"
LC_NAME="C"
LC_ADDRESS="C"
LC_TELEPHONE="C"
LC_MEASUREMENT="C"
LC_IDENTIFICATION="C"
LC_ALL=C

Are you still running mc from putty on Ubuntu? What is your echo $TERM? Can you try TERM=xterm mc?

comment:10 Changed 6 years ago by sorin

You are right regarding that mc does switch to 7-bits ASCII.

My terminal is using xterm-color in all cases (putty or Terminal.app), and changing it to xterm or color_xterm does not produce any change in behavior.

But I think we have a different expectations regarding the result: I would expect to see graphical characters or ASCII ones but never characters like "lqxmwv" instead of graphical characters.

I really do not understand why there are *3* modes of displaying the graphical characters. It does make sense to see only two: ASCII (mc -a) and the graphical ones.

On OS X (10.6) the default locale is "C" *but* the console is really using UTF-8. I tested using the Terminal.app and by doing ssh to the same machine. On both cases running cat file_with_utf8_content proved me that the console is fully supporting UTF-8 (the test file contained a wide range on unicode characters).

Considering that the console is already supporting UTF-8 (even if you use LC_ALL=C) probably mc could properly use graphical characters always. If this is not possible for other reasons, like portability, it should use ascii at least.

One thing is sure: the doc/faq is wrong about a the causes of displaying the graphical characters as lowercase Latin letters.

By the way, what kind of platform do you use? Setting LC_ALL=C did reproduce the bug for me on all platforms I tested: centos, ubuntu and osx.

Changed 6 years ago by zaytsev

• Attachment Screenshot.png​ added

comment:11 Changed 6 years ago by zaytsev

You don't seem to understand what I am saying. I am saying that for me it draws the lines correctly using pseudo-graphics even if the locale is set to C (which is exactly what one would expect to see if the terminal correctly supports the whole set of ASCII characters).

Also, you didn't answer my question, whether you always use Putty as a terminal emulator when connecting to these machines or not.

I am running wide range of Ubuntus and CentOSes, all fully UTF-8 enabled with gnome-terminal as the terminal emulator. I can't reproduce your problem.

comment:12 Changed 6 years ago by mwisnicki

• Cc mwisnicki@… added

Same thing happens with mc-4.7.2 on FreeBSD-8.1 when using Putty.

Putty does not ​support VT100 line drawing characters in UTF-8 mode.

You can work around it by forcing ncurses to use Unicode line drawing characters with environment variable NCURSES_NO_UTF8_ACS=1.

I don't know why it does not happen on linux servers.

comment:13 Changed 6 years ago by zaytsev

Wow, dude, you've almost got it. From the manual page:

Specifically, when running in a UTF-8 locale,the Linux console emulator and the GNU screen 
program ignore these.

That's why it doesn't happen on Linux and under screen.

OP, I think you should file a bug against ncurses to ask Thomas to add Putty to the NCURSES_NO_UTF8_ACS blacklist.

Does this happen with slang by the way?

Either way, sounds like it's not an mc bug.

comment:14 Changed 6 years ago by mwisnicki

Linux console emulator (TERM=linux) is used only on system console (i.e. outside of X).
Putty by default pretends to be xterm (TERM=xterm), you can configure putty to set terminal type (Connection\Data\Terminal-type string) of linux but then it's not xterm and you lose mouse and certain key codes.

I don't think there is a way to detect if we are running in putty. It's just putty that's broken, if it wants to pretend to be xterm it should behave like one.

What I don't understand is that when googling for solution I've found many bugs in bug trackers of various linux distributions and while some of them acknowledged the problem and recommended setting NCURSES_NO_UTF8_ACS when using Putty, there were also those where people said that it works for them out of the box.

comment:15 Changed 6 years ago by zaytsev

• Status changed from new to closed
• Resolution set to wontfix

Excellent analysis! Many thanks for your help. Closing as not an mc bug.

comment:18 Changed 6 years ago by mwisnicki

In case someone found this bug when troubleshooting putty:

I've created a modified version of PuTTY with support for ACS linedrawing in UTF-8 (as an option), fixed UTF-8 window titles and more here:

• ​http://github.com/mwisnicki/putty/downloads

BTW supporting ACS is against UTF-8 standard so it's the whole world (various xterms, ncurses) that's broken while PuTTY (and Terminal.app) actually conform to standards.

comment:19 Changed 6 years ago by zaytsev

• Version 4.7.0.8 deleted

Let's put it this way: we have nothing to do with line drawing. If something is broken, it must be ncurses, which exhibits incorrect behavior by default, but again, this can be changed using an environment variable, which, I guess, you can put into your Putty profile to be set on log in.

Recommended Links

Softpanorama Recommended

Top articles

Sites

Top articles

Sites

...

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: July, 28, 2019