Re: Mutt crashing on exit or replying (sometimes)

[Kyle Wheeler <kyle-mutt@xxxxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

~Kyle
- -- 
Science is what we can tell a computer. Art is everything else.
                                                               -- Knuth
-----BEGIN PGP SIGNATURE-----
Comment: Thank you for using encryption!

iEYEARECAAYFAkmxmU0ACgkQBkIOoMqOI15QiACdHQfdpyCDChty3AK8L8Q90iA9
r8sAoKmnwTCM3UVgW0OWlzVsuZGRLxiN
=VbaN
-----END PGP SIGNATURE-----