On 12/3/2014 6:16 AM, Tomas Hajny wrote:
Given the fact that OS/2 appeared in your listing, I can clarify the difference. It comes from the fact that in case of FindFirst/FindNext, the interpretation of wildcards is performed by the underlying operating system whereas the routine mentioned by Bart performs this interpretation inside the Pascal code. Equally to DOS (and actually implemented that way in an attempt to make OS/2 as compatible to DOS as possible), OS/2 is somewhat more "relaxed" in interpretation of question marks at the end of the file name (i.e. before the file extension) in the sense of evaluating question marks at that position (but not elsewhere) as either 1 _or_ no character.
right... i see this ""everywhere"" /except/ on native linux... even DOSEMU and similar that i have tested all see '?' as "0 or 1" character... even REGEX takes that approach :)
You get the same behaviour under DOS (either compiled with TP/BP or FPC) and also e.g. under DosEmu under Linux, etc. I believe that the MS Windows NTVDM implementation would not behave that way (i.e. I believe that the DOS window simply passes the request to MS Windows which perform the evaluation differently), but I haven't tried it.
cmd and command both see '?' as "0 or 1" character... C:\freepascal\projects\misc>command C:\FREEPA~1\PROJECTS\MISC>ver Microsoft Windows [Version 6.0.6002] C:\FREEPA~1\PROJECTS\MISC>dir t?.txt Volume in drive C is SQ004512V04 Volume Serial Number is DC02-9142 Directory of C:\FREEPA~1\projects\misc 12/02/2014 11:31 PM 2 t.txt 12/02/2014 11:31 PM 2 t1.txt 2 File(s) 4 bytes 0 Dir(s) 51,110,965,248 bytes free C:\FREEPA~1\PROJECTS\MISC>exit C:\FREEPA~1\projects\misc>cmd Microsoft Windows [Version 6.0.6002] Copyright (c) 2006 Microsoft Corporation. All rights reserved. C:\FREEPA~1\projects\misc>dir t?.txt Volume in drive C is SQ004512V04 Volume Serial Number is DC02-9142 Directory of C:\FREEPA~1\projects\misc 12/02/2014 11:31 PM 2 t.txt 12/02/2014 11:31 PM 2 t1.txt 2 File(s) 4 bytes 0 Dir(s) 51,111,006,208 bytes free C:\FREEPA~1\projects\misc>exit
Now regarding your original question - I don't think that you can ask the operating system to search for multiple masks at the same time (and thus the RTL does not provide such functionality directly either).
understood...
Scanning through all the files as suggested by Bart is the standard solution for that.
i didn't realize that that would be how it was done until after i started finding and reading relevant pages... when i started looking, i found nothing for plain FPC... everything was for delphi or lazarus...
However, _if_ you have reasons to be concerned about the performance of scanning through all the files (e.g. if running over a slow network drive and having to work with directories containing _many_ files - read: thousands of files at least), it is possible to reduce the number of operating system calls and network transfers by using the OS/2 API directly and providing it with a buffer sufficient for returning information about many files at once (e.g. one hundred of them, or whatever).
the most i've had to wade through was ~40000 files but i don't think that that will be much of a problem... it wasn't a problem with my previous simplistic finding and processing methods but i've recently removed the ""artificial"" file limits i had when using arrays... now i'm loading matching filenames into stringlists and then processing from there ;)
Obviously, your code would still need to go through all of them one by another, but it would decrease the overall time needed for processing this scan. Still, as already mentioned, this solution should not be necessary under normal conditions (and it would imply necessity of changing the implementation for other operating systems - unlike to using standard RTL functionality).
yeah, i'm looking for easy and simplistic cross-platform capability if i can get it... one of my projects is targetted at OS/2, winwhatever, and linux... they're all i can compile natively for... with that and the lack of lazarus on OS/2, i think the demo program i posted in my reply to jonas shows me the yellow brick road to follow to the emerald city... the hint came from bart and/or some older messages i found where it was stated that calling findfirst multiple times was a possibility... i think that (ff1) and/or the regex one i came up with (ff3) will work best for my needs...
i do also greatly appreciate bart's initial post and the subsequent ones from others... they got me started thinking clearer when i was blind and stuck before ;)
-- NOTE: No off-list assistance is given without prior approval. Please *keep mailing list traffic on the list* unless private contact is specifically requested and granted. _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal