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

[Andrey Borzenkov <arvidjaar@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1561 bytes --]

On 28 февраля 2009 22:52:33 Wolfgang Hukriede wrote:
> > 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?
>

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. So I would be surprised if 
zsh were the only program that had issues with non-ASCII characters.

FreeBSD could provide some other means to define local though.

>
> > 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?

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 ...)



[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]