>On the contrary, many designers would enthusiastically make that same >"mistake" if designing a new system. The whole point of making filenames >strings of bytes is that it lets the filesystem be character-set-neutral.
But it didn't work. You can't use EBCDIC or UTF-16 with a Unix filesystem. In fact, a new Unicode format had to be created for Unix filesystems, because the Unix filesystem made assumptions about what 0x0 and 0x2F mean. >Any other decision sets you up for a lot of backward-compatibility trouble >if your ideas on character-set encoding ever change. Yes? You're in for a lot of trouble if your ideas on character-set encoding ever changes. This is not limited to file systems >> ...if Unix had >> been designed to be a multilingual system from the start, such a design >> would never had existed. > >Unix was designed to be a language-independent system from the start. Debian wasn't fully 8-bit clean until Hamm, in 1998. (That is, any program that wasn't 8-bit clean was fixed or removed.) Even today, many programs won't handle EUC-JP or UTF-8 correctly. Doing a quick websearch, <http://infocom.cqu.edu.au/Units/aut98/85321/Study_Material/Resource_Materials/UNIX_History/Serious/> claims that Unix(tm) wasn't 8-bit clean until SVR4, in 1988. A language- independent system to me doesn't mean you support the dozen European languages that use the English alphabet plus six characters or less, as long as you don't mind those six characters getting used as symbols weird places. -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
