[24335] in Perl-Users-Digest
Perl-Users Digest, Issue: 6524 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed May 5 18:06:01 2004
Date: Wed, 5 May 2004 15:05:18 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Wed, 5 May 2004 Volume: 10 Number: 6524
Today's topics:
age file (max)
Re: assigning variable to a pipe <Joe.Smith@inwap.com>
Re: At wits end! LWP and IIS(?) <gnari@simnet.is>
Re: Background jobs in Perl <webmaster @ infusedlight . net>
Re: Background jobs in Perl <ittyspam@yahoo.com>
Re: calculate date 4 days ago <me@privacy.net>
Re: calculate date 4 days ago <jtc@shell.dimensional.com>
Directory sorted in chronological order <mdudley@king-cart.com>
Re: Finding all open filehandles and closing them befor <troc@pobox.com>
Re: free source authentication script <webmaster @ infusedlight . net>
Re: free source authentication script <webmaster @ infusedlight . net>
Re: free source authentication script <ittyspam@yahoo.com>
Re: free source authentication script <ittyspam@yahoo.com>
Re: free source authentication script <noreply@gunnar.cc>
Re: free source authentication script <ittyspam@yahoo.com>
Re: free source authentication script <jtc@shell.dimensional.com>
Re: free source authentication script <noreply@gunnar.cc>
Re: free source authentication script <trammell+usenet@hypersloth.invalid>
Re: free source authentication script <jtc@shell.dimensional.com>
Re: free source authentication script <sbryce@scottbryce.com>
function guessing regular expressions <wieniuszka@gazeta.pl>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 5 May 2004 12:48:20 -0700
From: maxgmt@hotmail.com (max)
Subject: age file
Message-Id: <e86dfd41.0405051148.546c4833@posting.google.com>
hi guys!!!
if ( -M $file ) > 1 do something ...
1 is one day , .5 is 12hours -M modification time
livefreeordie!!!
------------------------------
Date: Wed, 05 May 2004 20:10:58 GMT
From: Joe Smith <Joe.Smith@inwap.com>
Subject: Re: assigning variable to a pipe
Message-Id: <mTbmc.27656$Ia6.4126342@attbi_s03>
mike wrote:
> I did not use DBI.pm because i have trouble installing the
> module. I am using Solaris and the perl version is 5.005. My C compiler is
> not gcc but proprietary C package from Sun.
It is for that very reason that many people stop using /usr/perl5/bin/perl
for anything but Sun-provided startup scripts.
1) Download gcc from www.sunfreeware.com and install it in /usr/local.
2) Download newer perl from www.sunfreeware.com and install it in /usr/local.
3) rm /usr/bin/perl; ln -s /usr/local/bin/perl /usr/bin/perl
The above has no affect on scripts that explict use /usr/perl5/bin/perl.
-Joe
------------------------------
Date: Wed, 5 May 2004 18:11:48 -0000
From: "gnari" <gnari@simnet.is>
Subject: Re: At wits end! LWP and IIS(?)
Message-Id: <c7bam5$2eo$1@news.simnet.is>
"Calvine Chew" <calvine.is.not@starhub.net.sg> wrote in message
news:c7abh8$kfm$1@reader01.singnet.com.sg...
>
> "gnari" <gnari@simnet.is> wrote in message
> news:c7aaap$uir$1@news.simnet.is...
> > "Calvine Chew" <calvine.is.not@starhub.net.sg> wrote in message
> > news:c79m4b$806$1@reader01.singnet.com.sg...
> > > [problems with relayed upload]
> >
> > did you try to upload directly to the second script?
> > gnari
> >
> Yes indeed. The 2nd script (up.cgi) works perfectly and is able to save
the
> file (I verified this via a multipart/form-data html form to up.cgi). I
> checked the server log and there is no reference to any 501 errors or even
> requests to up.cgi!!
>
> I conclude that this means the request is not even going out. I understand
> that the header Client-Warning is inserted by LWP. Could this mean that
the
> script is failing at upload.cgi (1st script)?
yes. it means that the LWP::UserAgent request call (or
the HTTP::Request::Common POST call) is failing
I have never used these for file upload, and can't be bothered to do
research,
but I suspect that you at least need to specify multipart/form-data in
the POST call, and probably some more work. an upload post is in a pretty
different format that regular posts, and I am not sure
HTTP::Request::Common
supports it, thus the "501 (Not Implemented)" message.
good luck
gnari
------------------------------
Date: Wed, 5 May 2004 10:37:42 -0800
From: "Robin" <webmaster @ infusedlight . net>
Subject: Re: Background jobs in Perl
Message-Id: <c7bcaq$bqs$1@reader2.nmix.net>
"Mark J Fenbers" <Mark.Fenbers@noaa.gov> wrote in message
news:4098F6C2.FA9D6C13@noaa.gov...
> In my Perl script, I want to launch a command and not wait for it to
> return before moving on.
>
> In a Bash script, I can do it this way:
>
> /home/fenbers/myscript.bash &
>
> In Perl, can I just do this:
>
> `/home/fenbers/myscript.bash &`;
>
> Or is there a better way of doing this?
>
> Mark
see the perldocs for fork. If you don't know how to run perldocs, it runs as
a program from your command line, "perldoc whatever", if you really don't
know how to run a command line operation go to perldoc.com. Although it's
still down for a few days, probably/hopefullly.
-Robin
------------------------------
Date: Wed, 5 May 2004 14:56:42 -0400
From: Paul Lalli <ittyspam@yahoo.com>
Subject: Re: Background jobs in Perl
Message-Id: <20040505145501.O25082@dishwasher.cs.rpi.edu>
On Wed, 5 May 2004, Robin wrote:
> "Mark J Fenbers" <Mark.Fenbers@noaa.gov> wrote in message
> news:4098F6C2.FA9D6C13@noaa.gov...
> > In my Perl script, I want to launch a command and not wait for it to
> > return before moving on.
> >
> > In a Bash script, I can do it this way:
> >
> > /home/fenbers/myscript.bash &
> >
> > In Perl, can I just do this:
> >
> > `/home/fenbers/myscript.bash &`;
> >
> > Or is there a better way of doing this?
> >
> > Mark
>
>
> see the perldocs for fork. If you don't know how to run perldocs, it runs as
> a program from your command line, "perldoc whatever", if you really don't
> know how to run a command line operation go to perldoc.com. Although it's
> still down for a few days, probably/hopefullly.
For the love of $DIETY, stop trying to help people!!! Not only has this
question been answered (correctly, as opposed to your post) already, but
who in the blue hell are *you* to be telling people to read the docs when
not 10 minutes ago you admitted you STILL haven't read perldoc perlsub
after MONTHS of people telling you to!?
Paul Lalli
------------------------------
Date: Thu, 6 May 2004 06:57:24 +1200
From: "Tintin" <me@privacy.net>
Subject: Re: calculate date 4 days ago
Message-Id: <c7bde2$1qhiv$1@ID-172104.news.uni-berlin.de>
"Jim Cochrane" <jtc@shell.dimensional.com> wrote in message
news:slrnc9g73c.o19.jtc@shell.dimensional.com...
> In article <rcgisfbvr79.fsf@Jon-Ericson.sdsio.prv>, Jon Ericson wrote:
> > jshaboo@hotmail.com (joe shaboo) writes:
> >
> >> I'm trying to list files that are 4 days old, and then perform an
> >> action on them. I don't care about any files that are newer (have been
> >> edited or touched in the last 4 days), only 4 days or older.
> >>
> >> I can do this either through SHELL or perl, which ever is easier.
> >
> > Using option 1:
> >
> > $ find . -mtime -4
>
> For files 4 days or more older, I believe what is needed is: -mtime +4
> (Check man find to be sure.)
The OP's specifications are contradictory. They say "have been edited or
touched in the last 4 days", then say "only 4 days or older"
------------------------------
Date: 5 May 2004 13:52:59 -0600
From: Jim Cochrane <jtc@shell.dimensional.com>
Subject: Re: calculate date 4 days ago
Message-Id: <slrnc9ihgr.aii.jtc@shell.dimensional.com>
In article <c7bde2$1qhiv$1@ID-172104.news.uni-berlin.de>, Tintin wrote:
>
> "Jim Cochrane" <jtc@shell.dimensional.com> wrote in message
> news:slrnc9g73c.o19.jtc@shell.dimensional.com...
>> In article <rcgisfbvr79.fsf@Jon-Ericson.sdsio.prv>, Jon Ericson wrote:
>> > jshaboo@hotmail.com (joe shaboo) writes:
>> >
>> >> I'm trying to list files that are 4 days old, and then perform an
>> >> action on them. I don't care about any files that are newer (have been
>> >> edited or touched in the last 4 days), only 4 days or older.
>> >>
>> >> I can do this either through SHELL or perl, which ever is easier.
>> >
>> > Using option 1:
>> >
>> > $ find . -mtime -4
>>
>> For files 4 days or more older, I believe what is needed is: -mtime +4
>> (Check man find to be sure.)
>
> The OP's specifications are contradictory. They say "have been edited or
> touched in the last 4 days", then say "only 4 days or older"
Funny, I didn't even notice that. I guess I just read it like a perl
compiler compiling a block - since the specs. end with: "edited or
touched in the last 4 days), only 4 days or older.", I guess I took the
last expression in the phrase "only 4 days or older" and took that as
the final value of his spec. :-)
--
Jim Cochrane; jtc@dimensional.com
[When responding by email, include the term non-spam in the subject line to
get through my spam filter.]
------------------------------
Date: Wed, 05 May 2004 17:40:23 -0400
From: Marshall Dudley <mdudley@king-cart.com>
Subject: Directory sorted in chronological order
Message-Id: <40995F47.D264A059@king-cart.com>
I need to get a directory listing that is sorted in chronological
order. Looking at the top of page 203 in the Camel book, it seems that
the following should work, replacing the grep with a sort:
opendir (DIR,"./");
@dir = sort -M, readdir(DIR);
closedir DIR;
foreach $line (@dir) {
$age = -M $line;
print "$age\n";
}
perl getage.pl
0.00255787037037037
30.0848148148148
0.0299537037037037
0.0286574074074074
0.0530208333333333
0.0525810185185185
0.0261689814814815
0.0246180555555556
0.00256944444444444
0.00269675925925926
However, as you can see, the directory is not being sorted by age at
all.
Can anyone see what my error is?
Thanks,
Marshall
------------------------------
Date: Wed, 05 May 2004 21:42:44 GMT
From: Rocco Caputo <troc@pobox.com>
Subject: Re: Finding all open filehandles and closing them before exiting
Message-Id: <slrnc9iocl.lqj.troc@eyrie.homenet>
On 3 May 2004 13:31:22 -0700, Bryan Castillo wrote:
> Rocco Caputo <troc@pobox.com> wrote in message news:<slrnc9879b.lqj.troc@eyrie.homenet>...
>>
>> I use this:
>>
>> use POSIX qw(MAX_OPEN_FDS);
>> POSIX::close($_) for $^F+1 .. MAX_OPEN_FDS;
>
> Are you sure MAX_OPEN_FDS is right?
>
[error message]
>
> I found this in limits.h
>
> #define OPEN_MAX 64 /* max # of files a process can have
> open */
>
> Is this what you meant?
>
[success message]
>
> Not really a perl question then, but if you do use this logic, are you
> assured that the OS will reuse file descriptor numbers? So there is a
> max of 64 open files on this particular system, but does that mean
> that all file descriptor numbers will be < OPEN_MAX? (I guess I
> should really ask on comp.unix.programmer or better yet read the
> Single Unix Specification).
I'm sorry. I had some code above it to set MAX_OPEN_FDS based on
_SC_OPEN_MAX. It would take a wild guess if _SC_OPEN_MAX wasn't
defined.
# Determine the most file descriptors we can use.
my $max_open_fds;
eval {
$max_open_fds = sysconf(_SC_OPEN_MAX);
};
$max_open_fds = 1024 unless $max_open_fds;
eval "sub MAX_OPEN_FDS () { $max_open_fds }";
die if $@;
It should probably check OPEN_MAX as well, just to be safe.
I'm pretty sure most (if not all) operating systems with the concept of
file descriptor numbers will reuse them. I've witnessed several of them
first-hand, including DOS, various forms of Windows, AIX, and OS/2. The
UNIX variants do it as a matter of course.
Descriptor numbers are used for things like select() bit vector indices,
so they can't increase forever. That might not stop someone from
writing a kernel that does it, but we can kneecap them and leave them by
the door as a reminder to the others. :)
-- Rocco Caputo - http://poe.perl.org/
------------------------------
Date: Wed, 5 May 2004 10:25:01 -0800
From: "Robin" <webmaster @ infusedlight . net>
Subject: Re: free source authentication script
Message-Id: <c7bblc$ble$1@reader2.nmix.net>
"Tassilo v. Parseval" <tassilo.parseval@rwth-aachen.de> wrote in message
news:c7a2jr$1bs0g$1@ID-231055.news.uni-berlin.de...
> Also sprach Robin:
>
> > www.infusedlight.net/robin/temp/auth.txt
> >
> > Comments on this? The bottom two subs are meant for the script that the
> > auth.pl script goes to and the way the cookies are set, makes it secure
in
> > that if someone forgets to logout of the administration or other script
that
> > auth.pl goes to and someone else points their browser to that script
that
> > auth points to, it will simply redirect them to whatever page the
webmaster
> > chooses, ie: auth.pl again or the entry point to auth.pl. Some of you
may
> > have been doing this very same thing, pointing your browser to the admin
> > script or something similar, and I spent an hour improving the script so
> > this major security flaw won't be present. At least now my site won't be
> > defaced in this form, anyway.
> Now I see that auth.pl does two other things: It creates a file
> "Loggedinfile.log" and sets a cookie. Would admin.pl use these two
> things to determine whether a user is logged in? I hope not.
> "Loggedinfile.log" only exists once which means that anybody could log
> in as long as at least one person is already authenticated. Doing
> authentication based on a cookie is a very bad idea as well, as cookies
> reside on the client machine and anybody could create such a thing
> manually.
Your right, I didn't think of that at all, but still, who's gonna go into
the temp internet folder and create a cookie? At least not most users. The
way it does it is that admin.pl checks for the loggedinfile.log file and the
cookie using the sub "login" and if one of them isn't there it redirects
back to another page: ie: the login page. If someone is already
authenticated, someone else won't be able to access admin.pl directly
because they won't set the cookie unless they know the password, or create
the cookie manually, because the cookie is set when the password is typed in
right or when the password is initially set... When someone logs out of the
admin script the static cookie, Log is set to a null value so it will not be
read.
-Robin
------------------------------
Date: Wed, 5 May 2004 10:33:55 -0800
From: "Robin" <webmaster @ infusedlight . net>
Subject: Re: free source authentication script
Message-Id: <c7bc4b$bqn$1@reader2.nmix.net>
"Tore Aursand" <tore@aursand.no> wrote in message
news:pan.2004.05.05.09.47.28.929692@aursand.no...
> On Tue, 04 May 2004 22:22:45 -0800, Robin wrote:
> > www.infusedlight.net/robin/temp/auth.txt
>
> A short summary:
>
> * You're _still_ not indenting your code properly.
It's indented in the way I like it. How would you define "properly"?
> * You're _still_ not using 'strict' (or 'warnings').
Most of my code does and this one will too, as soon as I get around to it.
> * You're _still_ not checking the outcome of 'open()'.
Yeah, I figure that there won't be too much of a race condition or anything
like that because there's only one person who accesses the code who runs the
files, unless there's more than one person who has the password and even so
it's minimal...
Also, this is a modified older script, I will get around to it, and I
apologize for not "doing my best" before posting it.
> * Yoy're _still_ using 'exit' where it's inappropriate.
Where? :-)
> * You're _still_ calling subroutines with '&', without
> knowing really why (obviously).
I'll grant you that, I have to read perlsub.
> * You're _still_ mixing HTML and Perl code.
Well, as tassilo said, what's the point of not using perl? Perl is great for
interpolation of variables in html code and stuff.
> * You're _still_ not validating the data you are using
> throughout the script.
What do you mean exactly?
> * You're _still_ not listening to the people in this
> group. Why do you bother at all? You don't want to
> learn anything, obviously!?
>
> As for this particular script:
>
> * Do you know how cookies work? You're definitely not
> using cookies the way they should (...) be used.
How should they be used?
> * It is possible to access (and download) the "private"
> files you are using. How secure is that?
Not the password file, I've already tried that... and the loggedinfile.log
file means nothing if you download it. If you found a way to download the
password file, let me know where it is in the code.
-Robin
------------------------------
Date: Wed, 5 May 2004 14:41:41 -0400
From: Paul Lalli <ittyspam@yahoo.com>
Subject: Re: free source authentication script
Message-Id: <20040505143905.J25082@dishwasher.cs.rpi.edu>
On Wed, 5 May 2004, Robin wrote:
>
> "Tassilo v. Parseval" <tassilo.parseval@rwth-aachen.de> wrote in message
> news:c7a2jr$1bs0g$1@ID-231055.news.uni-berlin.de...
> >
> > Now I see that auth.pl does two other things: It creates a file
> > "Loggedinfile.log" and sets a cookie. Would admin.pl use these two
> > things to determine whether a user is logged in? I hope not.
> > "Loggedinfile.log" only exists once which means that anybody could log
> > in as long as at least one person is already authenticated. Doing
> > authentication based on a cookie is a very bad idea as well, as cookies
> > reside on the client machine and anybody could create such a thing
> > manually.
>
>
> Your right, I didn't think of that at all, but still, who's gonna go into
> the temp internet folder and create a cookie? At least not most users.
Of course *most* users aren't going to do that. *Most* users aren't
trying to hack your site! You don't program securely for *most* users -
you program securely for the few users who *are* trying to be malevolent.
The fact that you keep taking these completely unnecessary risks with the
security of anyone foolish enough to use your scripts continues to prove
that you are NOT ready to be releasing code to the public. It's
irresponsible and rude, frankly.
Paul Lalli
------------------------------
Date: Wed, 5 May 2004 14:52:14 -0400
From: Paul Lalli <ittyspam@yahoo.com>
Subject: Re: free source authentication script
Message-Id: <20040505144153.B25082@dishwasher.cs.rpi.edu>
On Wed, 5 May 2004, Robin wrote:
> "Tore Aursand" <tore@aursand.no> wrote in message
> news:pan.2004.05.05.09.47.28.929692@aursand.no...
> > On Tue, 04 May 2004 22:22:45 -0800, Robin wrote:
> > > www.infusedlight.net/robin/temp/auth.txt
> >
> > A short summary:
> >
> > * You're _still_ not indenting your code properly.
>
> It's indented in the way I like it. How would you define "properly"?
>
How many people have told you to read perldoc perlstyle so far? You
clearly haven't done it. From said doc:
Regarding aesthetics of code lay out, about the only thing
Larry cares strongly about is that the closing curly bracket
of a multi-line BLOCK should line up with the keyword that
started the construct. Beyond that, he has other
preferences that aren't so strong:
o 4-column indent.
o Opening curly on same line as keyword, if possible,
otherwise line up.
o Space before the opening curly of a multi-line BLOCK.
Therefore:
if ($foo) {
bar();
}
or
if ($foo)
{
bar();
}
are good. What you do:
if ($foo)
{
bar();
}
is not.
> > * You're _still_ not using 'strict' (or 'warnings').
>
> Most of my code does and this one will too, as soon as I get around to it.
>
Why on earth would you cause that much extra work for yourself? Do you
truly not see that having strict and warnings enabled at the beginning of
development will take you *far* less time than trying to go back later and
making everything work with strict enabled?
> > * You're _still_ not checking the outcome of 'open()'.
>
> Yeah, I figure that there won't be too much of a race condition or anything
> like that because there's only one person who accesses the code who runs the
> files, unless there's more than one person who has the password and even so
> it's minimal...
Do you honestly believe that's the only reason open() might fail? If
so... damn, I don't even know what to say to that. And even if it *was*
the only reason - you again decide that the risk is small enough to not
bother simply typing 'or die'? That's one of your biggest problems, Robin
- that you consider there to be "acceptable risks" when it comes to
program security, functionality, and robustness. There aren't.
> Also, this is a modified older script, I will get around to it, and I
> apologize for not "doing my best" before posting it.
STOP FRIGGIN' DOING THAT. In the first place, no one here is ASKING to
see your scripts - you're posting these of your own accord, much like a
cat putting a dead mouse on the door, hoping we all say "ohhh, isn't that
wonderful!". If you insist on deluging us with all these scripts no one
cares about, you could *at least* have the decency to post the final
drafts rather than works in progress!
Excuse me while I go take several long deep breaths.
Paul Lalli
------------------------------
Date: Wed, 05 May 2004 21:02:11 +0200
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: free source authentication script
Message-Id: <c7be01$1vukp$1@ID-184292.news.uni-berlin.de>
Paul Lalli wrote:
> That's one of your biggest problems, Robin - that you consider
> there to be "acceptable risks" when it comes to program security,
> functionality, and robustness. There aren't.
Yes, there are. If there weren't, we all should better cease with
programming.
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: Wed, 5 May 2004 15:33:28 -0400
From: Paul Lalli <ittyspam@yahoo.com>
Subject: Re: free source authentication script
Message-Id: <20040505153157.B25082@dishwasher.cs.rpi.edu>
On Wed, 5 May 2004, Gunnar Hjalmarsson wrote:
> Paul Lalli wrote:
> > That's one of your biggest problems, Robin - that you consider
> > there to be "acceptable risks" when it comes to program security,
> > functionality, and robustness. There aren't.
>
> Yes, there are. If there weren't, we all should better cease with
> programming.
Yes, you're correct, there are of course some acceptable risks. I
overspoke. My point should have been that Robin considers far too many
unacceptable risks acceptable, and doesn't bother eliminating far too many
of the easily avoided risks.
Paul Lalli
------------------------------
Date: 5 May 2004 14:01:24 -0600
From: Jim Cochrane <jtc@shell.dimensional.com>
Subject: Re: free source authentication script
Message-Id: <slrnc9ii0l.aii.jtc@shell.dimensional.com>
In article <20040505144153.B25082@dishwasher.cs.rpi.edu>, Paul Lalli wrote:
> On Wed, 5 May 2004, Robin wrote:
>
>> "Tore Aursand" <tore@aursand.no> wrote in message
>> news:pan.2004.05.05.09.47.28.929692@aursand.no...
>> > On Tue, 04 May 2004 22:22:45 -0800, Robin wrote:
>> > > www.infusedlight.net/robin/temp/auth.txt
>> >
>> > A short summary:
>> >
>> > * You're _still_ not indenting your code properly.
>>
>> ...
>
>> > * You're _still_ not checking the outcome of 'open()'.
>>
>> Yeah, I figure that there won't be too much of a race condition or anything
>> like that because there's only one person who accesses the code who runs the
>> files, unless there's more than one person who has the password and even so
>> it's minimal...
>
> Do you honestly believe that's the only reason open() might fail? If
> so... damn, I don't even know what to say to that. And even if it *was*
Perhaps he's operating on a different plane of reality, using a system that
never has file storage failures, files are always readable and writable by
everyone, files are never locked, etc.
--
Jim Cochrane; jtc@dimensional.com
[When responding by email, include the term non-spam in the subject line to
get through my spam filter.]
------------------------------
Date: Wed, 05 May 2004 22:04:54 +0200
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: free source authentication script
Message-Id: <c7bhlm$21eiv$1@ID-184292.news.uni-berlin.de>
Paul Lalli wrote:
> Gunnar Hjalmarsson wrote:
>> Paul Lalli wrote:
>>> That's one of your biggest problems, Robin - that you consider
>>> there to be "acceptable risks" when it comes to program
>>> security, functionality, and robustness. There aren't.
>>
>> Yes, there are. If there weren't, we all should better cease with
>> programming.
>
> Yes, you're correct, there are of course some acceptable risks. I
> overspoke. My point should have been that Robin considers far too
> many unacceptable risks acceptable, and doesn't bother eliminating
> far too many of the easily avoided risks.
Then we are agreed. :)
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: Wed, 5 May 2004 20:43:43 +0000 (UTC)
From: "John J. Trammell" <trammell+usenet@hypersloth.invalid>
Subject: Re: free source authentication script
Message-Id: <slrnc9ikfv.3jq.trammell+usenet@hypersloth.el-swifto.com.invalid>
On 5 May 2004 14:01:24 -0600, Jim Cochrane wrote:
> Perhaps he's operating on a different plane of reality, using a system
> that never has file storage failures, files are always readable and
> writable by everyone, files are never locked, etc.
Sure, Robin is really some Vingean Entity from the outer reaches of the
Galaxy.
Welcome to the Unthinking Depths, dude. :-)
NO CARRIER
------------------------------
Date: 5 May 2004 14:49:57 -0600
From: Jim Cochrane <jtc@shell.dimensional.com>
Subject: Re: free source authentication script
Message-Id: <slrnc9ikrl.aii.jtc@shell.dimensional.com>
In article <slrnc9ikfv.3jq.trammell+usenet@hypersloth.el-swifto.com.invalid>, John J. Trammell wrote:
> On 5 May 2004 14:01:24 -0600, Jim Cochrane wrote:
>> Perhaps he's operating on a different plane of reality, using a system
>> that never has file storage failures, files are always readable and
>> writable by everyone, files are never locked, etc.
>
> Sure, Robin is really some Vingean Entity from the outer reaches of the
> Galaxy.
>
> Welcome to the Unthinking Depths, dude. :-)
>
> NO CARRIER
>
I was thinking, perhaps, another universe, where the laws of physics are
entirely different :-)
--
Jim Cochrane; jtc@dimensional.com
[When responding by email, include the term non-spam in the subject line to
get through my spam filter.]
------------------------------
Date: Wed, 05 May 2004 15:44:06 -0600
From: Scott Bryce <sbryce@scottbryce.com>
Subject: Re: free source authentication script
Message-Id: <109io0sfukbkub6@corp.supernews.com>
Robin wrote:
>> * You're _still_ not indenting your code properly.
>
>
> It's indented in the way I like it. How would you define "properly"?
The most common method, and therefore the most readable to the most people:
if (some condition) {
statement;
statement;
statement;
}
An acceptable method (which I personally use):
if (some condition)
{
statement;
statement;
statement;
}
>> * You're _still_ not using 'strict' (or 'warnings').
>
>
> Most of my code does and this one will too, as soon as I get around to it.
No. Do that first! Otherwise you will find yourself having to fix a lot
of code after you finally put these two lines in. Do it right the first
time.
>> * You're _still_ not checking the outcome of 'open()'.
>
>
> Yeah, I figure that there won't be too much of a race condition or anything
> like
It isn't about race conditions. If, for some reason, the file won't
open, the rest of your code will be working with missing data, or data
will be lost. You need to know that when you open the file.
>> * You're _still_ mixing HTML and Perl code.
>
>
> Well, as tassilo said, what's the point of not using perl? Perl is great for
> interpolation of variables in html code and stuff.
Ease of maintenance. Tassilo has probably worked on systems where the
output was complex enough that it didn't really matter. Take a look at
HTML::Template. It is simple, yet robust. It will make your code easier
to read and maintain. If you decide to change the layout of your pages,
it will make the changes MUCH easier. If you are using table layout now
and change to CSS layout, which you should, it will be easier to
re-write your templates than to re-write your Perl.
>> * You're _still_ not validating the data you are using
>> throughout the script.
>
>
> What do you mean exactly?
Is the data you are getting what you expect it to be? Don't count on the
form to guarantee good input. I can easily slap together a web page that
will send your script bad data. What happens to your script then?
BTW, what happens if two people try to log in at the same time? It looks
like the second one will stomp on the first one.
>> * Do you know how cookies work? You're definitely not
>> using cookies the way they should (...) be used.
>
>
> How should they be used?
I'm not an expert on security, but I do know this: don't send meaningful
information to the user in your cookie.
A couple more pointers:
print ("Enter password to login: <FORM METHOD=\"POST\"
ACTION=\"$rootfile\">");
could be written as:
print qq(Enter password to login: <FORM METHOD="POST" ACTION="$rootfile">);
It is easier to read.
Also, you need to comment better. Comments like:
## the subs below can be used in any script
don't tell the reader anything. Your comments should answer the
question, "What on earth is this section of code supposed to be doing?"
It will make your code easier to follow. And I'll guarantee you that if
you try to tweak your own code six months from now, you will be asking
yourself that question.
------------------------------
Date: Wed, 05 May 2004 23:10:52 +0200
From: wieniuszka <wieniuszka@gazeta.pl>
Subject: function guessing regular expressions
Message-Id: <c7bl80$995$1@inews.gazeta.pl>
Hi there,
have anyone tried to develop a function which given a number of strings
which have something in common returns a regular expression fitting those
strings?
Is something like this possible at all?
I'm affraid that the most difficult thing would be to teach the program
choose the best pattern, because the strings may have many features in
common and the computer woud have to choose 'the best' - and that would
require 'AI'. But maybe I'm wrong.
Any ideas?
--
what's the number to 911?
Best regards
Wieniuszka
------------------------------
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.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
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 6524
***************************************
