[32622] in Perl-Users-Digest
Perl-Users Digest, Issue: 3896 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat Mar 9 09:09:32 2013
Date: Sat, 9 Mar 2013 06:09:16 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Sat, 9 Mar 2013 Volume: 11 Number: 3896
Today's topics:
Existing module for file browser <jblack@nospam.com>
Re: Existing module for file browser <bjoern@hoehrmann.de>
Re: Existing module for file browser <news@lawshouse.org>
Re: getting perl and php to talk to each other <troffasky@hotmail.com>
Re: message forwarding in perl <ben@morrow.me.uk>
Re: message forwarding in perl <rweikusat@mssgmbh.com>
Re: moving class indepdent methods out of class definit <ben@morrow.me.uk>
Re: moving class indepdent methods out of class definit <rweikusat@mssgmbh.com>
Perl method dispatching (was: message forwarding in per <rweikusat@mssgmbh.com>
Re: Perl method dispatching <rweikusat@mssgmbh.com>
Return only the directories from readdir <tavantzi@gmail.com>
Re: Return only the directories from readdir <rweikusat@mssgmbh.com>
Re: Return only the directories from readdir <willem@turtle.stack.nl>
Re: Return only the directories from readdir <rweikusat@mssgmbh.com>
Re: Return only the directories from readdir <news@lawshouse.org>
Re: Return only the directories from readdir <tavantzi@gmail.com>
Re: Return only the directories from readdir (Alan Curry)
Re: Return only the directories from readdir <ben@morrow.me.uk>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 8 Mar 2013 15:37:56 -0600
From: John Black <jblack@nospam.com>
Subject: Existing module for file browser
Message-Id: <MPG.2ba41630411b4ea998976b@news.eternal-september.org>
Hi, I have some perl code that processes a file or files and I want an easy Windows familiar
way for the user to specify the filename. I.e. my users are not really into "command lines".
I have used Win32::GUI a little but I am looking for an off the shelf solution that someone
has hopefully done to allow the user to use the windows file browser or something like it to
traverse the directory tree, find their file and select it. This module would ideally just
return a scalar variable containing the filename with path and then my existing code can take
it from there. (extra credit to allow the user to select multiple filenames and have them
returned in an array...)
Does such a thing exist in the public domain? Thanks!
John Black
------------------------------
Date: Sat, 09 Mar 2013 12:19:35 +0100
From: Bjoern Hoehrmann <bjoern@hoehrmann.de>
Subject: Re: Existing module for file browser
Message-Id: <bh6mj8h38ehjhqkt7jh0lptg7iq0bs95e5@hive.bjoern.hoehrmann.de>
* John Black wrote in comp.lang.perl.misc:
>Hi, I have some perl code that processes a file or files and I want an easy Windows familiar
>way for the user to specify the filename. I.e. my users are not really into "command lines".
>
>I have used Win32::GUI a little but I am looking for an off the shelf solution that someone
>has hopefully done to allow the user to use the windows file browser or something like it to
>traverse the directory tree, find their file and select it. This module would ideally just
>return a scalar variable containing the filename with path and then my existing code can take
>it from there. (extra credit to allow the user to select multiple filenames and have them
>returned in an array...)
Sounds like you want one of the Win32:: modules that expose a standard
function like `GetOpenFileName`, Win32::GUI among them; there probably
is nothing considerably more off-the-shelf.
--
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
------------------------------
Date: Sat, 09 Mar 2013 13:25:26 +0000
From: Henry Law <news@lawshouse.org>
Subject: Re: Existing module for file browser
Message-Id: <c-2dnSTYWYHbpabMnZ2dnUVZ8tOdnZ2d@giganews.com>
On 08/03/13 21:37, John Black wrote:
> I have used Win32::GUI a little but I am looking for an off the shelf solution that someone
> has hopefully done to allow the user to use the windows file browser or something like it to
> traverse the directory tree, find their file and select it.
Perl Tk should be able to do this (but then Perl Tk can do anything if
you faff around long enough). There's a module called Tk::FileDialog
(in CPAN); the perldoc for it has sample code that you might be able to
adapt.
Warning: I've never tried this; just hoping to be of some help.
--
Henry Law Manchester, England
------------------------------
Date: Thu, 07 Mar 2013 19:09:21 +0000
From: alexd <troffasky@hotmail.com>
Subject: Re: getting perl and php to talk to each other
Message-Id: <khaoi9$6i8$1@dont-email.me>
Cal Dershowitz (for it is he) wrote:
> Struggling.
>
> $ php-config --libs
> No command 'php-config' found, did you mean:
> Command 'pdp-config' from package 'pd-pdp' (universe)
> Command 'php-config5' from package 'php5-dev' (main)
> php-config: command not found
I should think that anybody with a passing familiarity with package
management would be able to work out what this output is telling them.
--
<http://ale.cx/> (AIM:troffasky) (UnSoEsNpEaTm@ale.cx)
19:08:28 up 80 days, 21:40, 8 users, load average: 0.91, 1.21, 1.25
Qua illic est reprehendit, illic est a vindicatum
------------------------------
Date: Fri, 8 Mar 2013 01:27:06 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: message forwarding in perl
Message-Id: <acrn0a-0v3.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
> Another trivial thing I'm actually using: Can be implemented via
> AUTOLOAD. The fact that UNIVERSAL->can and AUTOLOAD don't play nice
> with each other is actually documented. Again, one has to wonder why
> someone asks for this and specifically mentions a documented technical
> limitation of the obvious answer to the question.
Yup, it's easy to do badly, and rather difficult to do well. Quite apart
from getting ->can, ->DOES and ->isa to work properly (and ->can is
harder than you think), things like overloading are definitely
non-trivial. And no matter what you do, you're going to lose all the
benefit of perl's method cache logic.
I never said it was impossible, I said Perl's OO system wasn't
particularly designed to make it easy. Perl thinks much more in terms of
'an object is a data structure with some functions attached to it' than
'an object is something you can send messages to'. I don't particularly
like this (for one thing, it makes classless objects and prototype-style
inheritance rather difficult to implement), but that happens to be what
we have to work with.
There are (or were... I've lost touch with what's been happening on p5p
recently) people who are trying to make this sort of thing easier, by
making it possible for a class to define its own method dispatch logic.
> Since ->can, like ->DOES and any other way of enabling subroutines
> which are not part of a class to make 'control flow descision' based
> on the 'type' of some object shouldn't really exist to begin with (the
> point of overloading is to eliminate explicit 'switching based on type
> fields'), that's a small cost to pay.
In simple situations you are right; but consider the case of a module
like Storable. Storable wants to make it possible for objects to
serialise themselves if they want to, but needs to fall back to the
generic serialisation if they don't. If Perl had generics this would be
easy: Storable provides the generic
multi sub Storable::store (Any) {...}
(this is Perl 6 syntax) and other modules can provide more
specifically-typed versions as they like. Since it doesn't, the only
alternatives are either to put the generic method in UNIVERSAL (not
exactly polite) or to use reflection (->can or ->DOES) to ask the object
if it wants to provide its own behaviour.
Ben
------------------------------
Date: Fri, 08 Mar 2013 13:54:04 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: message forwarding in perl
Message-Id: <87ppzat2tf.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
>> Another trivial thing I'm actually using: Can be implemented via
>> AUTOLOAD. The fact that UNIVERSAL->can and AUTOLOAD don't play nice
>> with each other is actually documented. Again, one has to wonder why
>> someone asks for this and specifically mentions a documented technical
>> limitation of the obvious answer to the question.
>
> Yup, it's easy to do badly, and rather difficult to do well.
At least for suitable definitions of 'done badly' and 'done well'. I'm
using this to attach somewhat 'enhanced' functionality to the DBI
database and statement classes. In both cases, the original DBI
object is stored in an instance variable of the object (Again an
an array reference. "One million flies can't be wrong[*]" isn't an
argument except if one is aspiring to become the lord of the flies by
election) and if a method the replacement object doesn't implement is
called, AUTOLOAD compiles a 'delegation method' of the same name which
invokes the method on the DBI object with the same arguments and calls
that.
That's a perfectly working solution to the problem which needed to be
solved in this case. It is very likely not a 'perfectly working' (or
any kind of) solution for a lot of other problems which are more or
less related to the situation I had to deal with, however, that's no
concern of mine at the moment.
A certain kind of (recreational) programmers (or people with
software-related jobs who have no real problems to deal with and way
to much time on their hands) is convinced that the combined
washer-dryer-lawnmower-bicycle-tophat-eggwarmer-hovercraft-theodolite
would be the pinnacle of 'good software design', however, that's not
how things are constructed in the real world and there are good reason
for that (such as usability [complicated solutions to simple problems
are a pain in the ass] and reliabiliy [complicated stuff breaks more
often than simple stuff and in much more complicated ways]).
Possibly offensive content below the page break.
[*] I'm unsure if this is a well-known idiom outside of the small
German country town I was born in, so I'll include it here: "Scheisse
schmeckt gut. Millionen Fliegen koennen nicht irren." In English, that
would be "Poo must be tasty. Millions of flies can't be wrong".
------------------------------
Date: Fri, 8 Mar 2013 00:16:32 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: moving class indepdent methods out of class definitions
Message-Id: <08nn0a-od3.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
> ... and into places where they can be reused by other classes,
> including the possibility to 'overload' them in derived classes (not
> necessarily sensible for class-independent code): Put them into a
> package which exports them. Import them into the class package. That's
> 'roles in a nutshell' and the answer is actually so trivial (and
> obvious) that I'm wondering why 'experienced perl programmers' ask
> such questions.
[If you are referring to me, I have made no claims to be an experienced
Perl programmer.]
That's doable, certainly, and is indeed a simple-minded implementation
of roles. Moose roles do rather more for you than that:
- They allow a role to require that a class consuming it implement
certain methods. (These methods can be implemented directly or
taken from other roles.) When combined with method modifiers this
can be a very powerful tool for allowing hooks into a complex
system. See Catalyst for an example.
- They allow a class to consume a role but also to provide its own
implementation of some of the methods provided by that role.
Methods provided directly by the class 'hide' those imported from
roles. Note that this does not break the role interface, since the
method still has to be implemented somewhere.
- The role system checks, at role-composing time, that there aren't
any conflicts between the methods provided by the roles used by a
given class. If there is a conflict the class needs to provide its
own implementation of that method to make the behaviour
deterministic.
- It is possible to apply one or more roles to an instance (an
object) rather than a class. This will create a new gensymmed
subclass of the object's current class, compose the given roles
into that new class, and rebless the object. Again, this can be a
very powerful way of adding new behaviour to existing objects.
You may be interested to read some of the papers by the people who
invented the concept (which they call 'traits'):
http://scg.unibe.ch/research/traits .
Ben
------------------------------
Date: Fri, 08 Mar 2013 18:41:41 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: moving class indepdent methods out of class definitions
Message-Id: <87vc91iviy.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
[...]
> Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
>> ... and into places where they can be reused by other classes,
>> including the possibility to 'overload' them in derived classes (not
>> necessarily sensible for class-independent code): Put them into a
>> package which exports them. Import them into the class package. That's
>> 'roles in a nutshell' and the answer is actually so trivial (and
>> obvious) that I'm wondering why 'experienced perl programmers' ask
>> such questions.
>
> [If you are referring to me, I have made no claims to be an experienced
> Perl programmer.]
>
> That's doable, certainly, and is indeed a simple-minded implementation
> of roles.
It is a way to move class independent code out of classes into
packages which enable this code to be used as methods by any class
which provides a 'suitable interface' for accessing 'instance state'
which works with plain Perl 5. I'll mark this as a 'possibly useful
idea' for future problems but so far, I haven't missed it.
------------------------------
Date: Fri, 08 Mar 2013 14:12:19 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Perl method dispatching (was: message forwarding in perl)
Message-Id: <87li9yt1z0.fsf_-_@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
[...]
> Perl thinks much more in terms of 'an object is a data structure
> with some functions attached to it' than 'an object is something you
> can send messages to'.
Perl is an abstract concept and it can't think anyhing. It is
conceivable that the people/person who designed Perl OO thought in
this way and the (probably) C++-inspired method invocation syntax
actually suggests this. But de facto, the Perl method dispatch
mechanism is a message-passing system in all but the name: Any
reference object can have a 'current message interpreter' attached
(this attachment can be changed at runtime) and while there's a
'default' method of locating a subroutine supposed to be executed in
response to a message (namely, look at the 'function slot' of the glob
which is presently associated with the message 'title' in the symbol
table of the 'interpreter' package), the 'interpreter package' can
implement an arbitrary 'other dispatching scheme' via AUTOLOAD.
This may be an unintentional side effect of a couple of design
descisions and possibly even one 'certain people' are not even aware
of, but "It's alive" and this property can be used.
------------------------------
Date: Fri, 08 Mar 2013 22:47:16 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Perl method dispatching
Message-Id: <87ip51ik5n.fsf@sapphire.mobileactivedefense.com>
Rainer Weikusat <rweikusat@mssgmbh.com> writes:
> Ben Morrow <ben@morrow.me.uk> writes:
>
> [...]
>
>> Perl thinks much more in terms of 'an object is a data structure
>> with some functions attached to it' than 'an object is something you
>> can send messages to'.
>
> Perl is an abstract concept and it can't think anyhing. It is
> conceivable that the people/person who designed Perl OO thought in
> this way and the (probably) C++-inspired method invocation syntax
> actually suggests this. But de facto, the Perl method dispatch
> mechanism is a message-passing system in all but the name: Any
> reference object can have a 'current message interpreter' attached
> (this attachment can be changed at runtime) and while there's a
> 'default' method of locating a subroutine supposed to be executed in
> response to a message (namely, look at the 'function slot' of the glob
> which is presently associated with the message 'title' in the symbol
> table of the 'interpreter' package), the 'interpreter package' can
> implement an arbitrary 'other dispatching scheme' via AUTOLOAD.
Further, and that's the actually crucial part: The way 'method lookup'
works is independent of the code trying to invoke the method, of
the 'object' which is used as invocant and of the 'current message
interpreter' attached to this object: A string which comes from the
invoking code is mapped to a subroutine by using the 'current
interpreter' (stash) property of the 'instance reference' to locate a
package and then searching for a subroutine with this name in the
symbol table of this package (and the symbol tables of the 'parent
package(s)'): Any code can invoke any method on any object.
------------------------------
Date: Thu, 7 Mar 2013 09:46:22 -0800 (PST)
From: Michael-John Tavantzis <tavantzi@gmail.com>
Subject: Return only the directories from readdir
Message-Id: <5bbe12dc-23d0-49d6-a02b-89cd937726f5@googlegroups.com>
There is a slowdown associated with reading the contents of a directory tha=
t contains large amounts of files. Since I am only interested in sub-direc=
tory names is there a way to return the directory names only and skip retur=
ning the files? Or quickly determine if there exists a sub-directory at le=
ast?=20
Here is the code i'm starting from... would have liked to be able to put a =
"-d" in front of readdir.
opendir(my $directory_handle, $directory) || die("Cannot open directory");
my @searchSet=3D readdir($directory_handle);
------------------------------
Date: Thu, 07 Mar 2013 17:52:59 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Return only the directories from readdir
Message-Id: <877glj9jwk.fsf@sapphire.mobileactivedefense.com>
Michael-John Tavantzis <tavantzi@gmail.com> writes:
> There is a slowdown associated with reading the contents of a
> directory that contains large amounts of files. Since I am only
> interested in sub-directory names is there a way to return the
> directory names only and skip returning the files? Or quickly
> determine if there exists a sub-directory at least?
>
> Here is the code i'm starting from... would have liked to be able to
> put a "-d" in front of readdir.
No. You actually need to go through the list of returned names and
test them one-by-one in order to determine which are _presently_[*]
directories.
[*] This doesn't mean they will still be directories by the time some
'other code' uses them, cf
http://cwe.mitre.org/data/definitions/367.html
------------------------------
Date: Thu, 7 Mar 2013 17:57:48 +0000 (UTC)
From: Willem <willem@turtle.stack.nl>
Subject: Re: Return only the directories from readdir
Message-Id: <slrnkjhl8s.4q.willem@turtle.stack.nl>
Michael-John Tavantzis wrote:
) There is a slowdown associated with reading the contents of a directory that contains large amounts of files. Since I am only interested in sub-directory names is there a way to return the directory names only and skip returning the files? Or quickly determine if there exists a sub-directory at least?
)
) Here is the code i'm starting from... would have liked to be able to put a "-d" in front of readdir.
)
) opendir(my $directory_handle, $directory) || die("Cannot open directory");
) my @searchSet= readdir($directory_handle);
This seems to work (note the slash at the end):
my @searchSet = glob("$directory/*/");
But I have no idea of its efficiency.
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
------------------------------
Date: Thu, 07 Mar 2013 18:12:59 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Return only the directories from readdir
Message-Id: <8738w79iz8.fsf@sapphire.mobileactivedefense.com>
Willem <willem@turtle.stack.nl> writes:
> Michael-John Tavantzis wrote:
> ) There is a slowdown associated with reading the contents of a directory that contains large amounts of files. Since I am only interested in sub-directory names is there a way to return the directory names only and skip returning the files? Or quickly determine if there exists a sub-directory at least?
> )
> ) Here is the code i'm starting from... would have liked to be able to put a "-d" in front of readdir.
> )
> ) opendir(my $directory_handle, $directory) || die("Cannot open directory");
> ) my @searchSet= readdir($directory_handle);
>
> This seems to work (note the slash at the end):
>
> my @searchSet = glob("$directory/*/");
>
> But I have no idea of its efficiency.
It still needs to read the complete directory.
------------------------------
Date: Thu, 07 Mar 2013 18:25:15 +0000
From: Henry Law <news@lawshouse.org>
Subject: Re: Return only the directories from readdir
Message-Id: <XYqdnbYJD6MRRqXMnZ2dnUVZ7v-dnZ2d@giganews.com>
On 07/03/13 17:46, Michael-John Tavantzis wrote:
> There is a slowdown associated with reading the contents of a directory that contains large amounts of files. Since I am only interested in sub-directory names is there a way to return the directory names only and skip returning the files? Or quickly determine if there exists a sub-directory at least?
>
> Here is the code i'm starting from... would have liked to be able to put a "-d" in front of readdir.
I can see your need but, thinking about how the OS is doing this, I
doubt there's anything to be done. Directories (in Linux and
DOS/Windows at any rate) are just files, with a bit set in the file
descriptor to say that they're a directory. No sub-directory contains
any information as to whether any other file in the same directory is
also a sub-directory, or for that matter whether any of the files in the
containing directory are themselves directories.
So I'd doubt very much if the OS has any way of finding sub-directories
other than reading every entry and deciding there and then whether or
not it's a sub-directory.
I'm open to contradiction, though: this is entirely theoretical. And
some less-common OS's (IBM MVS (z/OS) or VM (z/VM), maybe) did their
disk management in different ways; it's possible that they maintained a
separate index of directories and sub-directories, which would allow
Perl to enumerate them directly.
--
Henry Law Manchester, England
------------------------------
Date: Thu, 7 Mar 2013 10:58:53 -0800 (PST)
From: Michael-John Tavantzis <tavantzi@gmail.com>
Subject: Re: Return only the directories from readdir
Message-Id: <8a3cf4f5-df67-4bc2-800c-aed69d12723f@googlegroups.com>
On Thursday, March 7, 2013 1:25:15 PM UTC-5, Henry Law wrote:
> On 07/03/13 17:46, Michael-John Tavantzis wrote:
>=20
> > There is a slowdown associated with reading the contents of a directory=
that contains large amounts of files. Since I am only interested in sub-d=
irectory names is there a way to return the directory names only and skip r=
eturning the files? Or quickly determine if there exists a sub-directory a=
t least?
>=20
> >
>=20
> > Here is the code i'm starting from... would have liked to be able to pu=
t a "-d" in front of readdir.
>=20
>=20
>=20
> I can see your need but, thinking about how the OS is doing this, I=20
>=20
> doubt there's anything to be done. Directories (in Linux and=20
>=20
> DOS/Windows at any rate) are just files, with a bit set in the file=20
>=20
> descriptor to say that they're a directory. No sub-directory contains=20
>=20
> any information as to whether any other file in the same directory is=20
>=20
> also a sub-directory, or for that matter whether any of the files in the=
=20
>=20
> containing directory are themselves directories.
>=20
>=20
>=20
> So I'd doubt very much if the OS has any way of finding sub-directories=
=20
>=20
> other than reading every entry and deciding there and then whether or=20
>=20
> not it's a sub-directory.
>=20
>=20
>=20
> I'm open to contradiction, though: this is entirely theoretical. And=20
>=20
> some less-common OS's (IBM MVS (z/OS) or VM (z/VM), maybe) did their=20
>=20
> disk management in different ways; it's possible that they maintained a=
=20
>=20
> separate index of directories and sub-directories, which would allow=20
>=20
> Perl to enumerate them directly.
Yes, that's what I was hoping for, or at least for the OS to have the folde=
rs and files sorted, so there was a way of doing this. Thank you for the r=
eplies.
>=20
>=20
>=20
> --=20
>=20
>=20
>=20
> Henry Law Manchester, England
------------------------------
Date: Thu, 7 Mar 2013 18:59:19 +0000 (UTC)
From: pacman@kosh.dhis.org (Alan Curry)
Subject: Re: Return only the directories from readdir
Message-Id: <khao27$2pe$1@speranza.aioe.org>
In article <5bbe12dc-23d0-49d6-a02b-89cd937726f5@googlegroups.com>,
Michael-John Tavantzis <tavantzi@gmail.com> wrote:
>There is a slowdown associated with reading the contents of a directory
>that contains large amounts of files. Since I am only interested in
>sub-directory names is there a way to return the directory names only
>and skip returning the files? Or quickly determine if there exists a
>sub-directory at least?
The last question does have an answer for unix filesystems: the link count of
a directory is 2 plus the number of subdirectories. The first 2 links are the
directory's name in its parent and its own ".", the rest are the ".." links
from the children.
perl -e '
opendir(my $d, "/tmp") or die $!;
my $subdirs = (stat $d)[3] - 2;
print "/tmp has $subdirs subdirs\n"'
You don't need to look for subdirectories if (stat $dirhandle)[3]-2==0, if
you can be sure that the filesystem is proper unix, not FAT or anything else
weird.
Some systems provide a d_type field in struct dirent, which allows you to
find out which returned items are directories without stat'ing them. This
would speed up your search because it means you don't have to read the
inodes. And it has a clean failure mode on unsupported filesystems, so you
can fall back to stat and not worry about breakage when that unexpected FAT
filesystem shows up.
I see there's an IO::Dirent module which provides access to the d_type
feature in perl.
--
Alan Curry
------------------------------
Date: Thu, 7 Mar 2013 23:15:56 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Return only the directories from readdir
Message-Id: <cmjn0a-eo2.ln1@anubis.morrow.me.uk>
Quoth Henry Law <news@lawshouse.org>:
> On 07/03/13 17:46, Michael-John Tavantzis wrote:
> > There is a slowdown associated with reading the contents of a
> directory that contains large amounts of files. Since I am only
> interested in sub-directory names is there a way to return the directory
> names only and skip returning the files? Or quickly determine if there
> exists a sub-directory at least?
> >
> > Here is the code i'm starting from... would have liked to be able to
> put a "-d" in front of readdir.
>
> I can see your need but, thinking about how the OS is doing this, I
> doubt there's anything to be done. Directories (in Linux and
> DOS/Windows at any rate) are just files, with a bit set in the file
> descriptor to say that they're a directory. No sub-directory contains
> any information as to whether any other file in the same directory is
> also a sub-directory, or for that matter whether any of the files in the
> containing directory are themselves directories.
>
> So I'd doubt very much if the OS has any way of finding sub-directories
> other than reading every entry and deciding there and then whether or
> not it's a sub-directory.
On BSD systems (including Mac OS X) readdir(3) returns the type of a
file along with the names, meaning you can find the subdirs without
needing to stat every entry. The core perl readdir function doesn't
return this information, but there is an IO::Dirent module which does.
Ben
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 3896
***************************************
