[14044] in Perl-Users-Digest
Perl-Users Digest, Issue: 1454 Volume: 9
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Nov 22 00:25:17 1999
Date: Sun, 21 Nov 1999 21:21:25 -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: <943248085-v9-i1454@ruby.oce.orst.edu>
Content-Type: text
Perl-Users Digest Sun, 21 Nov 1999 Volume: 9 Number: 1454
Today's topics:
search in subdirectories <nds9903@arch.ethz.ch>
Re: search in subdirectories (Tad McClellan)
Re: sendmail pipe lee.lindley@bigfoot.com
Re: Serious memory leak in MacPERL? (Chris Nandor)
Re: Shared variables between perl and embedded sh scrip <jarrowwx@NOSPAM.home.com>
Re: signature question (was Re: Help with Stoopid Nutsc <cassell@mail.cor.epa.gov>
Trapping Error Messages <palchin@dragnet.com.au>
Re: Trapping Error Messages <david@gigawatt.com>
Re: Trapping Error Messages (Brett W. McCoy)
Re: Trapping Error Messages (Brett W. McCoy)
Re: Un deletable files HELP!!! <rootbeer@redcat.com>
Re: What is a good book on Perl <cassell@mail.cor.epa.gov>
Re: What is a good book on Perl <cassell@mail.cor.epa.gov>
Re: Writing data in another server <rootbeer@redcat.com>
Re: Writing data in another server jampa@my-deja.com
Re: Writing data in another server <cassell@mail.cor.epa.gov>
Digest Administrivia (Last modified: 16 Sep 99) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sun, 21 Nov 1999 18:22:40 +0100
From: Sigrun Gudjonsdottir <nds9903@arch.ethz.ch>
Subject: search in subdirectories
Message-Id: <38382A60.AC2A139E@arch.ethz.ch>
Hi all,
I am new to perl but I have already made my first scripts and they work
but just for the directory where the script is. But I want to check the
subdirectories too and I have been looking for this for days, reading
everything on www.perl.com but I found nothing. Did I miss it or what?
Can somebody tell how to do this and maybe in a simple way (for a
beginner) :) please!
Thanks in advance.
--
Sigrun
xxx
------------------------------
Date: Sun, 21 Nov 1999 08:48:43 -0500
From: tadmc@metronet.com (Tad McClellan)
Subject: Re: search in subdirectories
Message-Id: <slrn83fu1r.6a1.tadmc@magna.metronet.com>
On Sun, 21 Nov 1999 18:22:40 +0100, Sigrun Gudjonsdottir
<nds9903@arch.ethz.ch> wrote:
>But I want to check the
>subdirectories too
>Can somebody tell how to do this
use File::Find; # this module does that
--
Tad McClellan SGML Consulting
tadmc@metronet.com Perl programming
Fort Worth, Texas
------------------------------
Date: 21 Nov 1999 18:00:03 GMT
From: lee.lindley@bigfoot.com
Subject: Re: sendmail pipe
Message-Id: <819bv3$s5f$1@rguxd.viasystems.com>
Eric Miller <dukat@flash.net> wrote:
:>It was sincere. I have a script now that will show the error messages
:>from sendmail, but only since I wrote header out first. Still trying
:>to get the output of sendmail written to a file, I thought it would
:>be something like this:
:>open(LOG, ">>error.log") or die("Can't open log file, $!");
:>unless (open STDERR, ">>&" . LOG) {
:> print "* Can't redirect STDERR: $!\n";
:> exit;
:>}
:>But not sure if that's what I really need to do. I am not sure
:>if sendmail's output is coming from STDIN or STDERR or what.
:>The "unless" statement is from a snippet I got somewhere,
:>and I read the FAQ which said you had to open the filehandle
:>you wanted to dup in the same mode, hence the ">>&" for appending
:>to the LOG file.
Um. No. That won't do what you want. Go back and read
`perldoc -q stderr` again from start to finish.
You were doing this:
open(MAIL, "|sendmail whatever_args") or die ...
Instead, you could do this:
unlink("/tmp/tmp$$") if (-e "/tmp/tmp$$); # Probably should error check
open(MAIL, "|sendmail whatever_args 2>/tmp/tmp$$") or die...;
# Or if sendmail writes to stdout and stderr
open(MAIL, "|sendmail whatever_args >/tmp/tmp$$ 2>&1") or die...;
# print to sendmail pipe like you already do.
close(MAIL) or die "Failed to write message to sendmail: $!";
# Test the close. If the OS was unable to fork and exec sendmail
# for you or if sendmail died before you finished writing to
# it, then you would find that out here.
if (open(SMERROR, "/tmp/tmp$$")) {
while (<SMERROR>) {
# Parse it? Just send it to a log? Whatever you want.
}
close SMERROR;
} else {
# Log some message? This is an unlikely event. I suppose
# sombody else could own an existing /tmp/tmp$$ and the
# unlink failed. Up to you how careful you want to be with
# it
}
unlink("/tmp/tmp$$") if (-e "/tmp/tmp$$);
--
// Lee.Lindley /// I used to think that being right was everything.
// @bigfoot.com /// Then I matured into the realization that getting
//////////////////// along was more important. Except on usenet.
------------------------------
Date: Sun, 21 Nov 1999 20:49:34 GMT
From: pudge@pobox.com (Chris Nandor)
Subject: Re: Serious memory leak in MacPERL?
Message-Id: <pudge-2111991549340001@192.168.0.7>
In article <sheppard-1711990811420001@192.168.0.1>, sheppard@magma.ca (Tom
Sheppard) wrote:
# Regrettably, this will not work as the hashes are so large that the
# "foreach" can not be executed without running out of memory. It seems that
# Perl tries to create an array of keys rather than just walking down the
# hash. As a result, this creates an even higher memory demand. The
# "foreach" cannot be used for any purpose, let alone delete.
each() can be used specifically to avoid this.
while (my($k, $v) = each %hash) { # get one pair at a time
# ...
}
--
Chris Nandor mailto:pudge@pobox.com http://pudge.net/
%PGPKey = ('B76E72AD', [1024, '0824090B CE73CA10 1FF77F13 8180B6B6'])
------------------------------
Date: Sun, 21 Nov 1999 22:37:47 GMT
From: John Arrowwood <jarrowwx@NOSPAM.home.com>
Subject: Re: Shared variables between perl and embedded sh scripts ???
Message-Id: <38387461.8F91EE60@NOSPAM.home.com>
otrcomm@wildapache.net wrote:
> However, the variables are not available in the shell script. Is
> there a way to have these variables available in my shell script also?
The variables are interpolated before the code is passed to the shell
script. You can have a line at the top, like so
SHELLVAR=$perlvar
which will allow the values to get passed into the shell script the way
you want them to. Or, if you just use $perlvar in the script, it will be
treated as a constant wherever it occurs.
You can NOT, however, make changes in the shell script version of the
variable and have the change reflected in the Perl variable, no matter
how hard you try...
> I have some large shell scripts and I am too lazy to translate the
> logic to perl (some of it I don't even know how to) and want to just
> wrap them in a 'system' function and embed the wrapped logic in perl
> scripts that expand the functionality of the original scripts.
Sometimes laziness is a virtue, other times it makes things harder than
they need to be. When I was first learning Perl, I still created shell
scripts for some things, but as I learned more, it became easier. One of
the things that helped a lot was reading the perlfunc man page, which
allowed me to see how to do all the things I was using shell scripts to
do...
> Another question! Before I can have access to the routines in
> 'initialize.sub', I have to copy 'initialize.sub' to
> /usr/lib/perl5/5.00503/i386-linux. I believe that this is because I
> do not have something setup correctly in my perl installation, but I
> do not know what. Any ideas? I want to keep 'initialize.sub' in the
> same directory as the perl script
Can't help you here (sorta), because for me, as long as the included file
is in the current working directory, it has always worked. If you are
not IN the directory that the script is running in, that can change
things.
What I did, which may help, is created a common library directory, then
used BEGIN { push @INC, '</absolute/lib-dir>'; } in order to make sure
that perl could find the library when it needed it.
Hope that helps!
-- John
------------------------------
Date: Sun, 21 Nov 1999 17:07:52 -0800
From: David Cassell <cassell@mail.cor.epa.gov>
Subject: Re: signature question (was Re: Help with Stoopid Nutscrape (Netscape))
Message-Id: <38389768.5E80FB4F@mail.cor.epa.gov>
Jonathan Stowe wrote:
[snip]
> How come you punks are getting free copies of books - how do I get in the
> rubber chicken circuit here ?
I did the Manning webmaster a little favor and corrected a few
typos. As a thank-you, I got that book. Not something likely
to get repeated.
Don't tell Andrew, but I *really* wanted to get Damian's book
instead. I'll end up paying real $$$ for it, I guess.
Still, I am *really* glad I got Andrew's book. I wouldn't
have bought it. But I can now recommend it to true beginners.
[Sorry, Randal.]
David
--
David Cassell, OAO cassell@mail.cor.epa.gov
Senior computing specialist
mathematical statistician
------------------------------
Date: Mon, 22 Nov 1999 12:06:45 +1100
From: "Paul" <palchin@dragnet.com.au>
Subject: Trapping Error Messages
Message-Id: <38389894.0@neptune.dragnet.com.au>
Hi,
I need to be able to trap all error messages generated by my perl scripts
that run when called via a browser.
Is there an easy way to do this or a module to use ? I'd like to store it in
say /cgi-bin/errors.log & possibly have the error bounced on to the browser
window ?
Thanks in advance,
Paul
Please cc reply to my email
paul@dragnet.com.au
------------------------------
Date: Sun, 21 Nov 1999 20:24:08 -0500
From: "Dave Kaufman" <david@gigawatt.com>
Subject: Re: Trapping Error Messages
Message-Id: <38389b46@nntp2.nac.net>
Paul <palchin@dragnet.com.au> wrote...
> I need to be able to trap all error messages generated by my perl scripts
> that run when called via a browser.
> Is there an easy way to do this or a module to use ? I'd like to store it
in
> say /cgi-bin/errors.log & possibly have the error bounced on to the
browser
> window ?
Yes. the CGI::Carp module does exactly these tasks, available from CPAN.
-dave
------------------------------
Date: Mon, 22 Nov 1999 03:42:29 GMT
From: bmccoy@news.lan2wan.com (Brett W. McCoy)
Subject: Re: Trapping Error Messages
Message-Id: <slrn83hf53.jbm.bmccoy@dragosani.lan2wan.com>
Also sprach Paul <palchin@dragnet.com.au>:
>I need to be able to trap all error messages generated by my perl scripts
>that run when called via a browser.
>Is there an easy way to do this or a module to use ? I'd like to store it in
>say /cgi-bin/errors.log & possibly have the error bounced on to the browser
>window ?
A lot depends on what server you are using (rather than the browser), and
what modules you are using to generate CGI output. Under Apache, for
instance, your errors go into its error log (becoming, essentially,
STDERR). If you want errors going to the browser, use the Carp module,
with the fatalsToBrowser pragma:
use Carp qw(fatalsToBrowser);
You can also just trap $! and print it to the browser screen, and log
errors yourself (not a bad idea, actually -- I usually opt for that
myself).
--
Brett W. McCoy
http://www.lan2wan.com/~bmccoy/
-----------------------------------------------------------------------
Hacking's just another word for nothing left to kludge.
------------------------------
Date: Mon, 22 Nov 1999 03:44:11 GMT
From: bmccoy@news.lan2wan.com (Brett W. McCoy)
Subject: Re: Trapping Error Messages
Message-Id: <slrn83hf89.jbm.bmccoy@dragosani.lan2wan.com>
Also sprach Brett W. McCoy <bmccoy@news.lan2wan.com>:
>use Carp qw(fatalsToBrowser);
I'm sorry -- you should use CGI::Carp, not the plain Carp module.
--
Brett W. McCoy
http://www.lan2wan.com/~bmccoy/
-----------------------------------------------------------------------
Love is like the measles; we all have to go through it.
-- Jerome K. Jerome
------------------------------
Date: Sun, 21 Nov 1999 10:13:41 -0800
From: Tom Phoenix <rootbeer@redcat.com>
Subject: Re: Un deletable files HELP!!!
Message-Id: <Pine.GSO.4.10.9911211007290.16575-100000@user2.teleport.com>
On Sat, 20 Nov 1999, Honey wrote:
> I have a cgi that wrote a file with non-standard characters. now I
> can't delete the file
Try specifying the filename the same way you did when you created it.
> I've tried an "unlink routine with a wild card and
> it only deletes my cgi.
Ha! Ha! Oh, excuse me. You must have the wrong wildcard. But if you need
to do so, use readdir and friends to get the real name, then pass that to
unlink.
And, after this, (tell your webmaster to) set up the cgi-bin directory and
its contents to not be writable by the webserver's process-ID. And keep
your data files in another directory, one which isn't served over the web.
Else you're potentially opening serious security holes. But this advice
about configuring webservers isn't on-topic for a Perl newsgroup, so I'll
stop here.
> I only have FTP access to the site.
Can't you use FTP to delete files? But you should get better access, or a
better site. Cheers!
--
Tom Phoenix Perl Training and Hacking Esperanto
Randal Schwartz Case: http://www.rahul.net/jeffrey/ovs/
------------------------------
Date: Sun, 21 Nov 1999 17:01:02 -0800
From: David Cassell <cassell@mail.cor.epa.gov>
Subject: Re: What is a good book on Perl
Message-Id: <383895CE.DC6EF60C@mail.cor.epa.gov>
Uri Guttman wrote:
[snip]
> the new johnson book from manning: elements of programming in perl (we
> need a nickname or an abbrev for that) is aimed at first time
The 'woman in a fez' book?
The 'fashion-victim' book?
All the Manning books seem to have this theme in their cover art.
["Is that a theme or a motif, Pete?" "I dunno, Bob."]
I had some other ideas for a name, but my wife hit my on the
arm when I tried them out on her. So they're not suitable
for a public forum. :-)
David
--
David Cassell, OAO cassell@mail.cor.epa.gov
Senior computing specialist
mathematical statistician
------------------------------
Date: Sun, 21 Nov 1999 17:05:00 -0800
From: David Cassell <cassell@mail.cor.epa.gov>
Subject: Re: What is a good book on Perl
Message-Id: <383896BC.D138DFF9@mail.cor.epa.gov>
Wyzelli wrote:
[snip]
> Any comments from anyone regarding
>
> Eric C. Herman: "Mastering Perl 5" from Sybex?
That's not the same guy who wrote that ghastly CGI-and-Perl
book for SamsNet, is it?
"Teach Yourself CGI Programming with Perl 5 in a week, Second Edition"
by Eric Herrmann [NOT recommended if you want to write Perl]
If it's the same guy, I doubt the book is worth what you paid
for it. Even if you got it for free.
David
--
David Cassell, OAO cassell@mail.cor.epa.gov
Senior computing specialist
mathematical statistician
------------------------------
Date: Sun, 21 Nov 1999 10:37:16 -0800
From: Tom Phoenix <rootbeer@redcat.com>
Subject: Re: Writing data in another server
Message-Id: <Pine.GSO.4.10.9911211034020.16575-100000@user2.teleport.com>
On Sun, 21 Nov 1999 jampa@my-deja.com wrote:
> I have a file in my Web Server that must be written by the wwwusers,
> so it's 777
Well, at least some of those bits are useless.
> i'm wondering if users can only write to this file using my scripts or
> someone more "evil" can use a local script or sort of to write data on
> my server?
Any program on your system can modify that file, potentially. For more
information on Unix permission bits, check your system's chmod(1) manpage
and the related manpages it references (directly and indirectly), any good
introductory book on Unix, and (the FAQ of) a newsgroup about Unix
systems. Probably in that order.
Cheers!
--
Tom Phoenix Perl Training and Hacking Esperanto
Randal Schwartz Case: http://www.rahul.net/jeffrey/ovs/
------------------------------
Date: Sun, 21 Nov 1999 20:57:23 GMT
From: jampa@my-deja.com
Subject: Re: Writing data in another server
Message-Id: <819mbi$m4k$1@nnrp1.deja.com>
> Any program on your system can modify that file, potentially.
Just programs in my server, is that right? Or programs hosted at others
can modify?
Thanx
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Sun, 21 Nov 1999 17:37:07 -0800
From: David Cassell <cassell@mail.cor.epa.gov>
Subject: Re: Writing data in another server
Message-Id: <38389E43.B8DE73BD@mail.cor.epa.gov>
jampa@my-deja.com wrote:
>
> > Any program on your system can modify that file, potentially.
>
> Just programs in my server, is that right? Or programs hosted at others
> can modify?
Since you set the permissions at 0777, any program from anywhere
which can gain access to that file can modify it. Since you're
using a webserver, there is the potential for just about anyone
on the planet getting at it one way or another [depending on
things such as where your file is, and how the security on your
server is set].
You may want to ask about this in the
comp.infosystems.www.authoring.cgi newsgroup, and to read
the FAQs referenced in the first question in perlfaq9 .
David
--
David Cassell, OAO cassell@mail.cor.epa.gov
Senior computing specialist
mathematical statistician
------------------------------
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 V9 Issue 1454
**************************************
