Followup to: <[EMAIL PROTECTED]>
By author: Tomohiro KUBOTA <[EMAIL PROTECTED]>
In newsgroup: linux.utf8
>
> Hi,
>
> At 26 Jun 2001 16:37:05 -0700,
> H. Peter Anvin <[EMAIL PROTECTED]> wrote:
>
> > The issue is, however, what that does mean? In particular, strings in
> > the filesystem are usually in the system-wide encoding scheme, not
> > what that particular user happens to be processing at the time.
>
> Ah, I understand. We were discussing about different theme.
> My point is not on the byte sequence for filenames in the filesystem.
> It can or cannot be UTF-8. I don't care much because users have
> little chance to access to the raw byte sequence on the filesystem.
> My point is that user-level commands must obey locale when they
> communicate with users. For example, 'ls' must display file names
> in locale encoding.
>
Users access the "raw byte sequences of the filesystem" all the time,
since that is what open(), fopen(), readdir() etc use.
I don't think you get it. Doing what you suggest would mean changing
every single application out there, which would be a downright
Quixotic task. The current APIs are simply not up to the task.
Relying on the locale mechanism as it is currently defined doesn't
work. Obviously, if the entire system uses a single locale
(e.g. UTF-8) this is trivial. Anything else, and it becomes a
nightmare.
Yes, it sucks. However, all it does is show is how badly we need a
single standard encoding, and basta ya.
-hpa
--
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
Linux-UTF8: i18n of Linux on all levels
Archive: http://mail.nl.linux.org/linux-utf8/
