I am trying to detect the current gnome-terminal character encoding from the command line. I have tried using gconftool :

$ gconftool-2 --get /apps/gnome-terminal/profiles/Default/encoding
$ gconftool-2 --type string --set /apps/gnome-terminal/profiles/Default/encoding
$ gconftool-2 --get /apps/gnome-terminal/profiles/Default/encoding

But if I now go to the gnome-terminal menu and choose Terminal->Set Character Encoding->ISO-8859-10 and then run again

$ gconftool-2 --get /apps/gnome-terminal/profiles/Default/encoding

so the encoding in /apps/gnome-terminal/profiles/Default/encoding has not changed to ISO-8859-10 even though the terminal is using that encoding. So it seems gconftool cannot be used to determine the current encoding.

  • What is it you actually want to do? I'm asking because this sounds like an XY problem and if you explain what your final objective is, there might be a better way. – terdon Jun 20 '15 at 15:18
  • @terdon Basically I have an application that should be run from gnome-terminal, but the application will only output UTF-8 encoded unicode to the terminal, therefore the application should warn the user if the terminal is not currently using UTF-8 encoding.. – Håkon Hægland Jun 20 '15 at 15:21
  • Ah, OK. Please edit your question and add that information. In that case, forget about gnome-terminal, you have no way of knowing if your user happens to be using it and that is only one of the many terminals available. – terdon Jun 20 '15 at 15:24
  • @terdon Actually the application only works in gnome-terminal.. It should not be used in any other terminals.. – Håkon Hægland Jun 20 '15 at 15:26
  • Um, OK. What a strange limitation. I guess your program's objective is to somehow modify gnome-terminal then, otherwise you are ignoring a huge subset of users. I doubt you'll find a way to detect the terminal's encoding. I would instead check for the user's language settings, something like echo $LANG | grep utf8 || echo "problem!" – terdon Jun 20 '15 at 15:30

I recommend checking locale charmap's output (which reports the values set by $LANG, $LC_CTYPE, $LC_ALL). This one does not directly query the terminal, but it's essential for most of the applications that the locale is set up correctly, consistently with the terminal. If it reports anything else than the actual behavior, not only your app but pretty much every other app will misbehave in the terminal, and it's not your fault. Of course the user can change the encoding from the menu, but if they decide to shoot themselves in the foot, there's not much you can/should do against. It's not your task to detect a faulty system-wide setting. Also there's no way for you to notice if the user switches encoding while your app is running, so I don't think there's much point in verifying it at startup.

If you really really need to check the runtime behavior, you can emit escape sequences that query the cursor position (and report it back in a certain format as if it's been typed from the keyboard), then emit some bytes that e.g. form a single character in UTF-8 while multiple characters in any other encoding (disabling local echo in the mean time, so keypresses by the user don't advance the cursor), and query the cursor position again. It's perhaps too much trouble and really not worth the effort.

  • What do you mean by "checking locale charmap's output"? Running locale -m displays all available charmaps.. – Håkon Hægland Jun 23 '15 at 18:40
  • Run the command locale charmap exactly as I've typed it, rather than locale -m. This prints you the locale your apps running inside the terminal will assume. If it's not set consistently with the charset chosen in the terminal, you're screwed anyways. (By the way this should be identical to that complicated perl one-liner.) – egmont Jun 23 '15 at 22:11
  • Yes this seems to work. Where are the locale keywords (like charmap, date_fmt, ..) defined? I tried the man page and googling but no luck so far :) – Håkon Hægland Jun 24 '15 at 8:19
  • Where have you found date_fmt then? :) I don't know where the keywords are defined, but it seems the ones recognized are the ones used in the definition files under /usr/share/i18n/locales (which are compiled into binary format to /usr/share/locale or /usr/share/locale-archive). – egmont Jun 24 '15 at 14:50

Here is a half-solution, addressing the problem of determining the encoding when /apps/gnome-terminal/profiles/Default/encoding is equal to the string current. Assuming that the string current means that gnome-terminal should use the current locale.

It is tempting to check the LANG variable to determine the encoding, but according to this question, that is not reliable. Instead the Perl module I18N::Langinfo should be used:

temp=$(gconftool-2 --get /apps/gnome-terminal/profiles/Default/encoding)

if [[ $temp == "current" ]] ; then
    perl -MI18N::Langinfo=langinfo,CODESET -E 'say langinfo(CODESET())'
    echo $temp

Note that this answer does not address the problem of determining the gnome-terminal encoding when the user manually changes the encoding from the gnome-terminal menu.

  • This solution also silently assumes that the user uses the Default profile. – egmont Jun 23 '15 at 17:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.