Re: [STUMP] That c-encoding problem again

[Christophe Rhodes]

Rohan Nicholls <address@hidden> writes:

> Seems I have found a solution, more like stumbled on it.  If you set
> the LC_ALL and LANG variables before starting sbcl to "UTF-8", it
> handles everything properly.

This doesn't seem likely to me, I'm afraid.

> So for if anyone else finds themselves suffering from the problem in
> the future, give this a shot and it should fix it.  Why sbcl chokes on
> something as uncomplicated as en.US.UTF-8 which maps to UTF-8, I do
> not know, but I would guess that it is not using the system locale
> definitions and might be using its own implementation of unicode,
> which only recognises UTF-8 and not variations on the theme.

I'm fairly sure that this is in fact backwards, assuming you meant
en_US.UTF-8.  My _guess_ as to what is actually causing your sbcl to
choke is that there is something present in the environment, or in
your current working directory's name, that is not legally
UTF-8-encoded; maybe a binary blob of data, or something -- and the
error message about not being able to decode an octet sequence into a
utf-8 string is from that.  (It's probably a bit more complicated,
because the error message itself is weird, but along these lines).

When you set your environment variables with LANG=UTF-8, what you're
doing is causing your system (including sbcl) to fallback to the C
locale; you can see this by doing
  LANG=UTF-8 locale -c LC_CTYPE
at a shell prompt.  This means that SBCL won't try to do certain
encoding, and so you get further with executing your Eterm...

SBCL's locale handling is entirely based on the system; it calls
nl_langinfo() and determines its default encoding based on that.

Best,

Christophe