Re^5: RFC - File::Util 4.x Series Pre-Release

[BrowserUk]

Be warned, that is a big ask and a very big task to do portably.

Perl really doesn't have any built-in facilities to deal with Unicode paths on Windows.

[Tommy]

I appreciate the words of wisdom, especially from someone so steeped in the dark arts of Win Perl ;~)

Getting down to business though, I think it would just be a matter of blacklisting filenames (not paths) containing things that qualify as a "path root" or a path "separator". After that, what's to stop me from letting the user (try) to push anything into the interface that they want? After all, if it can't be done, Perl itself will be the one to throw the error at the end of the call stack. I'll just kindly return the error... such is my thinking.

Normalization / canonicalization are totally different matters. I'm not sure I even want to attempt that. I'd have first believe it was a useful "feature". Then again, maybe it's been done before and I could use what's already been written. Haven't checked CPAN for that yet.

Bottom line, I think it's doable in the sense that other than the basic aforementioned checks, I would just step back and let Perl make the final decisions on what it will and won't accept, instead of the hand holding and "protections" I currently have in place.

Backing off a bit from the nanny mentality is something I've been considering for some time.

It's terribly late, and I'm rambling. But thanks BrowserUK, you always get me thinking outside the box.

[BrowserUk]

I think it would just be a matter of blacklisting filenames (not paths) containing things that qualify as a "path root" or a path "separator".

Hm The problem is that Windows has two separate OS APIs for dealing with ANSI and Wide file & paths, but Perl only uses the ANSI versions internally, so trying to even open a file who's name that contains Unicode characters fails. Often silently. Even the simplest things -- like globing a directory -- won't see files that the user can see are there, because glob templates that contain Unicide characters won't match the ANSIfied short pathnames that the ANSI APIs return for files containing unicode characters.

The user can see a file (using explorer or dir), but when he uses your module to attempt to manipulate that file, your module can't even see it. He's gonna blame your module.

One possible route -- and maybe an eye-opener for the task you are thinking of taking on -- would be to look at the Win32::Unicode::* set of modules.

Good luck.

[Tommy]

That seems like a huge glaring bug. Wow.

*wonders if Perl6 tries to fix this*

Once again, thanks for the guidance, checking those out... If I'm going to be portable, I've got to understand all the dark corners of file handling on every major OS (Solaris has some of the worst).