> It looks like it's unicode. That is a real problem because not everything > is equally unicode aware. Sometimes a unicode sequence will be > displayed as > its constituent bytes and in other contexts it will decay into a hook > character. U'll probably need to go all unicode aware on ur I/O and > processing. Read up on the unicode section in the ActiveState > manual. The > O'Reilly book is good too.
Thanks for the advice Chris. This thread was helpful: http://www.mhonarc.org/archive/html/perl-unicode/2003-12/msg00026.html But, there was no real solution offered.. just a lot of really good stuff on perl, unicode, locales and other stuff. Armed with a bit more understanding of how things worked did help though, and I went back to the original program. I noticed I was doing a call into an indirect sub from the wanted sub using $File::Find::name. I guessed that name was the result of a join. Since we are chdir in the wanted subroutine, that is not needed, and that is where the original failure occurred. I Replaced $File::Find::name with $_, and reran the program.. and gasp.. it correctly found the file with the UTF-16LE character and did not generate any errors! I was able to go through the entire set of files, and had no further problems (even though I had found evidence of several files with wide characters). Anyway, the OS was Windows Advanced 2000 Server with SP4 and the rollup applied. Dual CPU machine 2GB RAM and NTFS throughout with files coming from a workgroup based share on a Windows XP SP2 box. The problem seems to be coming from around line 726 of File::Find of Active State 5.8.7 -> $name = $abs_dir . $_; # $File::Find::name The join operation is doing something bad.. not really a win32 problem I guess. Richard _______________________________________________ Perl-Win32-Users mailing list [email protected] To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
