-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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 UTC
The text was updated successfully, but these errors were encountered: