On Son, 2005-06-05 at 09:39 +0600, Alexander E. Patrakov wrote: > Jürg Billeter wrote: > > Yes but it may introduce problems elsewhere as e.g. glib (and so gtk+) > > uses UTF-8 as default filename encoding, independent of your LANG > > variable - which is IMO the only sane filename encoding but is obviously > > problematic for non-UTF-8 console users. > > Every sane distro sets the G_FILENAME_ENCODING or (obsolete) > G_BROKEN_FILENAMES variable. Read this page:
I know these variables but the reason why IMO the only sane way is to use UTF-8 exclusively for encoding filenames is interoperability. You can't assume that every system you scp/rsync from/to or share an nfs mount or not even other possible users on the same system use the same locale as you do. Therefore is setting the filename encoding to the encoding of the by chance currently used locale not the right way. > Do you think that setting G_FILENAME_ENCODING should be moved to Glib2 > page instead? I have no preference whether it's there or on the glib2 page but there should probably be a note added that setting G_FILENAME_ENCODING may cause interoperability problems and not setting it and not using UTF-8 locales - as LFS does - causes display problems in console applications. > > By defaulting to UTF-8, Glib2 developers essentially say that "ls" is > broken and that every bash script writer should call iconv before > displaying filenames. Thus, I disagree with their default. "ls" can't be declared broken because there is no way "ls" could know what filename encoding is used. There should probably exist a standardized variable like G_FILENAME_ENCODING not only for glib2 based applications but globally so for backward compatibility the locale's encoding can be used and later one could switch to UTF-8. > > And now LFS is broken in all UTF-8 based locales (mainly due to ncurses > and console bootscript). The breakage is critical enough to prevent > non-English users from typing/seeing text in their language in some > important applications. English people wouldn't call this critical > because their native language uses only ASCII characters and pound sign, > thus the breakage occurs only on rare-for-them characters. But it's > still there. I know. For me it's not critical enough to not use UTF-8 as German at least uses mostly ASCII characters. > > Making LFS work in the upstream-imposed limits for both UTF-8 and > traditional locales is scheduled for LFS 7.0, but UTF-8 will not be the > default and its use will still be discouraged. I hope that upstream gets fixed at sometime. IIRC at least Fedora Core uses UTF-8 as default encoding, so there are probably people working on fixing all the problems but not as intense as it could be.... Regards, Jürg -- Jürg Billeter <[EMAIL PROTECTED]> -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
