_findfirst, _findnext from win32?

_findfirst, _findnext from win32?

Post by Igor Bobal » Thu, 26 Oct 2000 04:00:00



Hi.

I'm porting some system routlines from win32 platform to linux. Is there are
some replacement for _findfirst, _findnext function? If not - how to solve
the problem?

--
Sincerely yours
Igor Bobalo.
-----------------------

 
 
 

_findfirst, _findnext from win32?

Post by Lew Pitch » Thu, 26 Oct 2000 04:00:00


On Wed, 25 Oct 2000 19:18:37 -0000, "Igor Bobalo"


>Hi.

>I'm porting some system routlines from win32 platform to linux. Is there are
>some replacement for _findfirst, _findnext function?

Not directly. opendir(), readdir() and family are the directory
functions (one flavour at least), but they don't support globing.

Quote:>If not - how to solve the problem?

What problem (<g>)?? Seriously, not having findfirst()/findnext()
hasn't caused any problem on Unix/Linux.

You might try the regexp package in combination with readdir()
function to emulate findfirst()/findnext(). However, it would probably
be better if you re-examine the assumptions behind and design of your
program in the light of the different facilities of Linux. Likely,
you'll find that you don't really need findfirst()/findnext().

Lew Pitcher
Information Technology Consultant
Toronto Dominion Bank Financial Group


(Opinions expressed are my own, not my employer's.)

 
 
 

_findfirst, _findnext from win32?

Post by Kaz Kylhe » Thu, 26 Oct 2000 04:00:00



>Hi.

>I'm porting some system routlines from win32 platform to linux. Is there are
>some replacement for _findfirst, _findnext function? If not - how to solve
>the problem?

You can snarf large chunks of the directory using the POSIX.1 getdents() (get
directory entries) function.

Also take a look at the POSIX.2 glob() function if you need to get a list of
path names that match a given shell regular expression pattern.

--
Any hyperlinks appearing in this article were inserted by the unscrupulous
operators of a Usenet-to-web gateway, without obtaining the proper permission
of the author, who does not endorse any of the linked-to products or services.

 
 
 

_findfirst, _findnext from win32?

Post by Kaz Kylhe » Thu, 26 Oct 2000 04:00:00



>On Wed, 25 Oct 2000 19:18:37 -0000, "Igor Bobalo"

>>Hi.

>>I'm porting some system routlines from win32 platform to linux. Is there are
>>some replacement for _findfirst, _findnext function?
>Not directly. opendir(), readdir() and family are the directory
>functions (one flavour at least), but they don't support globing.

Note that readdir() returns a pointer to static storage, so it is not thread
safe.  I recommend readdir_r() or getdents() in code that may need to be thread
safe in the future.
 
 
 

_findfirst, _findnext from win32?

Post by Lew Pitch » Thu, 26 Oct 2000 04:00:00





>>On Wed, 25 Oct 2000 19:18:37 -0000, "Igor Bobalo"

>>>Hi.

>>>I'm porting some system routlines from win32 platform to linux. Is there are
>>>some replacement for _findfirst, _findnext function?
>>Not directly. opendir(), readdir() and family are the directory
>>functions (one flavour at least), but they don't support globing.

>Note that readdir() returns a pointer to static storage, so it is not thread
>safe.  I recommend readdir_r() or getdents() in code that may need to be thread
>safe in the future.

I qualified readdir() as "one flavour of directory functions" because
I didn't have my references handy, and am in a CYA mode today <g>.

I'm pleased to learn that my memory isn't completely faulty, as I
would have hoped that you would correct me if I had misstated things.

I still maintain that, if a porting exercise becomes a task of
rewriting the environment from which the program is derived (i.e.
building a findfirst() equivalent), then there's something
questionable with the design or implementation of the program being
ported. Rather than "look for the equivalent" of a platform-specific
API, porting should "look for how" other implementations on the
platform usually solve the problem.

For instance, because MSDOS derivatives do not glob in the shell,
MSDOS programs have taken on the effort of performing the globbing
within their own code (i.e. TYPE *.TXT would result in TYPE.EXE
invoking the findfirst()/findnext() API). On Linux (as in Unix),
filename globbing is (typically) performed at the shell, and is
(usually) unnecessary within the program (i.e. cat *.txt would result
in the shell globbing *.txt into a list of filenames into the
commandstring before the program is executed, and 'cat' just looks
through a list of completed filenames). If someone were to port an
MSDOS program that used findfirst()/findnext() in this manner, then
the effort of emulating findfirst()/findnext() in Linux would be of
minimal benefit (I'd say no benefit at all) to the program.

Lew Pitcher
Information Technology Consultant
Toronto Dominion Bank Financial Group


(Opinions expressed are my own, not my employer's.)

 
 
 

_findfirst, _findnext from win32?

Post by Norman Blac » Thu, 26 Oct 2000 04:00:00


Quote:> For instance, because MSDOS derivatives do not glob in the shell,
> MSDOS programs have taken on the effort of performing the globbing
> within their own code (i.e. TYPE *.TXT would result in TYPE.EXE
> invoking the findfirst()/findnext() API). On Linux (as in Unix),
> filename globbing is (typically) performed at the shell, and is
> (usually) unnecessary within the program (i.e. cat *.txt would result

All fine and well as long as the wildcard match (glob) comes via the command
line, via the shell. What if the wild card is given some other way.
From a file, from a prompt in a dialog, or anything other than the shell
command line.

My own application has directory lists, and I search those. It is not worth
mentioning the details. I just use opendir...readdir_r...fnmatch...closedir.

Implementing a findfirst, findnext, findclose is a simple and portable way
to have code that runs on Unix and Microsoft platforms with no code changes,
other than obviously the implementation of the find API calls themselves. My
own code follows this approach. Nothing ever calls the operating system
directly,  since all such activity goes through an encapsulation.
File/directory access, sockets, threads, exec, redirection exec, memory
mapped files, shared memory, de* interface, and even all GUI all go
through encapsulations. No operating system types, constants or procedures
exist in the encapsulation interface. Most encapsulations are very thin and
trivial, some are not. Such encapsulations can also help in Unix <-> Unix
ports, since some differences can exist.

I personally would rather encapsulate than recode for each system.

--
Norman Black
Stony Brook Software
the reply, fubar => ix.netcom






> >>On Wed, 25 Oct 2000 19:18:37 -0000, "Igor Bobalo"

> >>>Hi.

> >>>I'm porting some system routlines from win32 platform to linux. Is
there are
> >>>some replacement for _findfirst, _findnext function?
> >>Not directly. opendir(), readdir() and family are the directory
> >>functions (one flavour at least), but they don't support globing.

> >Note that readdir() returns a pointer to static storage, so it is not
thread
> >safe.  I recommend readdir_r() or getdents() in code that may need to be
thread
> >safe in the future.

> I qualified readdir() as "one flavour of directory functions" because
> I didn't have my references handy, and am in a CYA mode today <g>.

> I'm pleased to learn that my memory isn't completely faulty, as I
> would have hoped that you would correct me if I had misstated things.

> I still maintain that, if a porting exercise becomes a task of
> rewriting the environment from which the program is derived (i.e.
> building a findfirst() equivalent), then there's something
> questionable with the design or implementation of the program being
> ported. Rather than "look for the equivalent" of a platform-specific
> API, porting should "look for how" other implementations on the
> platform usually solve the problem.

> For instance, because MSDOS derivatives do not glob in the shell,
> MSDOS programs have taken on the effort of performing the globbing
> within their own code (i.e. TYPE *.TXT would result in TYPE.EXE
> invoking the findfirst()/findnext() API). On Linux (as in Unix),
> filename globbing is (typically) performed at the shell, and is
> (usually) unnecessary within the program (i.e. cat *.txt would result
> in the shell globbing *.txt into a list of filenames into the
> commandstring before the program is executed, and 'cat' just looks
> through a list of completed filenames). If someone were to port an
> MSDOS program that used findfirst()/findnext() in this manner, then
> the effort of emulating findfirst()/findnext() in Linux would be of
> minimal benefit (I'd say no benefit at all) to the program.

> Lew Pitcher
> Information Technology Consultant
> Toronto Dominion Bank Financial Group


> (Opinions expressed are my own, not my employer's.)

 
 
 

_findfirst, _findnext from win32?

Post by Lew Pitch » Sat, 28 Oct 2000 21:27:41


On Wed, 25 Oct 2000 13:42:20 -0700, "Norman Black"


>> For instance, because MSDOS derivatives do not glob in the shell,
>> MSDOS programs have taken on the effort of performing the globbing
>> within their own code (i.e. TYPE *.TXT would result in TYPE.EXE
>> invoking the findfirst()/findnext() API). On Linux (as in Unix),
>> filename globbing is (typically) performed at the shell, and is
>> (usually) unnecessary within the program (i.e. cat *.txt would result

>All fine and well as long as the wildcard match (glob) comes via the command
>line, via the shell. What if the wild card is given some other way.
>From a file, from a prompt in a dialog, or anything other than the shell
>command line.

>My own application has directory lists, and I search those. It is not worth
>mentioning the details. I just use opendir...readdir_r...fnmatch...closedir.

Which is why my _first_ suggestion was to use those exact functions.

What I was also advocating was that the OP re-examine the need for a
findfirst()-like function, based on (a) the potential that it was
unnecessary in his Linux/Unix implementation, and (b) that Unix (and
Linux) programmers probably already had addressed this need in other
manners.

Porting code isn't just about "how do I get it to compile properly?".
It's also about "how do I ensure that the program is doing what it
should, in the manner it should?". I fully expect that the OP will
next ask what the Linux equivalent of the Windows Registry functions
are, without understanding that Linux does it differently.

Quote:>Implementing a findfirst, findnext, findclose is a simple and portable way
>to have code that runs on Unix and Microsoft platforms with no code changes,
>other than obviously the implementation of the find API calls themselves. My
>own code follows this approach. Nothing ever calls the operating system
>directly,  since all such activity goes through an encapsulation.
>File/directory access, sockets, threads, exec, redirection exec, memory
>mapped files, shared memory, de* interface, and even all GUI all go
>through encapsulations. No operating system types, constants or procedures
>exist in the encapsulation interface. Most encapsulations are very thin and
>trivial, some are not. Such encapsulations can also help in Unix <-> Unix
>ports, since some differences can exist.

>I personally would rather encapsulate than recode for each system.

Sure, I agree.

Personally, I would rather design a platform-independant approach,
implemented by encapsulation rather than retrofit the design approach
of one platform to facilities of another.

- Show quoted text -

>--
>Norman Black
>Stony Brook Software
>the reply, fubar => ix.netcom







>> >>On Wed, 25 Oct 2000 19:18:37 -0000, "Igor Bobalo"

>> >>>Hi.

>> >>>I'm porting some system routlines from win32 platform to linux. Is
>there are
>> >>>some replacement for _findfirst, _findnext function?
>> >>Not directly. opendir(), readdir() and family are the directory
>> >>functions (one flavour at least), but they don't support globing.

>> >Note that readdir() returns a pointer to static storage, so it is not
>thread
>> >safe.  I recommend readdir_r() or getdents() in code that may need to be
>thread
>> >safe in the future.

>> I qualified readdir() as "one flavour of directory functions" because
>> I didn't have my references handy, and am in a CYA mode today <g>.

>> I'm pleased to learn that my memory isn't completely faulty, as I
>> would have hoped that you would correct me if I had misstated things.

>> I still maintain that, if a porting exercise becomes a task of
>> rewriting the environment from which the program is derived (i.e.
>> building a findfirst() equivalent), then there's something
>> questionable with the design or implementation of the program being
>> ported. Rather than "look for the equivalent" of a platform-specific
>> API, porting should "look for how" other implementations on the
>> platform usually solve the problem.

>> For instance, because MSDOS derivatives do not glob in the shell,
>> MSDOS programs have taken on the effort of performing the globbing
>> within their own code (i.e. TYPE *.TXT would result in TYPE.EXE
>> invoking the findfirst()/findnext() API). On Linux (as in Unix),
>> filename globbing is (typically) performed at the shell, and is
>> (usually) unnecessary within the program (i.e. cat *.txt would result
>> in the shell globbing *.txt into a list of filenames into the
>> commandstring before the program is executed, and 'cat' just looks
>> through a list of completed filenames). If someone were to port an
>> MSDOS program that used findfirst()/findnext() in this manner, then
>> the effort of emulating findfirst()/findnext() in Linux would be of
>> minimal benefit (I'd say no benefit at all) to the program.

>> Lew Pitcher
>> Information Technology Consultant
>> Toronto Dominion Bank Financial Group


>> (Opinions expressed are my own, not my employer's.)

Lew Pitcher
Information Technology Consultant
Toronto Dominion Bank Financial Group


(Opinions expressed are my own, not my employer's.)