Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I'm using GNU dialog in one of my lengthy shell scripts. One of the areas I've got problems with is when I'm asking for an inputBox where the user can type a book's title, mostly in French.

In this inputBox, entering accented characters (éàè are very common in French), or special UTF-8 characters such as the em-dash "—" shifts the cursor 4 characters right, instead of one. After 3 or 4 "special" characters, the inputbox is completely unusable because of this artifact.

Similarly, when I display a menu with dialog, accented characters shift the right border of the dialog box. That's less handicapping than in the inputBox, but yet it's a visual discomfort.

I've tried all kinds of stuff to get this working, to no avail.

For the record, here are my LC_* environment vars:

LC_PAPER=fr_FR.UTF-8
LC_ADDRESS=fr_FR.UTF-8
LC_MONETARY=fr_FR.UTF-8
LC_NUMERIC=fr_FR.UTF-8
LC_ALL=fr_FR.UTF-8
LC_TELEPHONE=fr_FR.UTF-8
LC_MESSAGES=fr_FR.UTF-8
LC_IDENTIFICATION=fr_FR.UTF-8
LC_COLLATE=fr_FR.UTF-8
LC_MEASUREMENT=fr_FR.UTF-8
LC_CTYPE=fr_FR.UTF-8
LC_TIME=fr_FR.UTF-8
LC_NAME=fr_FR.UTF-8
LANG=fr_FR.UTF-8

What could I do?

(Edit: as stated below, I'm on a Mac, and the same problem arises whether I use iTerm2 or the built-in Terminal emulator.)

share|improve this question

2 Answers 2

Make sure your terminal is in UTF-8 mode. If you are setting the locale variables from your ~/.bashrc as some do, then they will apply to the shell, but not to its parent terminal. Use tr \\0 \\n </proc/$PPID/environ to check whether the terminal has the same locale variables. (Some (such as GNOME Terminal) have an explicit character encoding menu, which you can use instead.)

Also, make sure the locale is listed by locale -a – if it is not, edit /etc/locale.gen and run locale-gen as root.


Note that it is not recommended to set LC_ALL unless necessary, as this makes overriding the more-specific variables impossible. Just LANG is enough

share|improve this answer
    
I don't have a /proc, as I'm on a Mac for iOS development. Whether I'm using iTerm2 (my default terminal) or Mac OS's standard Terminal, dialog exhibits this behavior. And my fr_FR.UTF-8 is correctly listed under locale -a. –  Cyrille Sep 8 '11 at 20:06
    
... (continued) but in iTerm2's settings, "Terminal Emulation > Character Encoding" is correctly set to "Unicode (UTF-8)". –  Cyrille Sep 8 '11 at 20:06
    
Actually, my terminal works great when in bash or vi — I can enter accented characters and it does not mess with them. Only dialog produces this problem. Could it be a problem in ncurses' configuration? –  Cyrille Sep 9 '11 at 13:21
    
Outdated ncurses and/or dialog, possibly? –  grawity Sep 9 '11 at 13:58
    
I would be surprised, I've compiled them with MacPorts just a few days ago. nCurses is at 5.9.20110404 and dialog is 1.1-20110707. I've had this problem for months, anyway. –  Cyrille Sep 9 '11 at 14:20

I know it's an old question, but neverthereless the answer might be useful...

I solved the problem setting the following environment variable:

export NCURSES_NO_UTF8_ACS=1

I have putty with the putty-256color Terminal string and a RHEL6 machine. It also works when using tmux or screen. For more information about this variable, just call 'man 3 ncurses'.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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