in reply to enumerating files on Windows with non-latin chars

I'm not a windows user (let alone one who would use file names in non-ascii languages), but provided you know what character encoding is being used for the file names, then using readdir in combination with Encode should do just fine.

If the names happen to be in utf8 already, then you are using Encode merely to mark the names as utf8 after you read them from the directory. If they are in some other encoding (UTF-16LE, CP1256 for Arabic, GBK for Chinese, or whatever), then you use Encode to turn that into utf8, so you can treat them properly as strings of characters (for regex matches, substr, etc).

If you go that route for a full recursive scan of a directory tree, you would simply manage the recursion yourself, using the "-d" function to know whether a given entry is a subdirectory, and if so, recurse into it (depth-first traversal) or push it onto a stack until you're done with the current directory (breadth-first traversal).

When you say you've "tried with find(&subroutine)", it would be much better if you show us the actual code you tried. I for one wouldn't be able to test it for myself, but if you were doing something obviously wrong, no one can spot the error if they can't see the code.

Regarding what you might need to do in order to read your file list in some display tool, that raises another question of equal importance: what character encoding do you need for your particular display tool? If it's not utf8 (and especially if it is somehow different from the encoding used in the directories), then Encode will help with that as well.

(update -- One more thing: Instead of saying "without success", it would be much better to say "I expected to see this: ... But instead I got this: ..." And when posting code or data, remember to put <code> and </code> around them.)

  • Comment on Re: enumerating files on Windows with non-latin chars