Jungshik Shin <[EMAIL PROTECTED]> writes:
>
> Then, he should switch to en_GB.UTF-8.
I probably will.
>Besides, he implied that
>he still uses ISO-8859-1 for files whose names can be covered by
>ISO-8859-1, which is why I wrote about mixing up two encodings
>in a single file system _under_ his control.
There is a tendancy for programs to assume that the locale's encoding
is used for the contents of the file. In the UK there are a LOT of files
which are not UTF-8 but iso8859-1 or iso8859-15.
As the "RedHat cannot build perl/Tk" e-mail barage proves this is a
rash assumption. If I leave my locale as a 8859-1 one then octet == char
assumptions are "mostly harmless". If I switch to a UTF-8 locale and
a stupid program dies because I spelt naive correctly in 8859-1
and that is a UTF-8 coding violation I don't gain much.
>
> Moreover, why would you think that en_GB.UTF-8 locale gives him the
>time and date format NOT suitable for him? You're making a mistake of
>binding locale and encoding. Encoding should never be a part of the
>locale definition.
That is EXACTLY the point Jarkko and I are making. The locale setting
really tells you NOTHING about the encoding.
So when presented with
if (-d "\x{20ac}4") ...
how is "locale" supposed to help poor Joe in his en_US.utf8 locale looking
at a sub-dir created by Kurt in [EMAIL PROTECTED] or was it Karl in de_DE.utf8
> Before writing that, please read the man page of 'smbmount' and
>'mount' if Linux system is available to you. They're not environment
>variables.
I think you are on "our" side.
