From 4.8.18 strange behavior when used in a SSH session from PuTTy #3820
Comments
Tried another SSH client from windows..SmartTTy |
Do you use vanilla mc or mc from some repo (probably, with some patches)? |
Replying to andrew_b:
Fedora F25 and F26 std repo |
Fedora just recently switched from slang to ncurses. |
Could you please attach a screenshot?
Is this only the line drawing wrong, or something else too? If so, what? |
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 |
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. |
|
Replying to egmont:
I have not found anything else than the line drawings
Screenshot attached with Putty setting codepage UTF-8 |
Replying to egmont:
Then line drawing is ok |
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. |
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. |
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." |
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. |
environment variable LC_CTYPE and Putty's Configuration/Window/Translation/Remote_character_set should be compatible: both UTF-8 or both ISO-8859-x |
|
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. |
Important
This issue was migrated from Trac:
knudch(knud.skrald@….info)egmont(@egmontkob),kloczek(kloczko.tomasz@….com),dickey(dickey@….com)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
Note
Original attachments:
knudch(knud.skrald@….info) onMay 2, 2017 at 14:59 UTCThe text was updated successfully, but these errors were encountered: