At Thu, 1 Feb 2001 21:30:22 -0600,
David Starner <[EMAIL PROTECTED]> wrote:
>
> On Thu, Feb 01, 2001 at 07:14:09PM -0800, Ulrich Drepper wrote:
> > Tomohiro KUBOTA <[EMAIL PROTECTED]> writes:
> >
> > > Thus, either of them should be taken:
> > > 1. libc/kernel accepts only UTF-8 filenames.
> > > 2. libc/kernel knows the locale.
> >
> > None of this. Neither the kernel nor libc will ever do anything about
> > the encoding of filenames etc. There are these stupid Winblows
> > exceptions of course but not for real filesystems.
>
> Yes, because it's better to be in the state that Linux is in (inconsistent
> encoding of filenames) than to actually now what the name of a file is
> in any program, always, like Winblows.
Then how problems I noticed can be solved?
Denial of 1 (libc/kernel accepts only UTF-8 filenames) leads to:
1'. libc/kernel accepts locale-encodings.
Denial of 2 (libc/kernel know the locale) leads to:
2'. libc/kernel doesn't know the locale or the encoding of the filename.
Handling locale-encodings without knowing the locale leads to
problems which I noticed in the last mail, i.e., the 2nd byte
of multibyte character can hit '/' and libc/kernel mitakes it
as directory separater.
Or, you think locale-encodings should be used but multibyte
encodings cannot be used? It is unfair.
---
Tomohiro KUBOTA <[EMAIL PROTECTED]>
http://surfchem0.riken.go.jp/~kubota/
"Introduction to I18N"
http://www.debian.org/doc/manuals/intro-i18n/
-
Linux-UTF8: i18n of Linux on all levels
Archive: http://mail.nl.linux.org/lists/
