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.

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.

Tommy
A mistake can be valuable or costly, depending on how faithfully you pursue correction

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.

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.