0

I ran BitchX on three different Linux OS-es because I got this weird � (question mark) on two of them (Linux OpenSUSE 11.4 and BackTrack 5 R1) using yakuake/konsole (OpenSUSE) and terminator/tilda (BT 5 R1).

However, on PuppyLinux Lucid 528 with RoxTerm the character is displayed as it should be (it is the Greek character "fi"). Now, on both SUSE and BT I have checked to see the value of $LC_CTYPE, and it's the same as in Puppy Linux (namely en_US, so no utf-8 encoding).

I've experimented on both SUSE and BT with different character encodings (from terminal's settings), I've noticed the changes, but the text was still sometimes garbled, instead of the question mark I got some weird unintelligible "u"-s (in Puppy it is always displayed correctly).

What could cause this annoying problem?
What could be different and how can I check the difference?

4
  • What caused this character to appear? Commented Mar 23, 2012 at 23:19
  • I just ran the application and saw it..it's a wrongful replacement of the Greek character.
    – chimil
    Commented Mar 24, 2012 at 7:05
  • SOLVED I set the value of $TERM to 'linux' (it was set to 'xterm' by default). Added "export TERM='linux'" (without the double quotes) to .bashrc and now the character is displayed properly and I can even see the ASCII coloured drawings.
    – chimil
    Commented Mar 24, 2012 at 10:16
  • UPDATE The tweak ONLY works with gnome terminals installed on either KDE or Gnome desktop environment (terminals that support it: gnome-terminal, terminator, ROXterm, tilda, guake). It does not work in Konsole or Yakuake, not even in Urxvt.
    – chimil
    Commented Mar 25, 2012 at 10:00

2 Answers 2

2

There are several things going on here.

Can you first make sure that LC_CTYPE=en_US does mean "no utf-8"?

The nl_langinfo function can help, for example:

$ python
>>> import locale
>>> locale.setlocale(locale.LC_CTYPE, 'en_US')
'en_US'
>>> locale.nl_langinfo(locale.CODESET)
'ISO-8859-1'

Secondly, it would be helpful to try changing only one variable at a time. For example, if RoxTerm works in PuppyLinux, does it work in OpenSUSE and/or BackTrack? And can you also say which version of BitchX you're using, in case it makes a difference?

Finally, IRC doesn't really supply any character encoding information, so the server and all the users in a channel have to agree on a character encoding. I think these days most users use UTF-8, so maybe you should try changing your settings to UTF-8?


UPDATE

You said BitchX doesn't support UTF-8.

Then I think you are going to have problems talking to other users.

But if everyone else is talking Greek, and also using BitchX, then perhaps you want to use the Greek ISO-8859-7 character set.

On my system, the only two locales that support ISO-8859-7 out of the box are Greek language ones, e.g. el_GR.iso88597.

Run locale -a to see a full list of your options, and choose one that includes that character set.

3
  • I get this error when running the code:>>> locale.setlocale('en_US') Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/lib/python2.6/locale.py", line 513, in setlocale return _setlocale(category, locale) TypeError: an integer is required I have tried with RoxTerm in BackTrack, and didn't make a difference: the character is displayed improperly. Here's the [BitchX] (wiki.bitchx.org/svn_instructions) version I'm using, i.e. the latest. BitchX doesn't support utf-8, but it should work, since it works in Puppy.
    – chimil
    Commented Mar 24, 2012 at 7:15
  • 1
    This shall be tried as: locale.setlocale(locale.LC_CTYPE, 'en_US')
    – Netch
    Commented Mar 24, 2012 at 7:48
  • Mikel, thank you so much for your time and your answer. Please see my comment to my question. I have found the solution meanwhile.
    – chimil
    Commented Mar 24, 2012 at 18:39
1

Question mark in rhomb likely means that your client program accepts character and passes it to displaying engine (am I correct that bitchX is only terminal program?), but terminal fails to render it. So it is likely terminal configuration problem - e.g. the selected font doesn't contain glyphs for Greek characters. You can test it by copy&paste from this terminal to another one with something like "hexdump -C" running - it would show phi codepoint (U+03C6, so `CF 86' in hexdump of utf-8). If so, try to select font which supports Greek.

Seeing something like \u03C6, , etc. means likely locale is broken (not Unicode) so client accepts characters, apply Unicode treating to them but then fails to output them directly and switches to fallback mode. So, I guess SuSE and BT setups both have en_US as alias to non-Unicode coding, likely ISO-8859-1. Try to set en_US.UTF-8 directly and compare effects.

2
  • Update: I tried to use Urxvt in Puppy Linux to see if it makes any difference from ROXterm. Surprise: it does NOT display it as it should be, so the only console that works is ROXTerm (but ONLY on Puppy Linux). It's not a font issue, since ROXTerm uses Liberation and I changed to Liberation in the other terminals, without any result. I'm puzzled.
    – chimil
    Commented Mar 24, 2012 at 9:28
  • My systems are FreeBSD8 at home and OpenSuSE (12.1; short time ago it was 11.4) at work. Both have no problems with phi in terminal if configured in UTF-8, but I prefer good old xterm for this. The font at home system is xos4-terminus-...-iso10646-1. I don't know the Fedora specifics but suggest first to solve correct displaying of Greek letters in terminal on all systems and, when succeeded, switch to teach BitchX.
    – Netch
    Commented Mar 25, 2012 at 8:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .