In 'perlunicode' under 'when Unicode does not happen' there is the statement (regarding Unicode functionality and the file system-related functions and operators - BTW the author missed '-X' ):
"One reason why Perl does not attempt to resolve the role of Unicode in this cases is that the answers are highly dependent on the operating system and the file system(s)." This statement seems a bit evasive - especially since there are no other reasons listed. What are the other reasons? Is there a plan to make things easier in this area? Or not? If not, why? This statement also seems like an exaggeration. On Unix-like systems, it is obvious how to deal with the file system - you convert Unicode to multibyte. On Windows, there is a choice when dealing with the file system - multibyte or Unicode - but the new "-C" switch seems to cover that choice. On other systems - who knows (true!) but isn't that a porting issue? Those 'other' people wouldn't be harmed by making things easier for the rest of us, right? Dealing with qx and 'system()' also seems less than mysterious to me - there's no 'wfork' - as far as I know - so you use multibyte. Don't get me wrong - I love the Unicode support in Perl - it is an amazing effort. But dealing with the file system (and to a lesser extent qx/system) seems like a big hole to me. An example. Say I have a Shift-JIS string and I want to do a mkdir (on a Shift-JIS-enabled OS with 5.8.1 build 807): $newdir = "kanji_here_\x89\x5C"; mkdir $newdir; The above works the way I'd expect, although print (-d $newdir ? 'yes' : 'no'); prints 'no' - oops a character handling bug! The second byte of the kanji is a backslash, which confuses Perl, apparently. "-d" really ought to assume the user knows what he is doing and do character-handling based on the current file system encoding setting (LC_CTYPE or the equivalent). It seems counter-intuitive that this fails: use encoding 'shiftjis'; $newdir = "kanji_here_\x89\x5C"; mkdir $newdir; Whoops - I just created a directory with Unicode utf-8 bytes (which don't assemble into valid Japanese characters). I don't think that's what most users would expect - and 'mkdir' could do better than that. Anyway, I don't mean to criticize all the wonderful work that has been done. This is more a question about future direction and also a request to update the documentation - if this kind of thing isn't going to be fixed soon it would be nice to add some sample code showing how to write a proper Unicode-ized Perl script that deals with the file system properly. Regards, =ED
