[17958] in Perl-Users-Digest
Perl-Users Digest, Issue: 118 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Jan 22 14:05:46 2001
Date: Mon, 22 Jan 2001 11:05:17 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Message-Id: <980190317-v10-i118@ruby.oce.orst.edu>
Content-Type: text
Perl-Users Digest Mon, 22 Jan 2001 Volume: 10 Number: 118
Today's topics:
Re: Assistance in Oz <jhall@ifxonline.com>
Re: Deleting a line from file <mischief@velma.motion.net>
Re: Directory Recursion Problem. <sdmeisner@SPAMGUARDyahoo.com>
Re: Directory Recursion Problem. (Rafael Garcia-Suarez)
Re: Directory Recursion Problem. <sdmeisner@SPAMGUARDyahoo.com>
Re: Directory Recursion Problem. (Anno Siegel)
Re: Directory Recursion Problem. (Anno Siegel)
Re: Directory Recursion Problem. (Martien Verbruggen)
Re: Directory Recursion Problem. <sdmeisner@SPAMGUARDyahoo.com>
Re: Directory Recursion Problem. (Martien Verbruggen)
Re: Directory Recursion Problem. <dajh101@yahoo.co.uk>
Re: Directory Recursion Problem. <sdmeisner@SPAMGUARDyahoo.com>
Re: Directory Recursion Problem. <aqumsieh@hyperchip.com>
DOS commands with long directory names lbieg@my-deja.com
Re: DOS commands with long directory names <sdmeisner@SPAMGUARDyahoo.com>
Re: DOS commands with long directory names <bart.lateur@skynet.be>
embedded perl in korn shell j355@my-deja.com
full-jeopardy, was Re: Directory Recursion Problem. <flavell@mail.cern.ch>
hash table <boussard@my-deja.com>
Re: How to debug memory leak in a perl script? (Stan Brown)
Re: How to turn 'die' in 'warn' on the fly <bart.lateur@skynet.be>
Digest Administrivia (Last modified: 16 Sep 99) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 22 Jan 2001 18:01:46 GMT
From: "John Hall" <jhall@ifxonline.com>
Subject: Re: Assistance in Oz
Message-Id: <eA_a6.23220$VA.466938@news1.rdc1.sdca.home.com>
laptops...
john hall
http://moron.shutdown.com
"Merlin" <robert@chalmers.com.au> wrote
> > of intellectual property floating around. Does anyone know a top
> > shelf programmer wishing to live the high life in Australia (beaches,
food
> > and wine, friendly people)
>
> and what programmer worth his salt is going to have time for any of that
> anyway.... :-)
>
------------------------------
Date: Mon, 22 Jan 2001 18:55:41 -0000
From: Chris Stith <mischief@velma.motion.net>
Subject: Re: Deleting a line from file
Message-Id: <t6p0hdh1fkivcd@corp.supernews.com>
Jeffrey Grace <gracenews@optusnet.com.au> wrote:
> "Tad McClellan" <tadmc@augustmail.com> wrote in message
> news:slrn96ljop.gb2.tadmc@tadmc26.august.net...
>> Jeffrey Grace <gracenews@optusnet.com.au> wrote:
>> >"Tad McClellan" <tadmc@augustmail.com> wrote in message
>> >news:slrn96j61l.9cm.tadmc@tadmc26.august.net...
> <snip>
>> >I wich to delete a line of text from a file, but there is a brief period
>> >where the file will not exist, and an open (FH, > file) will re-create a
>> >blank version.
>>
>>
>> I think you are saying that you want a _real_ in-place edit, that is,
>> you want the new file to have the same inode number as the original
>> file. Would that solve your problem?
> basically yes. Or any other method that can do the equivalent of keeping a
> file locked during the removal of a line of text.
> [snip]
[snip]
>> > open (FH, file) || open (FH, file), etc || die (message).
>> >
>> >Is there a better way?
until( open( FH, file ) ) {
}
or maybe this, which uses 4-arg select to do a less-than-second sleep:
until( open( FH, file ) ) {
select( undef, undef, undef, 0.25 );
}
Of course, this can become an infinite loop under some circumstances,
so I make it give up after a while.
my $open_try_counter = 0;
until( open ( FH, file ) ) {
select( undef, undef, undef, 0.5 );
$open_try_counter++;
if( $open_try_counter == 20 ) {
die "Could not open file";
}
}
> In this I was wondering if there was a way to make the script
> block while it waited for the file to exist. I do not wish to
> manually check for existence (eg: using -e) since this is
> non atomic.
The above is used in a few of my more mission-critical programs
where file opening must not fail. The exact example I give using
the counter gives up after not having opened the file for 10
seconds (the number of the counter * fraction of a second specified
in select() ). I've also used sleep() if the wait should be in
whole seconds.
This does get the same effect as blocking until the file can be
opened, except it's not really blocking (well, select does block,
but that's not what we're using it for).
This method, admittedly, uses some BFI, but it gets the job done.
I only use it for things such as log files and such that must not
fail.
> I was hoping not to have to put the file into memory as it is a CGI script
> and I'm worried about annoying the sysadmin, and getting my script deleted.
Always good to keep the sysadmin in mind. ;)
[snip quoted signature]
Didn't someone just ask that you didn't quote signatures?
Chris
--
Christopher E. Stith
Where there's a will, there's a lawyer.
------------------------------
Date: Mon, 22 Jan 2001 16:31:26 GMT
From: "Sean Meisner" <sdmeisner@SPAMGUARDyahoo.com>
Subject: Re: Directory Recursion Problem.
Message-Id: <yfZa6.54$LQ1.22667@sapphire.mtt.net>
The DIRHANDLE you're using to open each directory is a global..
meaning, each time you recurse it gets overwritten.. you need to
work with localized copies of DIR to preserve its state at all levels of
recursion.. say
local(*DIR);
as the first line of indexDir to make a local copy of the DIR typeglob
each time indexDir is called.
David Harrigan <dajh101@yahoo.co.uk> wrote in message
news:94hkg6$4br$1@soap.pipex.net...
> Hiya,
>
> Consider the following snippet. Can anyone tell me why it fails?
> (assume that there is a root directory with a load of subdirs. The perl
> script is in the root directory)
>
> #!/usr/bin/perl -w
> $defaultLoc = ".";
>
> indexDir($defaultLoc);
>
> sub indexDir {
> opendir DIR, $_[0] || die "Can't open $defaultLoc !!";
> foreach $subdir (sort readdir DIR) {
> print "$subdir\n";
> if(chdir $subdir) {
> indexDir($subdir);
> }
> }
> closedir DIR;
> }
>
>
>
>
------------------------------
Date: Mon, 22 Jan 2001 16:46:23 GMT
From: rgarciasuarez@free.fr (Rafael Garcia-Suarez)
Subject: Re: Directory Recursion Problem.
Message-Id: <slrn96oovq.3ke.rgarciasuarez@rafael.kazibao.net>
Sean Meisner wrote in comp.lang.perl.misc:
> The DIRHANDLE you're using to open each directory is a global..
> meaning, each time you recurse it gets overwritten.. you need to
> work with localized copies of DIR to preserve its state at all levels of
> recursion.. say
>
> local(*DIR);
>
> as the first line of indexDir to make a local copy of the DIR typeglob
> each time indexDir is called.
Yes, true. But, instead of maintaining a stack of open dirhandles,
it's better to close it before calling recursively the function again.
System resources are not unlimited.
PS. Please reply _after_ the text you're quoting. This is more readable,
esp. in long threads.
--
Rafael Garcia-Suarez / http://rgarciasuarez.free.fr/
print map substr($_,7).&$_, grep defined &$_, sort values %::;
sub Just {" another "}; sub Perl {" hacker,\n"};
------------------------------
Date: Mon, 22 Jan 2001 16:56:20 GMT
From: "Sean Meisner" <sdmeisner@SPAMGUARDyahoo.com>
Subject: Re: Directory Recursion Problem.
Message-Id: <UCZa6.61$LQ1.24556@sapphire.mtt.net>
Heh, agree with your point about closing the dirhandle, disagree
with your quoting preference.. I'd rather have the new text right at
the top and then if I need to refer to previous messages in the
quoted text, I'll scroll down, rather than being forced every time to
scroll through quoted text I don't need to look at..
Rafael Garcia-Suarez <rgarciasuarez@free.fr> wrote in message
news:slrn96oovq.3ke.rgarciasuarez@rafael.kazibao.net...
> Sean Meisner wrote in comp.lang.perl.misc:
> > The DIRHANDLE you're using to open each directory is a global..
> > meaning, each time you recurse it gets overwritten.. you need to
> > work with localized copies of DIR to preserve its state at all levels of
> > recursion.. say
> >
> > local(*DIR);
> >
> > as the first line of indexDir to make a local copy of the DIR typeglob
> > each time indexDir is called.
>
> Yes, true. But, instead of maintaining a stack of open dirhandles,
> it's better to close it before calling recursively the function again.
> System resources are not unlimited.
>
> PS. Please reply _after_ the text you're quoting. This is more readable,
> esp. in long threads.
>
> --
> Rafael Garcia-Suarez / http://rgarciasuarez.free.fr/
> print map substr($_,7).&$_, grep defined &$_, sort values %::;
> sub Just {" another "}; sub Perl {" hacker,\n"};
------------------------------
Date: 22 Jan 2001 16:57:19 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: Directory Recursion Problem.
Message-Id: <94hopf$7aq$1@mamenchi.zrz.TU-Berlin.DE>
David Harrigan <dajh101@yahoo.co.uk> wrote in comp.lang.perl.misc:
>Hiya,
>
>Consider the following snippet. Can anyone tell me why it fails?
Fails how? While it is commendable to include runnable code, it
would be nice if we didn't *have* to run it to find out what's
wrong.
It turns out that it recurses endlessly on '.' on my Unix machine.
But that's only part of the problem.
>(assume that there is a root directory with a load of subdirs. The perl
>script is in the root directory)
>
>#!/usr/bin/perl -w
use strict; # That should be here.
>$defaultLoc = ".";
>
>indexDir($defaultLoc);
>
>sub indexDir {
> opendir DIR, $_[0] || die "Can't open $defaultLoc !!";
You are quoting the wrong variable in your error message. In
recursive calls it will try to open other directories. It should
be $_[ 0], or better a decently named variable. I'll assume
"my $dir = shift;" in further comments.
> foreach $subdir (sort readdir DIR) {
next if $subdir =~ /^\.\.?$/; # we don't want to recurse on those
> print "$subdir\n";
> if(chdir $subdir) {
The chdir here will never work. Well, except under extraordinary
circumstances, when it will do the wrong thing. As your variable
name clearly points out, $subdir is a subdirectory, but of $dir, not
your current directory, so chdir will fail. Instead of (trying
to) chdir to $subdir in the loop, chdir to $dir before the loop.
Then you have the right situation for the recursive call: The directory
to indexDir() is in the current directory of the process.
> indexDir($subdir);
The recursive call will leave the current directory of the process
changed to something unexpected, unless you change the directory
back. It also re-opens the DIR filehandle, perhaps multiple times.
> }
> }
chdir '..'; # Unix-centric way of changing the directory back
# can be done outside of the loop
> closedir DIR;
This closes some directory, but often not the one originally
opened. It would be clearer to catch the directory contents
in an array and close the directory before the recursive call,
though that probably isn't critical.
>}
As you can see, there are lots of reasons why the routine doesn't
do what it is presumably expected to do. File system traversal
is remarkably tricky and gets more so if you want to be portable.
If you want this for production code, you're certainly better off
using the standard module File::Find. If it's for training, well
try again. I don't claim to have I spotted all bugs in your
program, actually I'm sure I've missed one or two.
Anno
------------------------------
Date: 22 Jan 2001 17:02:46 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: Directory Recursion Problem.
Message-Id: <94hp3m$7aq$2@mamenchi.zrz.TU-Berlin.DE>
Sean Meisner <sdmeisner@SPAMGUARDyahoo.com> wrote in comp.lang.perl.misc:
>Heh, agree with your point about closing the dirhandle, disagree
>with your quoting preference.. I'd rather have the new text right at
>the top and then if I need to refer to previous messages in the
>quoted text, I'll scroll down, rather than being forced every time to
>scroll through quoted text I don't need to look at..
Your personal preference aside, what matters here are the local
customs of the group, and the not-so-local Usenet customs in
general. Both are clearly in favor of a top-down-readable posting
style.
Anno
[jeopardy-quoted un-trimmed article deleted]
------------------------------
Date: Tue, 23 Jan 2001 04:01:07 +1100
From: mgjv@tradingpost.com.au (Martien Verbruggen)
Subject: Re: Directory Recursion Problem.
Message-Id: <slrn96opqj.bgr.mgjv@martien.heliotrope.home>
On Mon, 22 Jan 2001 16:46:23 GMT,
Rafael Garcia-Suarez <rgarciasuarez@free.fr> wrote:
> Sean Meisner wrote in comp.lang.perl.misc:
>> The DIRHANDLE you're using to open each directory is a global..
>> meaning, each time you recurse it gets overwritten.. you need to
>> work with localized copies of DIR to preserve its state at all levels of
>> recursion.. say
>>
>> local(*DIR);
>>
>> as the first line of indexDir to make a local copy of the DIR typeglob
>> each time indexDir is called.
>
> Yes, true. But, instead of maintaining a stack of open dirhandles,
> it's better to close it before calling recursively the function again.
> System resources are not unlimited.
Local file and directory handles outomatically get closed on exit of the
block to which they are scoped.
Martien
--
Martien Verbruggen |
Interactive Media Division |
Commercial Dynamics Pty. Ltd. | Curiouser and curiouser, said Alice.
NSW, Australia |
------------------------------
Date: Mon, 22 Jan 2001 17:32:02 GMT
From: "Sean Meisner" <sdmeisner@SPAMGUARDyahoo.com>
Subject: Re: Directory Recursion Problem.
Message-Id: <m8_a6.67$LQ1.27269@sapphire.mtt.net>
Anno Siegel <anno4000@lublin.zrz.tu-berlin.de> wrote in message
news:94hp3m$7aq$2@mamenchi.zrz.TU-Berlin.DE...
> Sean Meisner <sdmeisner@SPAMGUARDyahoo.com> wrote in comp.lang.perl.misc:
> >Heh, agree with your point about closing the dirhandle, disagree
> >with your quoting preference.. I'd rather have the new text right at
> >the top and then if I need to refer to previous messages in the
> >quoted text, I'll scroll down, rather than being forced every time to
> >scroll through quoted text I don't need to look at..
>
> Your personal preference aside, what matters here are the local
> customs of the group, and the not-so-local Usenet customs in
> general. Both are clearly in favor of a top-down-readable posting
> style.
>
> Anno
>
> [jeopardy-quoted un-trimmed article deleted]
Ok fine, standards compliance wins over efficiency :o)
Cheers,
Sean
------------------------------
Date: Tue, 23 Jan 2001 05:06:24 +1100
From: mgjv@tradingpost.com.au (Martien Verbruggen)
Subject: Re: Directory Recursion Problem.
Message-Id: <slrn96otl0.bgr.mgjv@martien.heliotrope.home>
On Mon, 22 Jan 2001 17:32:02 GMT,
Sean Meisner <sdmeisner@SPAMGUARDyahoo.com> wrote:
> Anno Siegel <anno4000@lublin.zrz.tu-berlin.de> wrote in message
> news:94hp3m$7aq$2@mamenchi.zrz.TU-Berlin.DE...
>> Sean Meisner <sdmeisner@SPAMGUARDyahoo.com> wrote in comp.lang.perl.misc:
>> >Heh, agree with your point about closing the dirhandle, disagree
>> >with your quoting preference.. I'd rather have the new text right at
>> >the top and then if I need to refer to previous messages in the
>> >quoted text, I'll scroll down, rather than being forced every time to
>> >scroll through quoted text I don't need to look at..
>>
>> Your personal preference aside, what matters here are the local
>> customs of the group, and the not-so-local Usenet customs in
>> general. Both are clearly in favor of a top-down-readable posting
>> style.
>>
>> Anno
>>
>> [jeopardy-quoted un-trimmed article deleted]
>
> Ok fine, standards compliance wins over efficiency :o)
It is _not_ efficient to top-post. It is only efficient for _you_. It is
inefficient when seen in the larger context of the newsgroup. It is
selfish to call something that saves you three seconds but costs
hundreds of other people more than three seconds efficient.
If you had read the group a littlebit before posting, then you wouldn't
have needed this personal explanation about why top posting in this
group is discouraged. You would have known, because we rehash this same
argument several times a week.
I am going to killfile outlook express for good now. I'm just sick of
the attitude that comes with it.
Martien
--
Martien Verbruggen |
Interactive Media Division | I took an IQ test and the results
Commercial Dynamics Pty. Ltd. | were negative.
NSW, Australia |
------------------------------
Date: Mon, 22 Jan 2001 18:14:59 -0000
From: "David Harrigan" <dajh101@yahoo.co.uk>
Subject: Re: Directory Recursion Problem.
Message-Id: <94ht8r$7ks$1@devel.uklinux.net>
Dear All,
Thanks very much for all your comments. I am indeed, learning
perl and well, sorry for the mistakes :-) I'll try and put your
suggestions into practice. Some other clean-ups:-
fails (should have been clearer here). It runs, on my Linux
and Windows box (gotta love portability) but it produces an
endless loop of . (dots) (someone already got this outcome)
I forgot to replace the $defaultLoc with $_[0] in the die
statement - sorry :-)
I've included the $! in the die since posting the message (just
discovered it in the "Learning Perl" book (the Llama book?))
I'll try the other suggestions tonight (or tomorrow - *yawn*)
David.
------------------------------
Date: Mon, 22 Jan 2001 18:29:55 GMT
From: "Sean Meisner" <sdmeisner@SPAMGUARDyahoo.com>
Subject: Re: Directory Recursion Problem.
Message-Id: <D__a6.77$LQ1.31345@sapphire.mtt.net>
> It is _not_ efficient to top-post. It is only efficient for _you_. It is
> inefficient when seen in the larger context of the newsgroup. It is
> selfish to call something that saves you three seconds but costs
> hundreds of other people more than three seconds efficient.
>
> If you had read the group a littlebit before posting, then you wouldn't
> have needed this personal explanation about why top posting in this
> group is discouraged. You would have known, because we rehash this same
> argument several times a week.
>
> I am going to killfile outlook express for good now. I'm just sick of
> the attitude that comes with it.
>
> Martien
> --
> Martien Verbruggen |
> Interactive Media Division | I took an IQ test and the results
> Commercial Dynamics Pty. Ltd. | were negative.
> NSW, Australia |
LOL!!! Chill out guy, it was just a little joke, and I complied with the
request.
Sheesh.. who pissed in your cornflakes this morning?? :o)
------------------------------
Date: Mon, 22 Jan 2001 18:36:31 GMT
From: Ala Qumsieh <aqumsieh@hyperchip.com>
Subject: Re: Directory Recursion Problem.
Message-Id: <7a8zo3qvrj.fsf@merlin.hyperchip.com>
"David Harrigan" <dajh101@yahoo.co.uk> writes:
> Consider the following snippet. Can anyone tell me why it fails?
What do you mean by 'it fails'? It depends on what you intend it to do
of course. Please provide more info.
> (assume that there is a root directory with a load of subdirs. The perl
> script is in the root directory)
>
> #!/usr/bin/perl -w
> $defaultLoc = ".";
>
> indexDir($defaultLoc);
>
> sub indexDir {
> opendir DIR, $_[0] || die "Can't open $defaultLoc !!";
It fails because of this. You have a precedence problem. || binds very
strongly, so your code is actually executed as:
opendir DIR, ($_[0] || die "Can't open $defaultLoc !!");
So, either use parentheses to avoid the confusion, or use the weaker
'or' instead of '||'.
Btw, why are you using $defaultLoc here and not $_[0]? You should be
consistent because if you modify the argument you pass to indexDir(),
then you'd have to modify indexDir() itself.
And, look into adding $! to your error message.
--Ala
------------------------------
Date: Mon, 22 Jan 2001 17:13:02 GMT
From: lbieg@my-deja.com
Subject: DOS commands with long directory names
Message-Id: <94hpmk$r56$1@nnrp1.deja.com>
I am trying to execute a DOS command in Perl on Windows NT and ME using
the back tick operator where the path contains spaces (ex: "D:\Program
Files\...) and I keep getting a bad command or file name error returned.
Can anyone tell me if there is any special syntax for this?
Thanks!
Loren
Sent via Deja.com
http://www.deja.com/
------------------------------
Date: Mon, 22 Jan 2001 17:38:48 GMT
From: "Sean Meisner" <sdmeisner@SPAMGUARDyahoo.com>
Subject: Re: DOS commands with long directory names
Message-Id: <Ie_a6.69$LQ1.27525@sapphire.mtt.net>
<lbieg@my-deja.com> wrote in message news:94hpmk$r56$1@nnrp1.deja.com...
> I am trying to execute a DOS command in Perl on Windows NT and ME using
> the back tick operator where the path contains spaces (ex: "D:\Program
> Files\...) and I keep getting a bad command or file name error returned.
>
> Can anyone tell me if there is any special syntax for this?
>
> Thanks!
>
> Loren
>
>
> Sent via Deja.com
> http://www.deja.com/
There is a special syntax.. DOS doesn't like names longer than 8
characters..
it will shorten longer names by truncating them and putting a ~(number code)
after them.. therefore try "D:\progra~1\..." in your backticks.. or maybe
progra~2
or ~3, just depends on how many directories you have that start with
"progra"...
------------------------------
Date: Mon, 22 Jan 2001 18:28:42 GMT
From: Bart Lateur <bart.lateur@skynet.be>
Subject: Re: DOS commands with long directory names
Message-Id: <7vuo6t0g1m4pbuo5kbfpogah6j6f5oorbl@4ax.com>
lbieg@my-deja.com wrote:
>I am trying to execute a DOS command in Perl on Windows NT and ME using
>the back tick operator where the path contains spaces (ex: "D:\Program
>Files\...) and I keep getting a bad command or file name error returned.
>
>Can anyone tell me if there is any special syntax for this?
Put the file path name between quotes. Something like:
system("\"$longfilename\"");
HTH,
Bart.
------------------------------
Date: Mon, 22 Jan 2001 18:47:50 GMT
From: j355@my-deja.com
Subject: embedded perl in korn shell
Message-Id: <94hv8i$i7$1@nnrp1.deja.com>
I am trying to pass environment variables, defined in a korn shell,
into a perl script within the korn shell script. I keep getting a perl
compiler error: syntax error at line 2, near "};"
Any ideas?
For example:
#################
export MYVAR=xyz
perl<<eof
print $ENV{MYVAR};
eof
#################
Sent via Deja.com
http://www.deja.com/
------------------------------
Date: Mon, 22 Jan 2001 19:34:36 +0100
From: "Alan J. Flavell" <flavell@mail.cern.ch>
Subject: full-jeopardy, was Re: Directory Recursion Problem.
Message-Id: <Pine.LNX.4.30.0101221918080.15660-100000@lxplus003.cern.ch>
On Tue, 23 Jan 2001, Martien Verbruggen wrote:
> It is _not_ efficient to top-post. It is only efficient for _you_. It is
> inefficient when seen in the larger context of the newsgroup.
It certainly is, and we don't seem to go for a day or two without
reminders being posted.
But for someone who's looking for a reliable answer, the vendors of
the kind of software that by default does upside-down fullquoting have
delivered us what seems to be an almost sure-fire warning alert. A
bit like fitting first cycles with trainer wheels - useless, indeed
actively counterproductive, once you've got started, but a clear
warning sign to others as long as they're in place.
> If you had read the group a littlebit before posting, then you wouldn't
> have needed this personal explanation about why top posting
Well, this time the perpetrator just slipped quietly into my killfile
for attitude, and I'd have said no more, if you hadn't brought the
subject up.
> I am going to killfile outlook express for good now.
Well, that's one approach, for sure. But OE's not the only offender
when it comes to upside-down quoting; and I'm told that it can be used
to post properly (the alt.usage.english group's FAQ even has some
helpful words about how to do it).
I think I'd rather kill on the upside-down quoting, than on the client
header.
> I'm just sick of the attitude that comes with it.
Right. And now I'm going to shut up about this, because we come here
to discuss Perl, not to discuss netiquette - sadly necessary though it
may be to raise that now and again.
all the best
------------------------------
Date: Mon, 22 Jan 2001 18:26:29 GMT
From: boussard <boussard@my-deja.com>
Subject: hash table
Message-Id: <94hu09$v9o$1@nnrp1.deja.com>
I am trying to find the easiest way to do the following query with a
hash table
I have 4 files, from which I need a few variables from each file. One of
the files has a variable in each of the separate files, for which I want
to merge the data and create a new file.
My question is: how do I grab a variable in one subroutine and carry
that variable into another?
Sent via Deja.com
http://www.deja.com/
------------------------------
Date: 22 Jan 2001 11:15:46 -0500
From: stanb@panix.com (Stan Brown)
Subject: Re: How to debug memory leak in a perl script?
Message-Id: <94hmbi$bkg$1@panix6.panix.com>
In <94ek3b$di0$1@ichaos.ichaos-int> Juha Laiho <Juha.Laiho@iki.fi> writes:
>stanb@panix.com (Stan Brown) said:
>>On overnight test runs, with data streaming in at full speed from another
>>perl script simulator, it appears to continue to grow in memory usage.
>>
>>Deletting the DB comiits, dose not fix this problem.
>>
>>Whats the best way to go baout debugng where it's leaking memory?
>You hopefully already have warnings enabled, and have 'use strict;' in
>effect.
>Beyond that, all kinds of anonymous things you create would be my prime
>suspects (are you really removing all references to those), closely
>followed by some array or hash not being cleaned up. Then perhaps you
>have a loop in which you create new database connections (or reopen files)
>without closing the old ones.
Thanks, I will check all of those.
I was hoping thta there might be a nifty CPAN module, or run time switch to
collect and dump periodicly memory usage statistics.
Any pointers to something like that?
------------------------------
Date: Mon, 22 Jan 2001 18:27:17 GMT
From: Bart Lateur <bart.lateur@skynet.be>
Subject: Re: How to turn 'die' in 'warn' on the fly
Message-Id: <diuo6tc5fbtqj5tpsru0qujoj4pocvehjl@4ax.com>
Martin Jost wrote:
>> Maybe you mean
>>
>> $SIG{__DIE__} = sub { warn shift };
>>
>> but careful. If people put a "die" somewhere, they usually don't
>> reconsider the possibility that the program would continue regardless.
>
>This isn't used as a 'fix'.
>What I want to do is, to see if all errors (of some special class) get
>caught.
>Normally the first one will 'die' the program. So I have to prevent
>this "for a moment".
>
>Unluckily your solution doesn't seem to work. The program dies
>nevertheless and prints the message twice...
Hmmm... apparently, die() wasn't supposed to continue. The second time
you see the message, it's probably the system that is doing the "die",
because your sub didn't.
Perhaps you need to bark up another tree. Perhaps don't use "warn" or
"die", but a custom sub of your own. Look at the implementation of
Carp.pm to see how it can be done. Key points are:
* The function caller() can return the environment of calling subs, in
array context. If you provide a numeric argument to caller(), you can
look deeper into the calling stack.
* die or warn with a message that ends in a newline, results in an
unchanged message, thus, no "at ... line ..." added.
In short, you can construct your own. Again, see Carp.pm. Or perhaps,
you can even USE Carp directly, but I doubt that.
--
Bart.
------------------------------
Date: 16 Sep 99 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 16 Sep 99)
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.
| NOTE: The mail to news gateway, and thus the ability to submit articles
| through this service to the newsgroup, has been removed. I do not have
| time to individually vet each article to make sure that someone isn't
| abusing the service, and I no longer have any desire to waste my time
| dealing with the campus admins when some fool complains to them about an
| article that has come through the gateway instead of complaining
| to the source.
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 118
**************************************
