Re^4: Is File::Find Unicode-(Conformant|Compliant|Enabled|Capable)?

That fails both the easiness test and the simplicity test. It's also not portable programming.

Is File::Find magically Unicode-capable on operating systems besides Microsoft Windows?

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).

Does anyone here know: Is File::Find going to be enhanced soon to handle Unicode directory and file names? It's a core module.

Comment on Re^4: Is File::Find Unicode-(Conformant\|Compliant\|Enabled\|Capable)?

Replies are listed 'Best First'.
Re^5: Is File::Find Unicode-(Conformant\|Compliant\|Enabled\|Capable)? by Anonymous Monk on Jun 08, 2010 at 01:46 UTC
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 Read more... (3 kB) Seems to work, but needs a test case, and Win32::Unicode::File::stat needs some help.... good luck, I hope you submit a bug report (perlbug) and get this patched quick. -- Some guy who happened to stop by and tune in for a minute	[reply] [d/l]

Replies are listed 'Best First'.

Re^5: Is File::Find Unicode-(Conformant|Compliant|Enabled|Capable)?
by Anonymous Monk on Jun 08, 2010 at 01:46 UTC

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