Clear questions and runnable code get the best and fastest answer |
|
PerlMonks |
Re^5: Is File::Find Unicode-(Conformant|Compliant|Enabled|Capable)?by Anonymous Monk |
on Jun 08, 2010 at 01:46 UTC ( [id://843602]=note: print w/replies, xml ) | Need Help?? |
That fails both the easiness test and the simplicity test. It's also not portable programming. Meh, maybe :D Is File::Find magically Unicode-capable on operating systems besides Microsoft Windows?... Yes, in that it "assumes byte strings both as arguments and results", and the underlying operating system calls will happily take and give unicode if they support that. The win32 version specifically uses the ascii version of the system calls (the unicode is called wide system calls), so you get shortnames (its win32 backwards compatibility). Modern Perl really ought to be able to do file handling stuff well (it does), and it ought to be able to handle Unicode well (it does now), and it ought to be able to do both at once well (it doesn't - not on Windows). Yeah, Modern Perl really ought to be without bugs too :) See this note from perlunicode One reason why Perl does not attempt to resolve the role of Unicode in these cases is that the answers are highly dependent on the operating system and the file system(s). For example, whether filenames can be in Unicode, and in exactly what kind of encoding, is not exactly a portable concept. Similarly for the qx and system: how well will the 'command line interface' (and which of them?) handle Unicode? Does anyone here know: Is File::Find going to be enhanced soon to handle Unicode directory and file names? It's a core module. *yawn* here is patch
-- Some guy who happened to stop by and tune in for a minute
In Section
Seekers of Perl Wisdom
|
|