Re: Echoing of 8-bit-characters broken after 4.3.2?

[Wolfgang Hukriede <whukriede@googlemail.com>]

Bart wrote:
> Try
>
> export LANG=is_IS.ISO8859-1
>
> I discovered this by tab-completing values for LANG.

Ok, many thanks, this works so far. I had to change the export to
LANG=IS.ISO8859-1 though since otherwise `date' talks in a language
which is unknown to me:

  > date
  lau 28 feb 2009 19:40:54 CET

No, this isn't OSX, but Freebsd-6.4 (with newest ports though by a few
days).

> The multibyte character handling on OSX appears to be particularly
> sensitive to the LANG setting (see my previous mail to Wolfgang).
> At the same time, OSX doesn't appear to export a LANG value (or at
> least it doesn't on my iMac at work).

Freebsd does not export the variable either, but why should it?

> I can't precisely reproduce the above; I get things like
>
> schaefer<263> touch x<00c3><00c3><00c3>x
>
> or
>
> schaefer<263> touch xinsert-composed-char:180: character not in range
>
> before I ever get as far as creating the file.  Maybe there's some
> additional character munging happening in transit of the email so
> I'm not using the correct input.

This is not so here. Only just the echoing of the character fails
unless LANG is set.
Tab completion worked in 4.3.2 and works with LANG set.

> Wolfgang, if you're reading this, something that I forgot to mention in
> my reply to you is that sometime during 4.3.x zsh began to pay closer
> attention to characters that are absent from the declared LANG character
> set and to either refuse to process them at all, or to render them as
> digits surrounded by angle brackets.  It no longer blindly passes those
> characters around unprocessed, so things that "worked" before because
> xterm dealt with the processing will now appear to "fail" because the
> shell is trying harder to do the right thing internally.

Yes, I suspected so. But what is the benefit of it? Perhaps to make
certain the shell can assume unicode as the default? Would an explicit
setopt (to remove the ambiguity) not be a viable/better alternative?

Looking up "man 1 locale" I found the bug section below. Might this be
significant?

  DESCRIPTION
       ...
       -m      Print names of all available charmaps.

  BUGS
       Since FreeBSD does not support charmaps in their POSIX meaning, locale
       emulates the -m option using the CODESETs listing of all available
       locales.