[12047] in Perl-Users-Digest
Perl-Users Digest, Issue: 5647 Volume: 8
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu May 13 04:07:14 1999
Date: Thu, 13 May 99 01:00:47 -0700
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, 13 May 1999 Volume: 8 Number: 5647
Today's topics:
Re: "mkdir" make unaccessible directory.... (Bob Trieger)
Re: Accessing lexicals outside of scope? Any workaround <jbb@my-dejanews.com>
Best way to make a Perl script "live?" <s@undersea.net>
Re: Best way to make a Perl script "live?" <swarren@www.wwwdotorg.org>
Re: BUG FIX - Newbie question on CGI developing (Charles R. Thompson)
Re: cgi submitting a form to another server michael_555@my-dejanews.com
Re: cgi submitting a form to another server (Charles R. Thompson)
Re: Conditional Search and replace solution <hawkwynd@adelphia.net>
CPAN - Example of good documentation IO::Socket <nospam@atanytimeonthe.net>
Re: CPAN-POD & pulling my hair OUT! HELP! do the doc's <ebohlman@netcom.com>
Re: dos ^M to unix \n (Bob Trieger)
Re: dos ^M to unix \n (Bart Lateur)
Re: dos ^M to unix \n (Bob Trieger)
Re: Finding Total Directory Size in Perl. (Larry Rosler)
Re: Finding Total Directory Size in Perl. <gary@rdss.com>
Re: Finding Total Directory Size in Perl. (Charles R. Thompson)
Re: Finding Total Directory Size in Perl. (Sam Holden)
Re: Finding Total Directory Size in Perl. (Larry Rosler)
Getting a DNS record voxelman@my-dejanews.com
Re: HASH AND ARRAY <swarren@www.wwwdotorg.org>
Re: HASH AND ARRAY (Bart Lateur)
Re: HASH AND ARRAY (Larry Rosler)
Special: Digest Administrivia (Last modified: 12 Dec 98 (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 12 May 1999 22:40:58 GMT
From: sowmaster@juicepigs.com (Bob Trieger)
Subject: Re: "mkdir" make unaccessible directory....
Message-Id: <7hcutm$on0$1@holly.prod.itd.earthlink.net>
[ courtesy cc sent by mail if address not munged ]
ryanngi@hotmail.com (Ryan Ngi) wrote:
>i use "mkdir" in a CGI, when i try it on BROWSER, the CGI make some
>unaccessible directory ,and also "chmod" is not work for it....
>
>i think the directory's UID isn't mine,... and i try "chown"... but
>not work.... do you know How to fix it???
Did you have a perl question?
------------------------------
Date: Thu, 13 May 1999 03:02:31 GMT
From: Julien B Beasley <jbb@my-dejanews.com>
To: ada@fc.hp.com
Subject: Re: Accessing lexicals outside of scope? Any workarounds?
Message-Id: <7hdfc6$dg1$1@nnrp1.deja.com>
In article <7hcdpo$4t5$2@fcnews.fc.hp.com>,
ada@fc.hp.com (Andrew Allen) wrote:
> how about something like
>
> BEGIN {eval `cat mylib.pl`;}
>
> It's not pretty, but...
eval `cat mylib.pl`;
works perfectly.
Thanks!
> Andrew
-Julien
--
It may take a litte courage to ask your doctor about Erectile
Dysfunction.
But everything worthwhile usually does.
-Bob Dole
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
------------------------------
Date: Wed, 12 May 1999 21:09:35 -0500
From: Sean <s@undersea.net>
Subject: Best way to make a Perl script "live?"
Message-Id: <373A345F.41E898D9@undersea.net>
Hi,
I have 3 monochrome monitors sitting here, and a serial port board
doing nothing. I want to write a Perl script that will display incoming
network connections on their respective ports on to these monitors using
'sniffit.' My question is; what is the least resource costing way to
monitor 24 hour input, like a 'tail' in Perl? 'sniffit' would be
running 24 hours sending input to a file. How can I pipe this info
straight out of the file continuously without having to write something
like if the file size changes every 1 second do something. BTW If I
were to write something like that, checking the size of a file every
second with Perl, what kind of resource would that be chewing away if
any? Any help is greatly appreciated. ThanX!
--Sean
------------------------------
Date: Thu, 13 May 1999 04:25:37 GMT
From: "Stephen Warren" <swarren@www.wwwdotorg.org>
Subject: Re: Best way to make a Perl script "live?"
Message-Id: <5vs_2.659$6x6.951@news.rdc1.sfba.home.com>
Sean <s@undersea.net> wrote in message
news:373A345F.41E898D9@undersea.net...
> My question is; what is the least resource costing way to
> monitor 24 hour input, like a 'tail' in Perl? 'sniffit' would be
> running 24 hours sending input to a file.
As far as simulating 'tail -f', there's another thread very recently that
mentioned it. I think it stated that the answer was in the FAQ
(http://www.perl.com/, follow link to FAQ).
I don't know sniffit, but with Perl, you don't _have_ to send the input
through a file, you could do something like:
open( FH, "sniffit |" ) || die "Error starting sniffit: $!" ;
--
Stephen Warren, Snr Systems Engineer, Technology House, San Francisco
mailto:swarren@techhouse.com http://www.techhouse.com/
mailto:swarren@wwwdotorg.org http://www.wwwdotorg.org/
MIME, S/MIME and HTML mail are acceptable
------------------------------
Date: Thu, 13 May 1999 04:42:33 GMT
From: design@raincloud-studios.com (Charles R. Thompson)
Subject: Re: BUG FIX - Newbie question on CGI developing
Message-Id: <MPG.11a42395712767749896b6@news>
In article <373a28b8.11976741@nntp1.ba.best.com>, Ken Bass says...
What a lamo I am! Don't use double-quotes in your replace tag. Single
quotes or some other delimiter will work much better. The double quotes
will fail on HREF and SRC tags if there is no replacement key. Then you
end up with a junky page. :(
Sorry folks!
fixes...
<html>
<head><title><replace='title'></title><head>
<body>
<p><replace='message'>
<p><replace='footer'>
<p><img src="<replace='myimage'>">
</body>
</html>
NOTE:
<replace="thing">
has s/always/sometimes worked for me if I do things perfect.
<replace='thing'>
is a bit better. :)
while ( ($key, $value) = each %pagestuff){
# find all instances of the named key and replace it
# with a value from the hash
$pagelines =~ s/<replace='$key'>/$pagestuff{$key}/;
}
--
Charles R. Thompson
RainCloud Studios
"That? That's no script. That's MY attempt at a rather complex README
file."
------------------------------
Date: Wed, 12 May 1999 23:33:16 GMT
From: michael_555@my-dejanews.com
Subject: Re: cgi submitting a form to another server
Message-Id: <7hd33r$2nk$1@nnrp1.deja.com>
> ok.. semantics. Make YOU type it in. If it never changes, then you
should
> have no problem remembering it. Didn't anyone ever tell you that not
> leaving userID's or passwords laying around is like the *first* step
in
> security measures?
>
Yah. Babysit my server waiting for some surfer to push a
button, then type in my userid so they get the next page
with no delay. Even if that could be done...
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
------------------------------
Date: Thu, 13 May 1999 00:11:10 GMT
From: design@raincloud-studios.com (Charles R. Thompson)
Subject: Re: cgi submitting a form to another server
Message-Id: <MPG.11a3e3f3ec023b969896b1@news>
[This followup was posted to comp.lang.perl.misc and a copy was sent to
the cited author.]
In article <7hd33r$2nk$1@nnrp1.deja.com>, michael_555@my-dejanews.com
says...
> Yah. Babysit my server waiting for some surfer to push a
> button, then type in my userid so they get the next page
> with no delay. Even if that could be done...
Terms like UserID mean very different things in many different contexts.
Now that I go back I see you are using a secure server(the only
indication of which is that little s in https), possibly for transactions
that passed a userid when someone makes a purchase or somesuch.
Well, without your userid that system is useless. I'll bet it shows in
the HTML of *their* forms as well. So either way, people are gonna see
it. Trying to hide it is somewhat silly if that's how the system is
designed. If your password is that simple, then heck ya, somebody may
guess it. Change it often. Here's a few recommendations...
X8gh54REwQ
8UIwe32ccV
JH9LLoeXCz
If you are using plain words for a password, you are just asking for your
paranoia to manifest itself into a real world situation.
As far down the non-Perl road as I'm willing to travel without a spare
canteen.
--
CT
"Fix your textwrap. Who do you think you are? E.E. Cummings?"
------------------------------
Date: Thu, 13 May 1999 04:38:01 GMT
From: "Hawkwynd" <hawkwynd@adelphia.net>
Subject: Re: Conditional Search and replace solution
Message-Id: <JGs_2.242$qp.830@server1.news.adelphia.net>
Larry Rosler wrote in message ...
>> next unless /^\d{2}_(\d{4})\.txt$/i;
>> open(INF,"$file_dir/$_");
>> open(OUTF,">$outdir/$1");
>
>Did we forget to tell you ALWAYS to check your open() calls?
Should it then be written then as:
open(INF,"$file_dir/$_") || die "Unable to open $file_dir/$_";
open(OUTF,">$outdir/$1") || die "Unable to open $outdir/$1";
>> tr/\014\015/ /d;
>
>This replaces "\014" by ' ' and deletes "\015". That's not what your
>pseudo-code says to do.
Ok, even though it DOES do that, what should I've coded it as? I thought
the d at the end deletes the pattern found between the / /'s ... Ok, time to
re-read the book..
>But that replacement is not what your pseudo-code says. I think you
>want this:
> next if /^NOTES:\s*$/;
>> if ($_=~m/ASSMD MTG: L: P: /s){
>>
>> $_ =~s/ASSMD MTG: L: P: / /s;
>> }
>
>This is twice as much work as necessary. I'm sure we told you just to
>do this, which is identical:
>
> s/ASSMD MTG: L: P: / /;
I'll give another shot, perhaps I did not write it properly, but when I
placed the line and ran the script, it didn't work correctly... One more
try, this time with flair..
I'd much rather do it correctly, and I understand that it would save the
code work too.
Thanks again, and I'll let you know how it works out..
Scott
------------------------------
Date: Wed, 12 May 1999 17:38:55 -0700
From: N <nospam@atanytimeonthe.net>
Subject: CPAN - Example of good documentation IO::Socket
Message-Id: <373A1F1F.4799@atanytimeonthe.net>
I read through lots of older posts about timeout problems, and they
never seem to be resolved.
Here's a example of the documentation problems I have been having, and
maybe why so many people have to post here with so many questions, from
http://linux.fh-heilbronn.de/doku/PERL/modules/IO::Socket.html
timeout([VAL])
Set or get the timeout value associated with this socket. If called
without any arguments then the current setting is returned. If called
with an argument the current setting is changed and the previous value
returned.
Ok, so does that mean that if I use ::INET with this and set the so
called "timeout" value, then it times out if it can't get a web page? I
don't think so, because I may have a good socket connection, but the
server may not pass anything back. Or is it a inactivity thing? So is it
making the connection timeout, or what?
How about "VAL" ? is it hours, days or what?
::INET docs say that I can use all the stuff for Socket, so I assume
there is no timeout if any text doesn't come back from a server, since I
have a good connection. Is there a way to set a time out for the socket
connecting, timeout for inactivity and maybe a timeout after making a
web page get request? (three seperate problems)
Where do I do this? can I do it BEFORE saying "new"? why say new if I
can't set the timeout value so it won't sit there all day long?
$remote = IO::Socket::INET->new( Proto => "tcp",
PeerAddr => $host,
PeerPort => "http(80)",
);
if ($remote) {
$remote->autoflush(1);
print $remote "GET $document HTTP/1.0" . $EOL . $EOL;
So I do the timeout call after the if ($remote) ??
or can I say
IO::Socket::INET->timeout(60);
$remote = IO::Socket::INET->new( .........
Why isn't this type of stuff documented? Doesn't CPAN have any
requirements before releasing a module or docs? Shouldn't they require a
example or TWO with all stuff like this? You would think the guys who
wrote these modules have some example code available....
Sorry but I am really frustrated.
------------------------------
Date: Thu, 13 May 1999 03:31:12 GMT
From: Eric Bohlman <ebohlman@netcom.com>
Subject: Re: CPAN-POD & pulling my hair OUT! HELP! do the doc's really suck this bad?
Message-Id: <ebohlmanFBnJ40.G6C@netcom.com>
I R A Aggie <fl_aggie@thepentagon.com> wrote:
: On Wed, 12 May 1999 11:10:39 -0700, N <nospam@atanytimeonthe.net>, in
: <3739C41F.3E7C@atanytimeonthe.net> wrote:
: + I really don't want to go to each module's ".tar.gz" file and extract
: + the docs, that's a real big waste of time and doesn't allow for
: + searching within docs very well.
: Try: 'perldoc perldoc'. Once you know where the .pod files are, you
: can 'grep' them, as they're text files. You might even looking downloading
: and installing 'perlindex'...
: + Go to the pages above and pretend like you want to know the variable
: + names and calls you can make to a module, then tell me that a idiot like
: + myself can make heads or tails of what you find.
: % perldoc Net::FTP
: Net::FTP - FTP Client class
[snip]
But that will only happen if he's *already* installed Net::FTP. What he
was looking for (you may have written before seeing his response to me)
was a way to browse the documentation on modules he *hadn't* yet installed.
------------------------------
Date: Wed, 12 May 1999 22:50:53 GMT
From: sowmaster@juicepigs.com (Bob Trieger)
Subject: Re: dos ^M to unix \n
Message-Id: <7hcvg5$on0$2@holly.prod.itd.earthlink.net>
[ courtesy cc sent by mail if address not munged ]
chris@holly.dyndns.org (Chris Costello) wrote:
> You want: s/\r\n/\n/;
nah, why replace the newline with a newline? Just remove the return
character.
s/\r//; or
y/\r//;
------------------------------
Date: Wed, 12 May 1999 23:19:22 GMT
From: bart.lateur@skynet.be (Bart Lateur)
Subject: Re: dos ^M to unix \n
Message-Id: <373c0bda.3522285@news.skynet.be>
Bob Trieger wrote:
>> You want: s/\r\n/\n/;
>
>nah, why replace the newline with a newline? Just remove the return
>character.
>
>s/\r//; or
>y/\r//;
Because, as TomC recently wrote, "you're on a Mac and you just wiped out
all the newlines.".
I think I would rahter make the "\n" optional. And replace "\r" and "\n"
by their literal values.
s/\015\012?/\n/g;
This does nothing if the file is already in Unix format.
Bart.
------------------------------
Date: Thu, 13 May 1999 01:51:32 GMT
From: sowmaster@juicepigs.com (Bob Trieger)
Subject: Re: dos ^M to unix \n
Message-Id: <7hda2m$8v1$1@ash.prod.itd.earthlink.net>
[ courtesy cc sent by mail if address not munged ]
bart.lateur@skynet.be (Bart Lateur) wrote:
>Bob Trieger wrote:
>
>>> You want: s/\r\n/\n/;
>>
>>nah, why replace the newline with a newline? Just remove the return
>>character.
>>
>>s/\r//; or
>>y/\r//;
>Because, as TomC recently wrote, "you're on a Mac and you just wiped out
>all the newlines.".
>
>I think I would rahter make the "\n" optional. And replace "\r" and "\n"
>by their literal values.
>
> s/\015\012?/\n/g;
>
>This does nothing if the file is already in Unix format.
point taken.
Thanks
------------------------------
Date: Wed, 12 May 1999 15:31:58 -0700
From: lr@hpl.hp.com (Larry Rosler)
Subject: Re: Finding Total Directory Size in Perl.
Message-Id: <MPG.11a3a13632e9fd14989a51@nntp.hpl.hp.com>
[Posted and a courtesy copy mailed.]
In article <slrn7jjuvd.ggl.sholden@pgrad.cs.usyd.edu.au> on 12 May 1999
22:08:46 GMT, Sam Holden <sholden@pgrad.cs.usyd.edu.au> says...
> On Wed, 12 May 1999 17:06:12 -0400, Gary Ebert <gary@rdss.com> wrote:
...
> >Apparently either you are way more anal than I am (hence all of this testing
> >nonsence :-) or you do not understand the script that I submitted. If it is
> >the former good for you I was just trying to quickly show the original poster
> >another way of doing what he asked about. If it is the latter then just say
> >"I do not understand what you are doing here please explain" and I will.
>
> I seriously doubt you could explain much (I dare say anything) about perl
> to Larry that he doesn't know. He on the other hand could probably explain
> a large amount to you, but I suspect you may be going to get plonked by those
> people that can actually help you in the future if you keep posting like this.
Thanks for the defense. Your generalization is not true. What I know
about Perl is based on experience drawn from C and Unix (yes, Unix,
TomC, as I know you know -- though I will continue to fight your rabid
Unix-centrism forever) and the Unix/POSIX command set.
I took that dumb certification test a while ago, and simply guessed at a
lot of stuff about OO (note I didn't mention C++ or Java above :-) and
DBM and modules and ... But I still ended up a 'Master'. :->
> >For the record I do believe that testing variables is in general a good thing
> >to do; however, I was trying to write a short script that demonstrated a
> >different way to go about adding up the sizes of files in a given directory I
> >was not submitting a fool proof program -- if I gave that impression I apologize.
>
> A program that actually had a chance of working would have been OK. You have two
> major errors (one not mentioned by Larry) and seem to fail to grasp that in
> this case you are wrong and someone else is right...
We seem to get one of those about once a week. Sigh... But no *plonk*.
Never.
--
(Just Another Larry) Rosler
Hewlett-Packard Company
http://www.hpl.hp.com/personal/Larry_Rosler/
lr@hpl.hp.com
------------------------------
Date: Wed, 12 May 1999 19:30:03 -0400
From: Gary Ebert <gary@rdss.com>
Subject: Re: Finding Total Directory Size in Perl.
Message-Id: <373A0EF2.EBD68F8B@rdss.com>
Sam Holden wrote:
>
> On Wed, 12 May 1999 17:06:12 -0400, Gary Ebert <gary@rdss.com> wrote:
> >
> >
> >Larry Rosler wrote:
> >>
> >> In article <3739C34E.D1F0878F@rdss.com> on Wed, 12 May 1999 14:07:14 -
> >> 0400, Gary Ebert <gary@rdss.com> says...
> >> ...
> >> > #!/usr/bin/perl
> >>
> >> Missing '-w'!
> >
> >granted but the error "use of uninitialized variable at line . . . really
> >annoys me because we all can see that I have initialized the variable.
>
> The idea is to fix the code so that the warnings go away, not to disable
> warnings. Do you do this in other areas as well. No need to have a smoke
> detector, after all it goes off wean I know there is no fire often when
> I cook. No need for a low fuel warning light on my car, since sometimes
> it lights up for no reason when I drive up hill...
Let me be more specific. The warning that I am referring to was the warning
that says something like the following:
"Use of an uninitialized variable"
the diagnostics pragma then adds:
"A variable was interpreted as "" or 0. To avoid this warning assign an
initial value to your variables."
Well the only solutions to this warning that I know of are quite cumbersome
and take quite a few lines of code so in this case I did "get rid of the smoke
detector". In general I agree that this is not the best way to do things
however I do not think that the extra code adds a meaningful lesson in this
particular case.
>
> >>
> >> > use strict;
> >> >
> >> > my $size = 0;
> >> > my $dir = $main::ARGV[0];
> >>
> >> Superfluous use of 'main::'.
> >
> >True but I prefer to include the package name -- just personal taste.
> >
> >> No test for nonexistent argument.
> >
> >No I did not. I do not think that level of detail was necessary for a brief
> >example to show a different way to do something.
> >
> >>
> >> > # note that the directory is passed in on the command line
> >> > # instead of hard coded into the script
> >> >
> >> > opendir (FILE, $dir) or die "could not open $_\n";
> >>
> >> $_ is undefined at this point. Do you mean $! ?
> >
> >oops that should have been $dir not $_.
> >
> >>
> >> > while ($_ = readdir FILE) {$size += -s unless (/^\.{1,2}?$/)}
> >>
> >> So you are adding up the sizes of things in the current directory that
> >> happen to have the same name as things in $dir. Hmmm...
> >
> >What?
> >
> >I am adding up the size of all of the files in $dir that are not '.' or '..'
>
> No your not, your doing what Larry said you were. Why don't you actually
> run the code and see...
As I told Larry in a private e-mail the problem was not that I did not try the
code the problem was that I only tried the code in the same directory as $dir.
I must admit that makes me quite foolish; however, your telling me to run the
code does not really help. The main problem here was that I did not think of
testing the code in a different directory.
>
> >
> >>
> >> By the way, what's with the '?' after the quantifier???
> >
> >Hmmm you are giving me crap about my script and you do not know the purpose of
> >the '?' modifier . . . interesting.
>
> I assume he does in fact...
>
> >
> >For the record the "?" is for minimal matching it is probably not needed --
> >again just personal preference.
>
> But that's useless in this context. You aren't capturing for one. You are
> between ^ and $ for another, so all that could possibly do is slow
> the regex match down... And confuse the reader with extra crap that has
> no positive effect...
You are correct in this context. I should have removed it. Maybe this only
makes sense to me but I do minimal matching unless I explicitly need "greedy"
matching. That is not to say that everyone should do things that way it is
just to say that is why I did it.
>
> >
> >>
> >> > # the unless statement insures that you do not count the . and .. files
> >> >
> >> > print "Total file size for $dir = $size bytes\n";
> >> >
> >> > # END
> >> >
> >> > And I am sure that this could be trimmed down even more.
> >>
> >> It could be trimmed *up* by chdir($dir)
> >
> >Yes it could I do not understand what you think will be gained by that but
> >that could be done.
>
> It would make the code have more resemblence to code that works...
Yes this is true and I do understand why *now*. Initially I did not
understand Larry's comment once Larry explained himself I felt (and still
feel) like quite the dumbass.
> >
> >> or by testing "$dir/$_".
> >
> >Let's see you want me to test $dir/$_.
> >
> >First I open the directory if the directory does not exist or the user does
> >not have the correct permissions the script is exited.
> >
> >Then I read the first file of the directory. All directories (in unix at
> >least wh/ is obviously what the original poster is using) have at least two
> >files '.' and '..' so I implicitly know that there are files in this
> >directory.
> >
> >If the file is not the . or the .. file I check to see if the file has
> >non-zero size (and return the file size) the '-s' operator does this.
> >
> >Then I add the size to the to the size of the previous files. If -s fails
> >then a zero is returned and added to the total doing nothing.
> >
> >Exactly what else would you have me test the file for?
>
> Testing $dir/$_ would actually test stat the file in the directory instead
> of in the current directory. Which would stop your code from always
> returning zero in most cases.
>
> You should really test if it a directory and if so, then you need to add
> up the sizes of all the files in that diorectory as well. Your code doesn't
> do that, so your code doesn't have any chance of working.
> Once you modified
> it to do that, you might se why intelligent poeple would use File::Find.
>
> >
> >>
> >> You might consider doing some testing next time before posting code.
> >
> >I did (as you pointed out) forget to test the case where the directory either
> >did not exist or could not be opened before I posted. However, other than
> >that the code works fine -- it adds up the size of each file in the passed in
> >directory. If you tested my script before sending this you would have
> >realized that.
>
> I doesn't. I did actually test your miserable excuse for a script..
> (I stored it in test.pl) Here's some of its output...
>
> [sholden@mrmph sholden]$ perl test.pl echo
> Total file size for echo = 0 bytes
> [sholden@mrmph sholden]$ du -ks echo
> 34 echo
> [sholden@mrmph sholden]$ perl test.pl cd
> Total file size for cd = 0 bytes
> [sholden@mrmph sholden]$ du -ks cd
> 192263 cd
> [sholden@mrmph sholden]$ cd ..
> [sholden@mrmph /home]$ perl ~/test.pl sholden
> Total file size for sholden = 0 bytes
> [sholden@mrmph /home]$ du -ks sholden
> [ the command is still running and I can't be bothered waiting...
> I'm guessing the answer should be 1.5Gb or so]
>
> You must have a different definition of works then I do...
>
> 0 bytes is the wrong answer in _all_ of those tests, yet the script that
> you claim works gives this output.
>
> >
> >Apparently either you are way more anal than I am (hence all of this testing
> >nonsence :-) or you do not understand the script that I submitted. If it is
> >the former good for you I was just trying to quickly show the original poster
> >another way of doing what he asked about. If it is the latter then just say
> >"I do not understand what you are doing here please explain" and I will.
>
> I seriously doubt you could explain much (I dare say anything) about perl
> to Larry that he doesn't know. He on the other hand could probably explain
> a large amount to you, but I suspect you may be going to get plonked by those
> people that can actually help you in the future if you keep posting like this.
>
> >
> >For the record I do believe that testing variables is in general a good thing
> >to do; however, I was trying to write a short script that demonstrated a
> >different way to go about adding up the sizes of files in a given directory I
> >was not submitting a fool proof program -- if I gave that impression I apologize.
>
> A program that actually had a chance of working would have been OK. You have two
> major errors (one not mentioned by Larry) and seem to fail to grasp that in
> this case you are wrong and someone else is right...
Admittedly I did fail to grasp that. I also must apologize for that. I was
having a rough day and I let my ego get the best of me.
>
> --
> Sam
>
> In case you hadn't noticed, Perl is not big on originality.
> --Larry Wall
--
Gary Ebert Operations Administrator
Voice: (301) 428-2115 Comtech Mobile Datacom Corporation
Fax: (301) 428-1004 19540 Amaranth Drive
Pager: (800) 777-4681 PIN: 3981842 Germantown, MD 20875-2126
------------------------------
Date: Thu, 13 May 1999 00:29:19 GMT
From: design@raincloud-studios.com (Charles R. Thompson)
Subject: Re: Finding Total Directory Size in Perl.
Message-Id: <MPG.11a3e82c9ceeb1c09896b2@news>
[This followup was posted to comp.lang.perl.misc and a copy was sent to
the cited author.]
In article <373A0EF2.EBD68F8B@rdss.com>, Gary Ebert says...
> Let me be more specific. The warning that I am referring to was the warning
> that says something like the following:
>
> "Use of an uninitialized variable"
> the diagnostics pragma then adds:
> "A variable was interpreted as "" or 0. To avoid this warning assign an
> initial value to your variables."
>
> Well the only solutions to this warning that I know of are quite cumbersome
> and take quite a few lines of code so in this case I did "get rid of the smoke
> detector". In general I agree that this is not the best way to do things
Egads man. If you need so many variables that it's a *chore* to assign
initial values, then you probably need rethink that code by possibly
breaking things up into subs and passing stuff around. Anytime I get more
variables than I can store in my own upstairs biological cache, I look
for alternatives.
> however I do not think that the extra code adds a meaningful lesson in this
> particular case.
Maybe not to who you presented, but it doesn't help the DEJANewser who
searches for directory recursing posts, etc... and ends up with your
code, then comes back here (it's source) to get it fixed. Not everyone
who reads the posts follows an entire thread start to finish. This stuff
hangs around the world for quite some time.
--
Charles R. Thompson
RainCloud Studios
"That? That's no script. That's your attempt at a rather complex README
file."
------------------------------
Date: 13 May 1999 00:10:48 GMT
From: sholden@pgrad.cs.usyd.edu.au (Sam Holden)
Subject: Re: Finding Total Directory Size in Perl.
Message-Id: <slrn7jk648.9ud.sholden@pgrad.cs.usyd.edu.au>
On Wed, 12 May 1999 19:30:03 -0400, Gary Ebert <gary@rdss.com> wrote:
>
>Yes this is true and I do understand why *now*. Initially I did not
>understand Larry's comment once Larry explained himself I felt (and still
>feel) like quite the dumbass.
I think we've all been there...
--
Sam
Some of you know what the Perl slogan on Windows is, and you can say it
with me: "It's a good thing there's more than one way to do it, because
most of them don't work." --Larry Wall
------------------------------
Date: Wed, 12 May 1999 17:24:53 -0700
From: lr@hpl.hp.com (Larry Rosler)
Subject: Re: Finding Total Directory Size in Perl.
Message-Id: <MPG.11a3bbacc0bd11d3989a55@nntp.hpl.hp.com>
[Posted and a courtesy copy mailed.]
In article <373A0EF2.EBD68F8B@rdss.com> on Wed, 12 May 1999 19:30:03 -
0400, Gary Ebert <gary@rdss.com> says...
...
> As I told Larry in a private e-mail the problem was not that I did not try the
> code the problem was that I only tried the code in the same directory as $dir.
> I must admit that makes me quite foolish; however, your telling me to run the
> code does not really help. The main problem here was that I did not think of
> testing the code in a different directory.
Then why have a $dir prefix argument at all? :-) That alone should
have led you to try it with different values than '.' or the actual name
of the current directory.
...
> Sam Holden wrote:
> > A program that actually had a chance of working would have been OK. You have two
> > major errors (one not mentioned by Larry) and seem to fail to grasp that in
> > this case you are wrong and someone else is right...
*I* omitted to mention a major error? That has never happened before!
:-)
> Admittedly I did fail to grasp that. I also must apologize for that. I was
> having a rough day and I let my ego get the best of me.
My usual answer when some Californian says to me "Have a good day now!"
is "Too late for that." Oh, well...
--
(Just Another Larry) Rosler
Hewlett-Packard Company
http://www.hpl.hp.com/personal/Larry_Rosler/
lr@hpl.hp.com
------------------------------
Date: Thu, 13 May 1999 04:17:39 GMT
From: voxelman@my-dejanews.com
Subject: Getting a DNS record
Message-Id: <7hdjp0$gfk$1@nnrp1.deja.com>
I have an application that needs to obtain the mx handle (mail
exchanger, mail server) for a domain to be passed to the application. Is
there a way to do this in Perl? If not or if there is an easier way to
do this some other way please let me know, this has been puzzling me for
a while now and I haven't found a good solution just some work arounds
I've used for other applications I've done..like parsing the output of
host -t mx domain but I really now need to be doing it in native perl or
some otherway. If someone has some ideas or could provide even a small
bit of assistance i would greatly appreciate it. Thanks in advance.
--Paul aka Voxelman
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
------------------------------
Date: Wed, 12 May 1999 23:43:16 GMT
From: "Stephen Warren" <swarren@www.wwwdotorg.org>
Subject: Re: HASH AND ARRAY
Message-Id: <omo_2.617$6x6.870@news.rdc1.sfba.home.com>
Bart Lateur <bart.lateur@skynet.be> wrote in message
news:373b0a97.3198996@news.skynet.be...
> Stephen Warren wrote:
>
> >I can't just do:
> >
> >@$elem{ @keys } = @$instructionTypeInfo{ @keys } ;
> >
> >since that'd over-ride the data that's already there...
>
> @selection = grep { exists $instructionTypeInfo->{$_} &&
> ! exists $elem->{$_} } @keys;
Indeed. I thought of that after seeing the other grep posts later, but...
a) The article you responded to _still_ hasn't appeared on my news-server
(which I posted it to!) so I couldn't follow-up to it.
b) It's bad to follow-up to your own posts:-)
The question is - is the grepping thing likely to be any faster? Of
course, the loop is probably a little more obvious.
--
Stephen Warren, Snr Systems Engineer, Technology House, San Francisco
mailto:swarren@techhouse.com http://www.techhouse.com/
mailto:swarren@wwwdotorg.org http://www.wwwdotorg.org/
MIME, S/MIME and HTML mail are acceptable
------------------------------
Date: Wed, 12 May 1999 23:12:58 GMT
From: bart.lateur@skynet.be (Bart Lateur)
Subject: Re: HASH AND ARRAY
Message-Id: <373b0a97.3198996@news.skynet.be>
Stephen Warren wrote:
>I can't just do:
>
>@$elem{ @keys } = @$instructionTypeInfo{ @keys } ;
>
>since that'd over-ride the data that's already there...
Select only those keys that are in the source hash but not in the
destination hash:
@selection = grep { exists $instructionTypeInfo->{$_} &&
! exists $elem->{$_} } @keys;
and try again with this subarray.
Bart.
------------------------------
Date: Wed, 12 May 1999 17:40:46 -0700
From: lr@hpl.hp.com (Larry Rosler)
Subject: Re: HASH AND ARRAY
Message-Id: <MPG.11a3bf65bd6d20a989a56@nntp.hpl.hp.com>
[Posted and a courtesy copy mailed.]
In article <omo_2.617$6x6.870@news.rdc1.sfba.home.com> on Wed, 12 May
1999 23:43:16 GMT, Stephen Warren <swarren@www.wwwdotorg.org> says...
...
> The question is - is the grepping thing likely to be any faster? Of
> course, the loop is probably a little more obvious.
General Perl performance principles:
Perl-ops are relatively slow, so the fewer of them, the better.
Built-in Perl functions are likely to be implemented in C, hence are
inherently fast in themselves.
Invoking a built-in Perl function is not significantly more costly than
doing any other perl-op.
So any grep or map is likely to be faster than any explicit loop.
***
This is almost exactly the opposite behavior from C, where ops are fast
and function calls are slow. So it took me a long while to catch on to
this.
As an example, consider using the length of a particular string twice in
a calculation.
In C,
if ((len = strlen(string)) > 30 && len < 60) { ... }
in Perl,
if (length($string) > 30 && length($string) < 60) { ... }
because storing the length and retrieving it again takes longer than
just recalculating it! Also, in C strlen() is O(N) in the length of the
string; in Perl, length() is O(0). But despite my now understanding
that length() is a 'fast' primitive, like add or negate, that expression
still hurts my eyes.
--
(Just Another Larry) Rosler
Hewlett-Packard Company
http://www.hpl.hp.com/personal/Larry_Rosler/
lr@hpl.hp.com
------------------------------
Date: 12 Dec 98 21:33:47 GMT (Last modified)
From: Perl-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Special: Digest Administrivia (Last modified: 12 Dec 98)
Message-Id: <null>
Administrivia:
Well, after 6 months, here's the answer to the quiz: what do we do about
comp.lang.perl.moderated. Answer: nothing.
]From: Russ Allbery <rra@stanford.edu>
]Date: 21 Sep 1998 19:53:43 -0700
]Subject: comp.lang.perl.moderated available via e-mail
]
]It is possible to subscribe to comp.lang.perl.moderated as a mailing list.
]To do so, send mail to majordomo@eyrie.org with "subscribe clpm" in the
]body. Majordomo will then send you instructions on how to confirm your
]subscription. This is provided as a general service for those people who
]cannot receive the newsgroup for whatever reason or who just prefer to
]receive messages via e-mail.
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.misc (and this Digest), send your
article to perl-users@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.
The Meta-FAQ, an article containing information about the FAQ, is
available by requesting "send perl-users meta-faq". The real FAQ, as it
appeared last in the newsgroup, can be retrieved with the request "send
perl-users FAQ". Due to their sizes, neither the Meta-FAQ nor the FAQ
are included in the digest.
The "mini-FAQ", which is an updated version of the Meta-FAQ, is
available by requesting "send perl-users mini-faq". It appears twice
weekly in the group, but is not distributed in the digest.
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 V8 Issue 5647
**************************************
