Ticket #3820 (new defect)

Opened 7 years ago

Last modified 5 years ago

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

Reported by: knudch Owned by:
Priority: major Milestone: Future Releases
Component: mc-tty Version: master
Keywords: Cc: egmont, kloczek, dickey
Blocked By: Blocking:
Branch state: no branch Votes for changeset:

Description

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

Attachments

mc_bug1.png (50.2 KB) - added by knudch 7 years ago.

Change History

comment:1 Changed 7 years ago by knudch

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

comment:2 follow-up: ↓ 4 Changed 7 years ago by andrew_b

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

comment:3 Changed 7 years ago by andrew_b

Related to #3809.

comment:4 in reply to: ↑ 2 Changed 7 years ago by 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

comment:5 Changed 7 years ago by egmont

  • Cc egmont added

Fedora just recently switched from slang to ncurses.

comment:6 follow-up: ↓ 11 Changed 7 years ago by 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?

comment:7 follow-up: ↓ 12 Changed 7 years ago by 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

comment:8 Changed 7 years ago by 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.

Last edited 7 years ago by egmont (previous) (diff)

comment:9 Changed 7 years ago by zaytsev

  • Cc kloczek added

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

comment:10 Changed 7 years ago by zaytsev

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

Changed 7 years ago by knudch

comment:11 in reply to: ↑ 6 Changed 7 years ago by 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

comment:12 in reply to: ↑ 7 Changed 7 years ago by 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

comment:13 Changed 7 years ago by zaytsev

  • Cc dickey added

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.

comment:14 Changed 7 years ago by 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.

comment:15 Changed 7 years ago by 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."

comment:16 Changed 7 years ago by 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.


comment:17 Changed 7 years ago by 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

comment:18 Changed 7 years ago by andrew_b

  • Component changed from mc-core to mc-tty
  • Milestone changed from 4.8.20 to Future Releases

comment:19 Changed 5 years ago by 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.

Note: See TracTickets for help on using tickets.