Re: Mutt crashing on exit or replying (sometimes)
0n Fri, Mar 06, 2009 at 03:44:45PM -0600, Kyle Wheeler wrote:
>On Friday, March 6 at 02:15 PM, quoth Joshua Tinnin:
>>> This may have nothing to do with your problem, but: setting the
>>> $charset variable manually is ALMOST NEVER a good idea! I've only
>>> ever seen *one* situation where it's even *useful*.
>>
>> I typically need more than just 7-bit text, however.
>
>So do I! But that means you have to establish an 8-bit environment,
>not just force your programs to spit out 8-bit characters and hope
>that everything makes good guesses about what's going on.
>
>> I'm really not sure how to get it to use unicode without my
>> specifying it. Is there something I'm missing? I wish the
>> documentation had warned me.
>
>The *correct* way of informing programs like mutt (so that all of the
>system libraries they rely on behave properly) is to use environment
>variables, specifically LANG (and, if you need them, the LC_*
>variables as well).
>
>Step 1 of establishing a UTF-8 environment is getting a terminal
>program that supports it. Most of them do these days, but you need to
>run them with the right flags. For example, xterm supports UTF-8, but
>requires a bunch of flags to enable it, so they usually provide the
>`uxterm` script in order to launch xterm in UTF-8 mode. The rxvt
>terminal has a similar script (I think it's `urxvt`).
>
>Step 2 is making sure you have UTF-8 fonts. This all depends on your
>OS, and I don't know the specifics of doing it with FreeBSD (with
>luck, you already have them).
>
>Step 3 is exporting the right environment variables - you can read the
>`locale` man page for details. Personally, I set LANG to be
>en_US.UTF-8, but you have to use `locale -a` (or something similar) to
>find out what encodings are available on your machine. (en means
>"english", US means "american", and UTF-8 means the character set) For
>example, on my OSX box...
>
> $ locale -a | grep en_US
> en_US
> en_US.ISO8859-1
> en_US.ISO8859-15
> en_US.US-ASCII
> en_US.UTF-8
>
>Often times, the uxterm/urxvt terminal scripts will set up your
>environment variables correctly for you, so you don't have to muck
>with them. However, many terminals do NOT set these things up for you
>(e.g. I don't believe gnome-terminal does, and I *know* Apple Terminal
>doesn't either). Chances are you want to add some logic to your
>~/.bashrc (or equivalent for your shell) to set the LANG environment
>variable correctly for your machine.
>
>(There are lots of tricks to detecting the correct locale setting for
>your terminal, depending on the environment. For example, in an X11
>environment, as long as you have a $WINDOWID environment variable, you
>can use the xprop program to find out what locale that window is
>using.)
>
>The tricky part of this is that in many cases the wrong settings can
>produce acceptable results *most* of the time.
>
>It IS, however, important to use environment variables. For example,
>mutt may use system library calls like "isalpha()", which base their
>answers on what locale they think they're in. Usually, they default to
>US-ASCII, and since that's the basis for most character sets, it
>usually produces acceptable results. But when someone sends you a
>message that uses a character that isn't in US-ASCII, those functions
>can get it wrong UNLESS they and mutt are both aware of the right
>character set.
>
>>> It'd probably be more helpful if you ran mutt inside a debugger and
>>> gave us a backtrace.
>>
>> How do you do that? Again, I'm not a programmer. I'm running it compiled
>> with debug flags and with the debug level set at 5.
>
>Usually, just load up mutt with the following command:
>
> gdb /usr/local/bin/mutt
>
>And then at the prompt, type "run". When mutt crashes, it will return
>you to the prompt, at which point you can type "backtrace". (To get
>out of it, type "quit".)
>
>>> What version of libiconv do you use? There's some buggy ones out
>>> there (esp. on FreeBSD) that are known to cause crashes. You may
>>> just need to update your iconv library.
>>
>> Well, right now it's libiconv-1.11_1. I'll run an update and see if a
>> newer version is available.
>
>Hmmm. 1.11 should be good.
>
>See about that backtrace; that'll give a much better idea of what's
>going on and where it's crashing.
An insanely useful email! Thanks for sharing this with the community kyle!
-aW
IMPORTANT: This email remains the property of the Australian Defence
Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT
1914. If you have received this email in error, you are requested to contact
the sender and delete the email.