Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Interpretation of LANG variable needs to be case insensitive. #2386

Closed
mc-butler opened this issue Oct 14, 2010 · 10 comments
Closed

Interpretation of LANG variable needs to be case insensitive. #2386

mc-butler opened this issue Oct 14, 2010 · 10 comments
Assignees
@aborodin
Labels
area: core Issues not related to a specific subsystem prio: medium Has the potential to affect progress ver: 4.7.4 Reproducible in version 4.7.4
Milestone
4.8.3

Comments

@mc-butler
Copy link

Important

This issue was migrated from Trac:

Origin https://midnight-commander.org/ticket/2386
Reporter urkle (urkle@….cc)

Related bug in iTerm 2

http://code.google.com/p/iterm2/issues/detail?id=204

When the LANG variable is set to en_US.utf-8 mcedit specifically does not correctly accept input (every character press is interpreted as a '.'). However when LANG is set to en_US.UTF-8 mcedit works correctly.

From the work on the bug against iTerm 2 it was discovered that in reality midnight commander is not handling the LANG and LC_* environment variable correctly.

From the IANA document on character sets.

The character set names may be up to 40 characters taken from the
printable characters of US-ASCII. However, no distinction is made
between use of upper and lower case letters.

http://www.iana.org/assignments/character-sets

Note

Original attachments:

  • utf8.cc (raw) by urkle (urkle@….cc) on Oct 14, 2010 at 13:43 UTC
@mc-butler
Copy link
Author

Changed by andrew_b (@aborodin) on Oct 14, 2010 at 6:15 UTC (comment 1)

MC doesn't directly interpret the LC_* and LANG variables. It detects the encoding using nl_langinfo (CODESET).

I cannot reproduce this bug on Linux. Both ru_RU.UTF-8 and ru_RU.utf-8 values of LANG are interpreted as utf-8 locale and MC works fine for me with that both values.

I can't find MC details at http://code.google.com/p/iterm2/issues/detail?id=204: MC version, GLib version, wich screen library MC is built with (S-Lang or NCurses).

@mc-butler
Copy link
Author

Changed by urkle (urkle@….cc) on Oct 14, 2010 at 13:41 UTC (comment 2)

MC version has been 4.7.+ (First noticed it with 4.7.0.3 currently using 4.7.4)

glib2 version is 2.22.4
MC is currently built with slang (issue occurred when built with ncurses as well)

This is on Mac OS X 10.6.4.

And the issue is NOT specific to iTerm either.. the Standard Mac OSX terminal also exhibits the same behavior if the LANG is set to a lowercase utf-8. (the default there is upper case though)

BTW, I can't recreate on my linux box either, only the Mac system.

@mc-butler
Copy link
Author

Changed by urkle (urkle@….cc) on Oct 14, 2010 at 13:43 UTC

UTF test script

@mc-butler
Copy link
Author

Changed by urkle (urkle@….cc) on Oct 14, 2010 at 13:47 UTC (comment 3)

I attached a test C++ program that I used for actually a different purpose but it does show some "oddities" between how Mac OS X and Linux return back information about the character set.

Specifically, the nl_langinfo(CODESET); call.

On linux it ALWAYS returns upper case UTF-8 whether the LANG is set to utf-8 or UTF-8.
On Mac OS X, it returns the same case as the LANG input.

@mc-butler
Copy link
Author

Changed by andrew_b (@aborodin) on Nov 5, 2011 at 6:14 UTC (comment 4)

  • Milestone changed from 4.7 to Future Releases
  • Branch state set to no branch

@mc-butler
Copy link
Author

Changed by andrew_b (@aborodin) on Mar 22, 2012 at 17:35 UTC (comment 5)

  • Owner set to andrew_b
  • Branch state changed from no branch to on review
  • Status changed from new to accepted
  • Milestone changed from Future Releases to 4.8.3
  • Component changed from mcedit to mc-core

Branch: 2386_LANG_case_insensitive (parent: master).
[c45e5a67123f6c483a4032a7130042295a273254]

urkle, plese test this fix.

@mc-butler
Copy link
Author

Changed by slavazanko (@slavaz) on Mar 22, 2012 at 19:01 UTC (comment 6)

  • Votes set to slavazanko

@mc-butler
Copy link
Author

Changed by angel_il (@ilia-maslakov) on Mar 24, 2012 at 7:08 UTC (comment 7)

  • Votes changed from slavazanko to slavazanko angel_il
  • Branch state changed from on review to approved

@mc-butler
Copy link
Author

Changed by andrew_b (@aborodin) on Mar 28, 2012 at 9:02 UTC (comment 8)

  • Resolution set to fixed
  • Votes changed from slavazanko angel_il to committed-master
  • Branch state changed from approved to merged
  • Keywords set to stable-candidate
  • Status changed from accepted to testing

Merged to master: [91ff90f].

@mc-butler
Copy link
Author

Changed by andrew_b (@aborodin) on Mar 28, 2012 at 9:12 UTC (comment 9)

  • Votes changed from committed-master to committed-master committed-stable
  • Status changed from testing to closed
  • Keywords stable-candidate deleted

Merged to 4.8.1-stable: [d474cad].

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@aborodin aborodin

Labels
area: core Issues not related to a specific subsystem prio: medium Has the potential to affect progress ver: 4.7.4 Reproducible in version 4.7.4
Milestone
4.8.3
Development

No branches or pull requests
2 participants
@aborodin @mc-butler