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
