[19468] in Perl-Users-Digest
Perl-Users Digest, Issue: 1663 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Aug 30 21:10:25 2001
Date: Thu, 30 Aug 2001 18:10:11 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Message-Id: <999220210-v10-i1663@ruby.oce.orst.edu>
Content-Type: text
Perl-Users Digest Thu, 30 Aug 2001 Volume: 10 Number: 1663
Today's topics:
registration worries (Mr. Green)
Re: registration worries (Mark Jason Dominus)
Re: registration worries <krahnj@acm.org>
Re: Script not reading templates - why?? (Martien Verbruggen)
Re: Sort output and find last. <pilsl_@goldfisch.at>
Re: Using perl for a server daemon????? (Martien Verbruggen)
Re: Using perl for a server daemon????? <pilsl_@goldfisch.at>
Re: Weird @INC if run from web (Martien Verbruggen)
Re: Weird @INC if run from web <samneric@tigerriverOMIT-THIS.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 30 Aug 2001 16:06:13 -0700
From: greenseaweed@aol.com (Mr. Green)
Subject: registration worries
Message-Id: <5370f8aa.0108301506.a953820@posting.google.com>
Hi,
My registration system seems to work fine. No problems so far. But
since I am not a wizard yet, I wanted to pass along part of my code
and see what people thought of it. I am looking for any possible
improvements. Thank you so very much.
-------------------------------------------------------------------------------
$Path = '/local/etc/httpd/htdocs/blah/registration';
opendir(THATDIR, $Path) or die "Cannot open path: $!";
@allfiles = readdir THATDIR;
closedir THATDIR;
# Generate random file name (which will be a random number.)
$filename = random_name();
sub random_name {
srand(time() ^ ($$ + ($$ << 15)) );
$rand1 = int(rand(9999));
while ($rand1 < 1000) {
$rand1 = int(rand(9999));
}
# See if the random name/number already exists in the directory.
# If so, call the subroutine again.
$results = grep(/$rand1/,@allfiles);
if ($results) {
random_name();
}
else {
return $rand1;
}
}
------------------------------
Date: Fri, 31 Aug 2001 00:22:00 GMT
From: mjd@plover.com (Mark Jason Dominus)
Subject: Re: registration worries
Message-Id: <3b8ed8a7.11f9$2e8@news.op.net>
In article <5370f8aa.0108301506.a953820@posting.google.com>,
Mr. Green <greenseaweed@aol.com> wrote:
>sub random_name {
>
> srand(time() ^ ($$ + ($$ << 15)) );
srand() should be called at most once per program execution. It is
incorrect to call it each time random_name() is invoked.
> $rand1 = int(rand(9999));
> while ($rand1 < 1000) {
> $rand1 = int(rand(9999));
> }
Here you want to use the 'do-while' construction:
do {
$rand1 = int(rand(9999));
} while ($rand1 < 1000);
This does the assignment before the test. But it's simpler yet to
just get the generation right on the first try. You want to generate
a random number between 1000 and 9999. So do:
$rand1 = int(1000 + rand(9000));
(Notice also that your original code has an off-by-one error; it only
generates numbers up to 9998, not 9999.)
># See if the random name/number already exists in the directory.
># If so, call the subroutine again.
>
> $results = grep(/$rand1/,@allfiles);
Here you're using a pattern match to see if $rand1 appears in
@allfiles. At best, this is inefficient. At worst, it's incorrect,
because if you one day decide to allow numbers of different lengths,
you'll find that /1234/ matches "71234" when you don't want it to.
Better code is:
$results = grep($rand1 eq $_ , @allfiles);
This tests to see if $rand1 is identical to any item of @allfiles.
The $results variable is useless, because you use it only once,
immediately after setting it, and never again. (Such variables
sometimes have value as documentation, but the name 'results' doesn't
accomplish that either.) Instead, just use:
if (grep($rand1 eq $_ , @allfiles)) {
...
This gets rid of $results.
With these changes, the code looks like this:
sub random_name {
$rand1 = int(1000 + rand(9000));
if (grep($rand1 eq $_ , @allfiles)) {
random_name();
} else {
return $rand1;
}
}
We should declare $rand1 with 'my', so that it won't conflict with any
other use of '$rand1' that happens to appear elsewhere in the program:
my $rand1 = int(1000 + rand(9000));
The 'grep' is going to be slow if @allfiles is large. When you want
to know if a certain item is present in an array, that's usually a
good sign that the array should have been a hash.
We could use a hash here, but there's an even better option: What
you're really trying to find out is if the file already exists. Perl
has a built-in way of asking if a file already exists, written '-e'.
('e' for 'exists'.)
Using '-e', the 'grep' test simply becomes:
if (-e "$Path/$rand1") {
random_name();
} else {
return $rand1;
}
Now you can get rid of @allfiles completely, and you can also get rid
of the opendir-readdir-closedir code.
random_name() contains a recursive call to itself, which is simple,
but in this case what you're really trying to accomplish is simply to
repeat the selection of $rand1 until you find an unused value. This
can be accomplished with a simple loop:
sub random_name {
my $rand1;
do {
$rand1 = int(1000 + rand(9000));
} while ( -e "$Path/$rand1" );
return $rand1;
}
The final, complete version is:
$Path = '/local/etc/httpd/htdocs/blah/registration';
srand(time() ^ ($$ + ($$ << 15)) );
# Generate random file name (which will be a random number.)
$filename = random_name();
sub random_name {
my $rand1;
do {
$rand1 = int(1000 + rand(9000));
} while ( -e "$Path/$rand1" );
return $rand1;
}
This is 8 lines long, and the original version was 14, so we've
eliminated about half the code while improving performance and
reliability.
You may also enjoy these articles, which are similar to this one:
http://www.perl.com/pub/2000/04/raceinfo.html
http://www.perl.com/pub/2000/06/commify.html
http://www.perl.com/pub/2000/11/repair3.html
http://www.oreillynet.com/pub/a/network/2001/05/18/perl_redflags.html
Hope this helps.
--
@P=split//,".URRUU\c8R";@d=split//,"\nrekcah xinU / lreP rehtona tsuJ";sub p{
@p{"r$p","u$p"}=(P,P);pipe"r$p","u$p";++$p;($q*=2)+=$f=!fork;map{$P=$P[$f^ord
($p{$_})&6];$p{$_}=/ ^$P/ix?$P:close$_}keys%p}p;p;p;p;p;map{$p{$_}=~/^[P.]/&&
close$_}%p;wait until$?;map{/^r/&&<$_>}%p;$_=$d[$q];sleep rand(2)if/\S/;print
------------------------------
Date: Fri, 31 Aug 2001 00:55:56 GMT
From: "John W. Krahn" <krahnj@acm.org>
Subject: Re: registration worries
Message-Id: <3B8EE110.58D317A9@acm.org>
"Mr. Green" wrote:
>
> Hi,
>
> My registration system seems to work fine. No problems so far. But
> since I am not a wizard yet, I wanted to pass along part of my code
> and see what people thought of it. I am looking for any possible
> improvements. Thank you so very much.
perldoc -q "How do I make a temporary file name"
John
--
use Perl;
program
fulfillment
------------------------------
Date: Fri, 31 Aug 2001 00:02:39 GMT
From: mgjv@tradingpost.com.au (Martien Verbruggen)
Subject: Re: Script not reading templates - why??
Message-Id: <slrn9otl0v.1jv.mgjv@verbruggen.comdyn.com.au>
On Thu, 30 Aug 2001 11:20:07 +0100,
Gifford Birchley <gbirchley@hotmail.com> wrote:
> I have a Perl application from Network Solutions - ISP Tools v1.3 - which
And what does the support department of Network Solutions have to say
about this problem? Or don't they offer support?
What does the documentation say about this? Does it say you have to do
anything after 'installing' new templates? Or is there no
documentation?
Maybe you should whinge to Network Solutions.
> reads in a set of templates and returns formatted web pages to STDOUT. The
> templates are supposed to be editable to customise the HTML output. Problem
> is, the script seems to be reading in the templates first time it runs, and
> then ignoring them from then on. I can edit, move or delete the templates -
> no change! Even rebooting - no change!! I am running RH Linux 7.1,
Sounds like caching to me. I'd look for cached copies somewhere, and
delete them. If it is caching, then I'd say it is behaving pretty
dumb, or you're not doing what you're supposed to do when updating
templates.
Martien
--
Martien Verbruggen |
Interactive Media Division | Never hire a poor lawyer. Never buy
Commercial Dynamics Pty. Ltd. | from a rich salesperson.
NSW, Australia |
------------------------------
Date: Fri, 31 Aug 2001 02:29:54 +0200
From: peter pilsl <pilsl_@goldfisch.at>
Subject: Re: Sort output and find last.
Message-Id: <3b8eda85$1@e-post.inode.at>
Joe Meyer wrote:
> I am a beginner in Perl programming. I am looking for a way to sort a
> dataset on a Perl variable, so multiple responses to an internet survey
> are
> grouped together. Then, I want to pick up the last non-missing response
> to
> each question for each respondent. I think I know how to sort the data,
> but I am not sure how to pick up the last non-missing value of each
> variable after the sort is done.
>
Chris is right : I really dont understand what you want to do ...
peter
--
mag. peter pilsl
pilsl_@goldfisch.at
http://www.goldfisch.at
------------------------------
Date: Fri, 31 Aug 2001 00:14:25 GMT
From: mgjv@tradingpost.com.au (Martien Verbruggen)
Subject: Re: Using perl for a server daemon?????
Message-Id: <slrn9otln0.1jv.mgjv@verbruggen.comdyn.com.au>
On 30 Aug 2001 07:29:06 -0700,
Gary Cub <gary@irl.com> wrote:
> Hi,
>
> I have been asked to build a server daemon to run on a Linux
> platform and was thinking about doing it in PERL. Can anyone tell me
> of any security problems their would be in using PERL over C, as I
> prefer PERL.
There are no problems with Perl specific to writing 'server daemons'
AFAIK. It's a silly comparison anyway. Perl and C are languages.
Languages are generally not the things that have security problems.
Applications do. Perl applications have fewer problems with buffer
overrun exploits, for example, because memory management works in a
totally different way. However, many Perl applications have problems
with spawning shells, and using magic opens with user input, which
might be exploited.
Security is not a function of the language, but of how you write your
application. Each language, however, has its own things to look out
for. Perl makes your life a little easier by providing the -T flag,
which will alert you to many potentially threatening things.
All the above aside: your question about 'security problems' is way,
way, way too vague. You haven't even specified anything about what
this server daemon will be doing, and if and how it will be accessible
by the outside world, internal networks, external networks, trusted
users, untrusted users, etc..
> Also, if there is no reasons not to use PERL why then are more
> server daemons written in PERL??
I think you meant to ask why there _aren't_ more servers written in
Perl?
History.
Tradition.
Performance.
Expedience.
Maybe some other reasons. Each 'server daemon' probably has different
reasons. Some daemons need very tight OS specific interaction, which
is often easier to do in C than in Perl. Many daemons have an age old
tradition, that streches back way before Perl was born. Many daemons
need very good performance, and maybe more importantly, low resource
usage, neither of which Perl can provide as well as C can.
Martien
--
Martien Verbruggen |
Interactive Media Division | Unix is the answer, but only if you
Commercial Dynamics Pty. Ltd. | phrase the question very carefully
NSW, Australia |
------------------------------
Date: Fri, 31 Aug 2001 02:32:25 +0200
From: peter pilsl <pilsl_@goldfisch.at>
Subject: Re: Using perl for a server daemon?????
Message-Id: <3b8edb20@e-post.inode.at>
Gary Cub wrote:
> Hi,
>
> I have been asked to build a server daemon to run on a Linux
> platform and was thinking about doing it in PERL. Can anyone tell me
> of any security problems their would be in using PERL over C, as I
> prefer PERL.
The problem is not perl itself. It may be the underlying libs and of course
your code might have holes ...
> Also, if there is no reasons not to use PERL why then are more
> server daemons written in PERL??
>
C performs better ...
peter
--
mag. peter pilsl
pilsl_@goldfisch.at
http://www.goldfisch.at
------------------------------
Date: Thu, 30 Aug 2001 23:48:06 GMT
From: mgjv@tradingpost.com.au (Martien Verbruggen)
Subject: Re: Weird @INC if run from web
Message-Id: <slrn9otk5m.1jv.mgjv@verbruggen.comdyn.com.au>
On 30 Aug 2001 03:00:53 -0700,
Batara Kesuma <bkesuma@yahoo.com> wrote:
> Hi,
>
>
> Can't locate cookie.pl in @INC (@INC contains: /var/www/html/mixed
> /usr/lib/perl5/5.6.1/i386-linux /usr/lib/perl5/5.6.1
> /usr/lib/perl5/site_perl/5.6.1/i386-linux
> /usr/lib/perl5/site_perl/5.6.1
> /usr/lib/perl5/site_perl/5.6.0/i386-linux
> /usr/lib/perl5/site_perl/5.6.0 /usr/lib/perl5/site_perl .) at
> /var/www/html/mixed/apply.cgi line 5.
> [Thu Aug 30 18:57:09 2001] [error] [client 192.168.0.77] Premature end
> of script headers: /var/www/html/mixed/apply.cgi
And you expected this to work because?
Because cookie.pl is in the same directory as your program? The
current working directory and the location of your program are not the
same thing. I doubt that the web server executes your program by
first cd-ing into the directory it lives in.
The Perl FAQ, section 8 has the following questions:
How do I keep my own module/library directory?
How do I add the directory my program lives in to the mod
ule/library search path?
How do I add a directory to my include path at runtime?
I think that between them, they answer your question.
Martien
--
Martien Verbruggen |
Interactive Media Division | "In a world without fences,
Commercial Dynamics Pty. Ltd. | who needs Gates?"
NSW, Australia |
------------------------------
Date: Thu, 30 Aug 2001 20:39:43 -0400
From: Samneric <samneric@tigerriverOMIT-THIS.com>
Subject: Re: Weird @INC if run from web
Message-Id: <MPG.15f8a6db1a4089399896a7@news.onemain.com>
Batara Kesuma wrote:
> Hi,
>
> I tried using require 'something.pl' so I could run the subroutine
> inside that file from my main file. If I run it from the terminal, it
> is ok. But when I try to run it from the web, it gives me 500 error.
Okay:
The directory is in @INC.
The cookie.pl file is in mixed.
That leaves:
From the web, you're not "owner".
Perl doesn't need direcory read permission to invoke the script.
Perl DOES need it to look for cookie.pl in mixed though.
Check your directory read permissions for mixed.
------------------------------
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 1663
***************************************
