From 4.8.18 strange behavior when used in a SSH session from PuTTy

[knudch]

In a SSH session coming from PuTTy codepage is incorrect eg. line drawings etc is wrong.
Should be UTF-8 but is ISO8859-1.
SSH session from a Linux client MC 4.8.18 is working correct.

Version 4.8.17 does not show this bug
4.8.18/19 do..

Knud

[knudch]

Tried another SSH client from windows..SmartTTy
same behavior....MC is using wrong codepage

[andrew_b]

Do you use vanilla mc or mc from some repo (probably, with some patches)?

[andrew_b]

Related to #3809.

[knudch]

Replying to andrew_b:

Do you use vanilla mc or mc from some repo (probably, with some patches)?

Fedora F25 and F26 std repo

[egmont]

Fedora just recently switched from slang to ncurses.

[egmont]

Could you please attach a screenshot?

eg. line drawings etc is wrong.

Is this only the line drawing wrong, or something else too? If so, what?

[egmont]

PuTTY is known not to support the linedrawing "alternate character set" in UTF-8. To workaround in ncurses, try this:

export NCURSES_NO_UTF8_ACS=1

[egmont]

As per ​http://www.cl.cam.ac.uk/~mgk25/unicode.html#term probably PuTTY does The Right Thing, although it's not the best choice wrt. backwards compatibility.

ncurses could safely go for UTF-8 for single line drawing chars, yet it chooses the backwards compatible braindamaged way instead which doesn't work in PuTTY. It also fails to handle double line drawing chars: #3158. Not my favorite piece of software, to say the least :(

I'm wondering if mc could work around this issue by setting NCURSES_NO_UTF8_ACS=1 for itself, although the problem is not limited to mc, effects all other ncurses apps the same way, so it should rather be solved on ncurses or OS/distribution level.

[zaytsev]

@kloczek: FYI, another consequence of your slang -> ncurses migration.

[zaytsev]

@egmont, maybe try to involve @dickey in the discussion?

[knudch]

Replying to egmont:

Could you please attach a screenshot?

eg. line drawings etc is wrong.

Is this only the line drawing wrong, or something else too? If so, what?

I have not found anything else than the line drawings

Screenshot attached with Putty setting codepage UTF-8

[knudch]

Replying to egmont:

PuTTY is known not to support the linedrawing "alternate character set" in UTF-8. To workaround in ncurses, try this:

export NCURSES_NO_UTF8_ACS=1

Then line drawing is ok

[zaytsev]

Hi Thomas,

I'm CC'ing you on this issue since you might have an opinion on that. In not, please feel free to remove yourself :-) Is there a function we can call to the same effect as setting NCURSES_NO_UTF8_ACS, and should we do this, or rather it should be done differently / at a different level?

Z.

[dickey]

There's no function (intentionally: ncurses uses environment variables where a function would not be helpful). You'd have to set the environment variable before initializing a screen, e.g., with newterm or initscr.

[egmont]

Just for the record: ​http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/utf8-plus-vt100.html .

It's been a "wish" for PuTTY for 10+ years now with "priority: low: We aren't sure whether to fix this or not."

[knudch]

As I can read....the "wish" for PuTTy has some "implications"....right or wrong I don't know.

But PuTTY is not alone to this problem....As mentioned earlier in this thread other combinations (SmartTTy/MC) shows the same behavior.

[lzsiga]

environment variable LC_CTYPE and Putty's Configuration/Window/Translation?/Remote_character_set should be compatible: both UTF-8 or both ISO-8859-x

[egmont]

PuTTY version 0.71 adds a new config option:

"Enable VT100 line drawing even in UTF-8 mode"

Enabling it should also solve the "lqqqqqqqq" problem.