[22890] in Perl-Users-Digest
Perl-Users Digest, Issue: 5111 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Jun 12 18:06:07 2003
Date: Thu, 12 Jun 2003 15:05:17 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Thu, 12 Jun 2003 Volume: 10 Number: 5111
Today's topics:
ANNOUNCE: List::Compare v0.2 <jkeen@concentric.net>
ANNOUNCE: Image::PBMlib 1.05 -- PBM/PGM/PPM image readi <*@eli.users.panix.com>
Converting a Python script to Perl (Otto Wyss)
Do it faster <ghostnr1@telia.com>
Re: Do it faster <usenet@dwall.fastmail.fm>
Re: Do it faster (Tad McClellan)
Re: Do it faster <ghostnr1@telia.com>
Re: Do it faster <matthew@weierophinney.net>
Re: Do it faster <drumspoorly@reachone.net>
Re: Do it faster (Randal L. Schwartz)
Re: Do it faster <emschwar@pobox.com>
Re: Do it faster <emschwar@pobox.com>
Re: Do it faster (Sam Holden)
Re: Do it faster <drumspoorly@reachone.net>
Re: Do it faster <ghostnr1@telia.com>
Do signal handlers cause automatic buffer flushing? (Carlton Brown)
exporting oracle query to excel using perl (Jessica)
Re: exporting oracle query to excel using perl <karabot@canada.com>
Re: exporting oracle query to excel using perl <karabot@canada.com>
Re: exporting oracle query to excel using perl <goedicke@goedsole.com>
fast way to determine empty directories <bmetcalf@nortelnetworks.com>
Re: fast way to determine empty directories <Juha.Laiho@iki.fi>
Re: fast way to determine empty directories <Wolfgang_.fischer@freenet.de>
Re: fast way to determine empty directories <bmetcalf@nortelnetworks.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 07 Jun 2003 12:43:52 GMT
From: "James E Keenan" <jkeen@concentric.net>
Subject: ANNOUNCE: List::Compare v0.2
Message-Id: <as2nr-qni.ln1@red.stonehenge.com>
*** post for FREE via your newsreader at post.newsfeed.com ***
Version 0.2 of Perl extension List::Compare is available from CPAN
(http://search.cpan.org/author/JKEENAN/List-Compare-0.2/) and CPAN mirrors.
Since the last uploaded version, additional methods have been added to
permit the user not only to compare lists with respect to intersection,
union, etc., but also to identify whether particular strings are members of
one or more lists. v0.2 also fixes some annoying carp messages that were
appearing when 'make test' was called.
Comments are welcome; please put "List::Compare" in your subject line.
Thank you very much.
-----= Posted via Newsfeed.Com, Uncensored Usenet News =-----
http://www.newsfeed.com - The #1 Newsgroup Service in the World!
-----== 100,000 Groups! - 19 Servers! - Unlimited Download! =-----
------------------------------
Date: Sat, 7 Jun 2003 00:05:25 +0000 (UTC)
From: Eli the Bearded <*@eli.users.panix.com>
Subject: ANNOUNCE: Image::PBMlib 1.05 -- PBM/PGM/PPM image reading functions
Message-Id: <2s2nr-h3o.ln1@red.stonehenge.com>
*** post for FREE via your newsreader at post.newsfeed.com ***
NAME
Image::PBMlib - Helper functions for PBM/PGM/PPM image
file formats
SYNOPSIS
use Image::PBMlib;
... open(PPM, "< image.ppm")...
my $ref = readppmheader(\*PPM);
my @pixels = readpixels_raw(\*PPM, $$ref{type},
($$ref{width} * $$ref{height}) );
my @pixels = readpixels_dec(\*PPM, $$ref{type},
($$ref{width} * $$ref{height}) );
my @rgb = hextriplettoraw("F00BA4");
my @rgb = dectriplettoraw("17:34:51");
my $header = makeppmheader($ref);
DESCRIPTION
This is primarily a library for reading portable bitmap
(PBM), portable graymap (PGM), and portable pixmap (PPM)
files. These image formats are only the barest step up
from raw data, and have a very simple format which is the
key to be "portable". Writing out images in these formats
is very easy.
Reading images in these formats is also easy, but not
quite "very easy". Proper reading of the file needs to
happen one byte at a time, since there is no fixed header
length. Headers can also contain comments, which must be
ignored. Then, once past the header, there are a total of
six different ways that the data might need to be read: a
raw and an ascii encoding of each image color level.
GET IT
This module is on or coming to a CPAN mirror near you now.
This is a pure perl module.
CHANGES
This version is a bug-fix version. Comments handling had been
seriously buggy, and certain file errors are better handled now.
Elijah
------
this time remembering the c.l.p.announce crosspost
-----= Posted via Newsfeed.Com, Uncensored Usenet News =-----
http://www.newsfeed.com - The #1 Newsgroup Service in the World!
-----== 100,000 Groups! - 19 Servers! - Unlimited Download! =-----
------------------------------
Date: Thu, 12 Jun 2003 22:34:36 +0200
From: otto.wyss@bluewin.ch (Otto Wyss)
Subject: Converting a Python script to Perl
Message-Id: <1fwgp3s.dyo1mnywjmrN%otto.wyss@bluewin.ch>
Does anybody know a program to convert a Python script to a Perl script?
All my researches only turn up a program to convert the other way. I
does not have to be perfect as long as the produced code is readable. If
possible I'd prefer a Windows version.
O. Wyss
--
See "http://wxguide.sourceforge.net/" for ideas how to design your app.
------------------------------
Date: Thu, 12 Jun 2003 18:13:41 GMT
From: "GhostNr1" <ghostnr1@telia.com>
Subject: Do it faster
Message-Id: <pp3Ga.11461$mU6.13902@newsb.telia.net>
I have this script
sub parse_form_data
{
local (*FORM_DATA) = @_;
local ( $request_method, $query_string, @key_value_pairs, $key_value, $key,
$value);
if ($ENV{'QUERY_STRING'})
{
$query_string = $ENV{'QUERY_STRING'};
}
if ($ENV{'REQUEST_METHOD'} eq "POST")
{
read (STDIN, $query_string2, $ENV{'CONTENT_LENGTH'});
$query_string = join ("&", $query_string, $query_string2);
print $query_string, "<br>";
}
@key_value_pairs = split (/&/, $query_string);
foreach $key_value (@key_value_pairs) {
($key, $value) = split (/=/, $key_value);
$value =~ tr/+/ /;
$value =~ s/%([\dA-Fa-f][\dA-Fa-f])/pack ("C", hex ($1))/eg;
if (defined($FORM_DATA{$key}))
{
$FORM_DATA{$key} = join ("\0", $FORM_DATA{$key}, $value);
}
else
{
$FORM_DATA{$key} = $value;
}
}
}
and call it with parse_form_data(*DATA); and get the info via
$DATA{'example'}
This is to retrive data from <input name="example" type="text" value="">
this text box.
the problem is it don't work if you use <form enctype="multipart/form-data">
I need to use this
binmode (STDIN);
read (STDIN, $upload_data, $ENV{'CONTENT_LENGTH'});
@Raw_Data = split (/-----------------------------.{9}/, $upload_data);
@File_Upload = split (/\n/, $Raw_Data[1], 5);
$test = $File_Upload[1];
while ($File_Upload[1] =~ /\\/)
{ $File_Upload[1] =~ s/^.*\\//; }
$File_Upload[1] =~ s/"//;
substr ($File_Upload[1], -1, 1, "");
substr ($File_Upload[3], -2, 2, "");
and I need to retrive 2 values both $File_Upload[1] and $File_Upload[4]
Can someone help me with this?
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.489 / Virus Database: 288 - Release Date: 6/10/2003
------------------------------
Date: Thu, 12 Jun 2003 18:43:13 -0000
From: "David K. Wall" <usenet@dwall.fastmail.fm>
Subject: Re: Do it faster
Message-Id: <Xns939895BE599A9dkwwashere@216.168.3.30>
GhostNr1 <ghostnr1@telia.com> wrote:
> I have this script
> sub parse_form_data
[other code snipped]
Don't reinvent the wheel. Use CGI.pm and save yourself much grief.
--
David K. Wall
------------------------------
Date: Thu, 12 Jun 2003 13:42:22 -0500
From: tadmc@augustmail.com (Tad McClellan)
Subject: Re: Do it faster
Message-Id: <slrnbehice.2vk.tadmc@magna.augustmail.com>
GhostNr1 <ghostnr1@telia.com> wrote:
> I have this script
> sub parse_form_data
That wheel has already been invented. Just use the existing wheel.
> local ( $request_method, $query_string, @key_value_pairs, $key_value, $key,
> $value);
This is a 7-year old Perl style. You knew that, right?
> Can someone help me with this?
use CGI;
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Thu, 12 Jun 2003 18:52:30 GMT
From: "GhostNr1" <ghostnr1@telia.com>
Subject: Re: Do it faster
Message-Id: <OZ3Ga.11465$mU6.14527@newsb.telia.net>
yes I knew it was old but not that old.
I use this only to learn. I need to understand what happend. If you use
cgi.pm you only get in some data and then you retrive some. What happen
between you don't know. That's why I do my own.
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.489 / Virus Database: 288 - Release Date: 6/10/2003
------------------------------
Date: Thu, 12 Jun 2003 19:00:07 GMT
From: Matthew Weier O'Phinney <matthew@weierophinney.net>
Subject: Re: Do it faster
Message-Id: <slrnbehjdm.1a6.matthew@kavalier.weierophinney.net>
* GhostNr1 <ghostnr1@telia.com>:
> yes I knew it was old but not that old.
> I use this only to learn. I need to understand what happend. If you use
> cgi.pm you only get in some data and then you retrive some. What happen
> between you don't know. That's why I do my own.
So look at CGI.pm or CGI::Simple and see what they do... ;-)
--
Matthew Weier O'Phinney
matthew@weierophinney.net
http://matthew.weierophinney.net
------------------------------
Date: Thu, 12 Jun 2003 12:56:40 -0700
From: Steve May <drumspoorly@reachone.net>
Subject: Re: Do it faster
Message-Id: <vehm9sbptd8ia5@corp.supernews.com>
Matthew Weier O'Phinney wrote:
> * GhostNr1 <ghostnr1@telia.com>:
>
>>yes I knew it was old but not that old.
>>I use this only to learn. I need to understand what happend. If you use
>>cgi.pm you only get in some data and then you retrive some. What happen
>>between you don't know. That's why I do my own.
>
>
> So look at CGI.pm or CGI::Simple and see what they do... ;-)
>
And that is a good thing to do, BUT.....
If you don't have a good feel for what the incoming query string looks
like, the code might not make a whole lot of sense.
If you made a little script that printed out %ENV and banged it from
a normal html form and a multi-part form data form you could see
what was being processed which would make the CGI code *much* easier to
understand.
There are a lot of issues to deal with in multi-part forms. Having
written my own upload routines, I can tell you that it is probably
not something you can do in a few minutes or even hours. Fun to
tinker with, but unless you have a really good reason for using a
home-rolled version you are almost certainly better off using CGI
for production scripts.
s.
------------------------------
Date: Thu, 12 Jun 2003 21:06:21 GMT
From: merlyn@stonehenge.com (Randal L. Schwartz)
Subject: Re: Do it faster
Message-Id: <74b6d3bbddb91ca7d4765d538e9d3c31@free.teranews.com>
>>>>> "Steve" == Steve May <drumspoorly@reachone.net> writes:
Steve> If you made a little script that printed out %ENV and banged it from
Steve> a normal html form and a multi-part form data form you could see
Steve> what was being processed which would make the CGI code *much* easier to
Steve> understand.
But why? Do you often play with multiplication by repeated addition
to "see what is being processed"?
Steve> There are a lot of issues to deal with in multi-part forms. Having
Steve> written my own upload routines, I can tell you that it is probably
Steve> not something you can do in a few minutes or even hours. Fun to
Steve> tinker with, but unless you have a really good reason for using a
Steve> home-rolled version you are almost certainly better off using CGI
Steve> for production scripts.
This seems to contradict your previous paragraph.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
------------------------------
Date: 12 Jun 2003 15:08:21 -0600
From: Eric Schwartz <emschwar@pobox.com>
Subject: Re: Do it faster
Message-Id: <etod6hjuhq2.fsf@wormtongue.emschwar>
merlyn@stonehenge.com (Randal L. Schwartz) writes:
> >>>>> "Steve" == Steve May <drumspoorly@reachone.net> writes:
> Steve> If you made a little script that printed out %ENV and banged it from
> Steve> a normal html form and a multi-part form data form you could see
> Steve> what was being processed which would make the CGI code *much* easier to
> Steve> understand.
>
> But why? Do you often play with multiplication by repeated addition
> to "see what is being processed"?
I'm not Steve, but no, I don't-- that's because I understand
multiplication. When I was 4 or 5, and just learning it, I did in
fact do repeated addition to verify it was the same thing as
multiplication. After I understood Likewise, I could see someone who is just learning
CGI programming wanting to understand how it works by writing some
homegrown parsing code.
> Steve> There are a lot of issues to deal with in multi-part forms. Having
> Steve> written my own upload routines, I can tell you that it is probably
> Steve> not something you can do in a few minutes or even hours. Fun to
> Steve> tinker with, but unless you have a really good reason for using a
> Steve> home-rolled version you are almost certainly better off using CGI
> Steve> for production scripts.
>
> This seems to contradict your previous paragraph.
Not at all-- there's a difference between doing something to see how
it works, and using that in a production system. I might play around
with assembling an engine from parts to see if I could, but I probably
wouldn't put it in a car and drive around in it. Likewise, I'd advise
anybody wishing to play around with CGI parsing for educational
purposes to go at it and have lots of fun, but to be DARNED sure to
use CGI.pm for anything real.
-=Eric
--
Come to think of it, there are already a million monkeys on a million
typewriters, and Usenet is NOTHING like Shakespeare.
-- Blair Houghton.
------------------------------
Date: 12 Jun 2003 15:10:49 -0600
From: Eric Schwartz <emschwar@pobox.com>
Subject: Re: Do it faster
Message-Id: <eto8ys7uhly.fsf@wormtongue.emschwar>
Eric Schwartz <emschwar@pobox.com> writes:
> I'm not Steve, but no, I don't-- that's because I understand
> multiplication. When I was 4 or 5, and just learning it, I did in
> fact do repeated addition to verify it was the same thing as
> multiplication. After I understood Likewise, I could see someone who is just learning
> CGI programming wanting to understand how it works by writing some
> homegrown parsing code.
Sorry to followup to myself; I posted in mid-edit. I meant to say:
After I understood it, I just used multiplication tables and stopped
doing it by hand. Likewise...
-=Eric
--
Come to think of it, there are already a million monkeys on a million
typewriters, and Usenet is NOTHING like Shakespeare.
-- Blair Houghton.
------------------------------
Date: 12 Jun 2003 21:15:04 GMT
From: sholden@flexal.cs.usyd.edu.au (Sam Holden)
Subject: Re: Do it faster
Message-Id: <slrnbehrao.gep.sholden@flexal.cs.usyd.edu.au>
On Thu, 12 Jun 2003 21:06:21 GMT,
Randal L. Schwartz <merlyn@stonehenge.com> wrote:
>>>>>> "Steve" == Steve May <drumspoorly@reachone.net> writes:
>
>Steve> If you made a little script that printed out %ENV and banged it from
>Steve> a normal html form and a multi-part form data form you could see
>Steve> what was being processed which would make the CGI code *much* easier to
>Steve> understand.
>
> But why? Do you often play with multiplication by repeated addition
> to "see what is being processed"?
Of course addition should be done via a ripple carry adder implemented
in perl.
For reasons I haven't worked out yet, my code is really slow...
--
Sam Holden
------------------------------
Date: Thu, 12 Jun 2003 14:56:52 -0700
From: Steve May <drumspoorly@reachone.net>
Subject: Re: Do it faster
Message-Id: <vehtb6euqmes7c@corp.supernews.com>
Randal L. Schwartz wrote:
>>>>>>"Steve" == Steve May <drumspoorly@reachone.net> writes:
>
>
> Steve> If you made a little script that printed out %ENV and banged it from
> Steve> a normal html form and a multi-part form data form you could see
> Steve> what was being processed which would make the CGI code *much* easier to
> Steve> understand.
>
> But why? Do you often play with multiplication by repeated addition
> to "see what is being processed"?
>
Ah.... no. But then I *think* I have a fairly firm grasp of
multiplication, probably because we did such things back
in grade school. :-)
Then too, if you are getting a result of x*y=42 it might be
illuminating to know that x=6 and y=7.
I mean, if x equalled 6 and y equalled 9, there might be
something fundamentally wrong. (cough)
> Steve> There are a lot of issues to deal with in multi-part forms. Having
> Steve> written my own upload routines, I can tell you that it is probably
> Steve> not something you can do in a few minutes or even hours. Fun to
> Steve> tinker with, but unless you have a really good reason for using a
> Steve> home-rolled version you are almost certainly better off using CGI
> Steve> for production scripts.
>
> This seems to contradict your previous paragraph.
>
Not really, at least in my mind. (such as it is)
It sounded like the OP wanted to understand what was going on with file
uploads. Cool, understanding the process is not that bad an idea IMHO.
And I remembered that CGI.pm's routines did NOT make a whole lot of
sense to me until I knew what the input being processed looked like.
Sure, I read the specs, but reading a description of
boundary strings and etc. vs actually looking at them, well....
one picture and all that...
We see it all the time in c.p.l.m where someone will post code
that parses some kind of input, but neglects to post any sample
input. Often, folks want to see what the input is/was before they'll
deal with it.
Go figure. :-)
Having said all that, I did want to tell the OP that for 99.999%
of uses, CGI.pm is a better deal for file uploads. Personally I
rarely use it, but that's me and I am well aware of the price
I pay.
s.
------------------------------
Date: Thu, 12 Jun 2003 21:56:49 GMT
From: "GhostNr1" <ghostnr1@telia.com>
Subject: Re: Do it faster
Message-Id: <BG6Ga.11495$mU6.14543@newsb.telia.net>
Okej you have convinced me. I should try to work with CGI.pm. Infakt I have
allready started to work with it. I'm glad I have been working so mutch
without it. It is so mutch easyer to understand what happends and how to use
it. Thx for all the comments.
But I think I should do like you steve and do some own when I have time.
thx again
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.489 / Virus Database: 288 - Release Date: 6/10/2003
------------------------------
Date: 12 Jun 2003 12:44:48 -0700
From: carltonbrown@hotmail.com (Carlton Brown)
Subject: Do signal handlers cause automatic buffer flushing?
Message-Id: <aa611a32.0306121144.73f8508c@posting.google.com>
I am finding that if I have a file handles generated by open2(), for
some reason a newline is written to the filehandle to the process.
Can anyone help me understand the reason for this behavior and how to
avoid or work around it?
I tried to reproduce this for a handle to a normal file and found that
the behavior doesn't occur. Is this just PERL's way of being
courteous to called programs, by flushing its buffers? If so, why
doesn't signal trapping disable such behavior? I've tried tweaking
$|, no luck there. The behavior is reproducible on more than one
signal (SIGINT SIGALRM SIGHUP) and on more than one perl version
(5.005_03, 5.6.1, OS Solaris 8).
I have isolated it down to this short perl script and a trivial shell
script. The perl script catches the input and sends it to the shell
script. The shell script reads its STDIN and writes it to an output
file called client.out. If you run it, you'll notice that all the
console input is written to the file, but if you control-C, you get
newlines (the $ symbol) written to the file where I'd expect nothing
at all to be written.
Thanks in advance!
#########################
# Body of calling script
#########################
#!/usr/bin/perl
use IPC::Open2;
# use warnings;
# use diagnostics;
$SIG{'INT'} = \&exitScript;
$cliProg = "client.sh 2> /dev/null";
&openClient($cliProg);
while (<STDIN>) {
$line = $_;
print "Got some STDIN - $line";
undef $line;
}
&exitScript();
sub openClient() {
my $shCmd = shift;
print "DEBUG: Starting $shCmd\n";
$pid = open2(SVREAD, SVWRITE, "$shCmd") or die "Couldn't open $shCmd
- $!";
$svread = *SVREAD;
$svwrite = *SVWRITE;
}
sub exitScript() {
print "\nDEBUG: Beginning exit sequence\n";
}
#######################
# Body of called script (client.sh)
#######################
#!/bin/ksh
# INT must be trapped here
trap `echo "signalled"` 2
echo "Beginning $0"
while true
do
read go?"Enter a command: "
if [ "$go" == "q" ]
then
break
fi
echo "`date` You entered: $go" | cat -vet | tee -a client.out
done
echo "Ending $0"
------------------------------
Date: 12 Jun 2003 10:51:57 -0700
From: msu_jessica@yahoo.com (Jessica)
Subject: exporting oracle query to excel using perl
Message-Id: <912de2af.0306120951.a8e352a@posting.google.com>
Has anyone ever used perl to query an oracle database and tried to
export that to an excel file? I am new to perl and could use any good
examples.
------------------------------
Date: Thu, 12 Jun 2003 14:11:41 -0400
From: "George Karabotsos" <karabot@canada.com>
Subject: Re: exporting oracle query to excel using perl
Message-Id: <yn3Ga.5103$JN6.851021@news20.bellglobal.com>
Try storing you result from the perl script into a tab-separated (it can be
any character) file, then use the Import Data File option of Excel to get
the data into a spreadsheat. Its actually quite simple to do.
"Jessica" <msu_jessica@yahoo.com> wrote in message
news:912de2af.0306120951.a8e352a@posting.google.com...
> Has anyone ever used perl to query an oracle database and tried to
> export that to an excel file? I am new to perl and could use any good
> examples.
------------------------------
Date: Thu, 12 Jun 2003 14:11:41 -0400
From: "George Karabotsos" <karabot@canada.com>
Subject: Re: exporting oracle query to excel using perl
Message-Id: <Pn3Ga.8671$0c4.878063@news20.bellglobal.com>
Try storing you result from the perl script into a tab-separated (it can be
any character) file, then use the Import Data File option of Excel to get
the data into a spreadsheat. Its actually quite simple to do.
"Jessica" <msu_jessica@yahoo.com> wrote in message
news:912de2af.0306120951.a8e352a@posting.google.com...
> Has anyone ever used perl to query an oracle database and tried to
> export that to an excel file? I am new to perl and could use any good
> examples.
------------------------------
Date: Thu, 12 Jun 2003 18:34:43 GMT
From: William Goedicke <goedicke@goedsole.com>
Subject: Re: exporting oracle query to excel using perl
Message-Id: <m3vfvbta9y.fsf@mail.goedsole.com>
Dear Jessica -
msu_jessica@yahoo.com (Jessica) writes:
> Has anyone ever used perl to query an oracle database and tried to
> export that to an excel file? I am new to perl and could use any
> good examples.
You should use the following modules:
use DBI;
use Text::CSV;
You'll have to install DBD::Oracle as well.
I don't have time to write out a custom example, but the documentation
in each module is excellent and come with examples.
Yours - Billy
============================================================
William Goedicke goedicke@goedsole.com
http://www.goedsole.com:8080
============================================================
Lest we forget:
The Computer Professional's Credo: "First do no harm."
- William Goedicke
------------------------------
Date: Thu, 12 Jun 2003 15:09:40 +0000 (UTC)
From: Brandon Metcalf <bmetcalf@nortelnetworks.com>
Subject: fast way to determine empty directories
Message-Id: <slrnbeh5pv.vc0.bmetcalf@cash.rhiamet.com>
I'm working on an algorithm where I have a list of files in various
directories and need to remove the directories if they are empty after
removing the files. One obvious way to do this would be to keep
directories in some data structure and once all of the files have been
removed do a opendir() and readdir() on each directory to determine if
the directory is empty and can be removed. However, for a large list
of directories this doesn't seem too efficient.
Is there a faster method of determining whether or not a directory is
empty?
Thanks,
Brandon
--
And let me tell you this. The older you do get, the more rules they're
going to try to get you to follow. You just gotta keep livin' man.
L.I.V.I.N. --Wooderson
------------------------------
Date: Thu, 12 Jun 2003 16:12:00 GMT
From: Juha Laiho <Juha.Laiho@iki.fi>
Subject: Re: fast way to determine empty directories
Message-Id: <bca8mn$8pv$1@ichaos.ichaos-int>
bmetcalf@nortelnetworks.com said:
>I'm working on an algorithm where I have a list of files in various
>directories and need to remove the directories if they are empty after
>removing the files. One obvious way to do this would be to keep
>directories in some data structure and once all of the files have been
>removed do a opendir() and readdir() on each directory to determine if
>the directory is empty and can be removed. However, for a large list
>of directories this doesn't seem too efficient.
>
>Is there a faster method of determining whether or not a directory is
>empty?
Hmm.. what kind of situation do you have -- are you expecting multi-level
removals - as in:
/d1/d2/d3/f1
... and need, after having removed f1, to remove d2 (and perhaps d1) in
addition to d3?
I'd attempt very much to keep the data in depth-sorted order, so that
from the above you'd have elements
/d1/d2/d3/f1
/d1/d2/d3
/d1/d2
/d1
... so that you know that all "deeper-level" elements (subdirectories
as well as files) are removed before the next element in list.
Then just attempt to remove everything in your list, in the list order -
ignoring elements you couldn't remove - or if needed, creating a log of
the elements you couldn't remove.
There might be some speedup if, upon finding that some element can't be
removed, you would also flag all the upper-level elements from this point
to be non-removable (so, if there f.ex. was /d1/d2/f2 that was not in your
remove list, then you wouldn't be able to remove /d1/d2 or /d1 -- so, when
getting the error when trying to remove /d1/d2, you could mark /d1 so that
you don't even attempt to remove it.
(and reaching here, I'm not certain whether or not this is portable for all
platforms, but shouldn't have any problems on Unix (-like) systems.
--
Wolf a.k.a. Juha Laiho Espoo, Finland
(GC 3.0) GIT d- s+: a C++ ULSH++++$ P++@ L+++ E- W+$@ N++ !K w !O !M V
PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++ y++++
"...cancel my subscription to the resurrection!" (Jim Morrison)
------------------------------
Date: Thu, 12 Jun 2003 18:17:29 +0200
From: Wolfgang Fischer <Wolfgang_.fischer@freenet.de>
Subject: Re: fast way to determine empty directories
Message-Id: <pan.2003.06.12.16.17.28.907499@freenet.de>
On Thu, 12 Jun 2003 15:09:40 +0000, Brandon Metcalf wrote:
>
> I'm working on an algorithm where I have a list of files in various
> directories and need to remove the directories if they are empty after
> removing the files. One obvious way to do this would be to keep
> directories in some data structure and once all of the files have been
> removed do a opendir() and readdir() on each directory to determine if
> the directory is empty and can be removed. However, for a large list
> of directories this doesn't seem too efficient.
Hi,
rmdir removes only empty directories. For more information, see perldoc -f
rmdir.
If you want to keep empty directories, you might simply recreate them
later.
>
> Is there a faster method of determining whether or not a directory is
> empty?
>
>
> Thanks,
> Brandon
------------------------------
Date: Thu, 12 Jun 2003 18:49:40 +0000 (UTC)
From: Brandon Metcalf <bmetcalf@nortelnetworks.com>
Subject: Re: fast way to determine empty directories
Message-Id: <slrnbehida.vc0.bmetcalf@cash.rhiamet.com>
Juha.Laiho@iki.fi writes:
> bmetcalf@nortelnetworks.com said:
> >I'm working on an algorithm where I have a list of files in various
> >directories and need to remove the directories if they are empty after
> >removing the files. One obvious way to do this would be to keep
> >directories in some data structure and once all of the files have been
> >removed do a opendir() and readdir() on each directory to determine if
> >the directory is empty and can be removed. However, for a large list
> >of directories this doesn't seem too efficient.
> >
> >Is there a faster method of determining whether or not a directory is
> >empty?
> Hmm.. what kind of situation do you have -- are you expecting multi-level
> removals - as in:
> /d1/d2/d3/f1
> ... and need, after having removed f1, to remove d2 (and perhaps d1) in
> addition to d3?
Exactly.
> I'd attempt very much to keep the data in depth-sorted order, so that
> from the above you'd have elements
> /d1/d2/d3/f1
> /d1/d2/d3
> /d1/d2
> /d1
> ... so that you know that all "deeper-level" elements (subdirectories
> as well as files) are removed before the next element in list.
> Then just attempt to remove everything in your list, in the list order -
> ignoring elements you couldn't remove - or if needed, creating a log of
> the elements you couldn't remove.
Yep, I had thought about this approache. I'll start with this and
optimize from there. Thanks.
Brandon
--
And let me tell you this. The older you do get, the more rules they're
going to try to get you to follow. You just gotta keep livin' man.
L.I.V.I.N. --Wooderson
------------------------------
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:
The Perl-Users Digest is a retransmission of the USENET newsgroup
comp.lang.perl.misc. For subscription or unsubscription requests, send
the single line:
subscribe perl-users
or:
unsubscribe perl-users
to almanac@ruby.oce.orst.edu.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
To request back copies (available for a week or so), send your request
to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
where x is the volume number and y is the issue number.
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 V10 Issue 5111
***************************************
