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

[Wolfgang Hukriede <whukriede@xxxxxxxxxxxxxx>]

Andrey wrote:
> Because this is established standard to define your character set
> properties. Without it applications should assume C (or POSIX) locale
> that basically corresponds to standard ASCII.

Should the character set properties not be set by LC_CTYPE? As far as
I can tell LANG sets more than that? Do I understand correctly that
LANG is zsh-specific? (On my box, man 3 setlocale does not have it.)

> So I would be surprised if
> zsh were the only program that had issues with non-ASCII characters.

At least emacs passes them through without ado. There's only one other
program that I had problems with in that respect. (That's unicode
only.) Looks like more will come...

> FreeBSD could provide some other means to define local though.

Not that I know of.

> Because blindly emitting arbitrary character sequence to terminal may
> have completely undefined effects and screw up display to the point that
> you need hard reset (town legend also is that you can cause you terminal
> to echo back any sequence like "rm -rf" as input back to shell ...)

Urban legends aside, this may be. Otoh... I've been using zsh since at
least 10 years almost exclusively and quite intensely and have used
8-bit-characters all the time (all on xterms), but any display
distortion never happened to me. This is probably due to the fact that
filenames are mostly under ones own control. I suffered display
distortion from reading emails though, but the shell could not have
done anything about that. Correctness of vt100-control-sequences
cannot be monitored either.

Therefore I think passing-through of eight bit characters should be
configurable. But I still do not understand how am I supposed to do
that (without triggering side effects). Why is PRINT_EIGHT_BIT
constricted to affect tab-completion only?