[fpc-pascal] findfirst wildcards...

[Tomas Hajny]

On Wed, December 3, 2014 06:05, waldo kitty wrote:
> On 12/2/2014 5:12 PM, Bart wrote:
>> On 12/2/14, waldo kitty <wkitty42 at windstream.net> wrote:
>>>
>>> how do you process for multiple filemasks?
>>>
>>> eg: find ts??????.sel and t???.sel for the same processing run
>>
>> Maybe I misunderstand the question but:
>> Use '*' as mask for FindFirst/FindNext then use MatchesMaskList()?
>
> can you help me understand the differences in the output of the below
> program?
>
> given these three filenames: t.txt t1.txt t11.txt
>
> with mask  t?.txt  why does MatchesMaskList not show t.txt and t11.txt
> like
> plain findfirst?
 .
 .

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.

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.

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). Scanning
through all the files as suggested by Bart is the standard solution for
that. 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). 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).

Tomas