[30353] in Perl-Users-Digest
Perl-Users Digest, Issue: 1596 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri May 30 16:19:24 2008
Date: Fri, 30 May 2008 13:14:20 -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 Fri, 30 May 2008 Volume: 11 Number: 1596
Today's topics:
Re: Need help with a simple (I think) Perl script <1usa@llenroc.ude.invalid>
Re: Need help with a simple (I think) Perl script <szrRE@szromanMO.comVE>
Re: Need help with a simple (I think) Perl script <szrRE@szromanMO.comVE>
Re: Need help with a simple (I think) Perl script <joe+usenet@sunstarsys.com>
Re: Need help with a simple (I think) Perl script <joe+usenet@sunstarsys.com>
Re: Need help with a simple (I think) Perl script <1usa@llenroc.ude.invalid>
Re: Need help with a simple (I think) Perl script <joe+usenet@sunstarsys.com>
Re: Need help with a simple (I think) Perl script <hjp-usenet2@hjp.at>
Re: Need help with a simple (I think) Perl script sln@netherlands.co
Re: Need help with a simple (I think) Perl script <1usa@llenroc.ude.invalid>
Re: Need help with a simple (I think) Perl script sln@netherlands.co
Re: Need help with a simple (I think) Perl script xhoster@gmail.com
Re: Need help with a simple (I think) Perl script sln@netherlands.co
Re: Need help with a simple (I think) Perl script sln@netherlands.co
Re: Need help with a simple (I think) Perl script sln@netherlands.co
Re: Need help with a simple (I think) Perl script sln@netherlands.co
Re: Need help with a simple (I think) Perl script <szrRE@szromanMO.comVE>
Re: Perl Special Variable Containing the name of the me <simon.chao@fmr.com>
Perl Special Variable Containing the name of the method <nigelstuart@gmail.com>
Re: Perl Special Variable Containing the name of the me <1usa@llenroc.ude.invalid>
Pop3 Email - Perl <fjrusso@yahoo.com>
Re: Pop3 Email - Perl <1usa@llenroc.ude.invalid>
Re: Pop3 Email - Perl <asdf@fghj.dilivna>
Re: The Importance of Terminology's Quality <jpthing@online.no>
Re: Using perl locally on a Windows XP system <jurgenex@hotmail.com>
Win32::IE::Mechanize can't upload <wizardofyendor@gmail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 30 May 2008 15:09:42 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude.invalid>
Subject: Re: Need help with a simple (I think) Perl script
Message-Id: <Xns9AAE718AE439asu1cornelledu@127.0.0.1>
Ted Zlatanov <tzz@lifelogs.com> wrote in
news:86ej7jg7u5.fsf@lifelogs.com:
> On Thu, 29 May 2008 21:05:15 GMT "A. Sinan Unur"
> <1usa@llenroc.ude.invalid> wrote:
>
> ASU> Ted Zlatanov <tzz@lifelogs.com> wrote in
> ASU> news:86od6oga57.fsf@lifelogs.com:
>>> You and A. Sinan Unur are being nasty when a quick look at the
>>> original script would have been sufficient to understand the
>>> miscommunication.
>
> ASU> No.
> ASU> In the original script, there is a
> ASU> use strict;
> ASU> line. Had that line actually been in the script rather than
> ASU> pasted into the post as an after-thought, the typo would have
> ASU> been caught by the OP.
>
> ASU> Hence, my belief that the poster intentionally misrepresented the
> ASU> contents of the script. That is, he lied.
>
> Calling someone a liar is very insulting in most cultures. Were you
> trying to insult the OP or were you trying to state the facts?
The
use strict;
line did not get inserted into the post magically. It had to have been
put there by the OP.
The existence of that line in the post implies to me that the code
posted was strict-clean.
I wasted time trying to put together a helpful post assuming the OP had
made the right kind of effort.
Then, all the way at the end, just as I am about to explain the security
vulnerability created by using unvalidated CGI parameters to serve
files, I realize that the OP had not actually checked his program with
strict.
I am assuming there also exist some cultures where people do not like
being fed "intentional misrepresentations". Especially if said
intentional misrepresentations result in wasted time.
> IMO, it would have been much better to say "hey, I'm pretty sure you
> didn't post the source code you actually used. why?" It's a
> statement of fact, no emotional charge, no judgement of the person
> implied. If there was a misunderstanding or something omitted, let it
> come out but without rancor.
OK.
Sinan
--
A. Sinan Unur <1usa@llenroc.ude.invalid>
(remove .invalid and reverse each component for email address)
comp.lang.perl.misc guidelines on the WWW:
http://www.rehabitation.com/clpmisc/
------------------------------
Date: Fri, 30 May 2008 09:39:10 -0700
From: "szr" <szrRE@szromanMO.comVE>
Subject: Re: Need help with a simple (I think) Perl script
Message-Id: <g1pajf017ph@news4.newsguy.com>
Ben Bullock wrote:
> On Fri, 30 May 2008 01:16:39 +0200, Gunnar Hjalmarsson wrote:
>
>> If you develop a Perl program in a CGI
>> environment, you'd better make it a habit to
>>
>> use CGI::Carp 'fatalsToBrowser';
>>
>> It will make the browser display more meaningful error messages.
>
> That may not always be a good habit, since the error messages are
> meaningful only to the programmer:
>
> http://schwern.org/~schwern/cgi-bin/unix2vms/
>
> One can look for the messages produced by "die" in the error log too,
> and if the code is in use by people other than the CGI programmers
> (which it probably will be) it's probably a better bet to not use the
> above outside of testing, since it will produce something meaningless
> and confusing.
One trick I used in the past was to have a $SIG{__DIE__} handler that
check $ENV{REMOTE_ADDR} and if it was my own, print (custom) errors ($!
and such), else just dies, leaving the error in the logs.
--
szr
------------------------------
Date: Fri, 30 May 2008 10:17:34 -0700
From: "szr" <szrRE@szromanMO.comVE>
Subject: Re: Need help with a simple (I think) Perl script
Message-Id: <g1pcre01ajf@news4.newsguy.com>
Charlton Wilbur wrote:
> Bill H <bill@ts1000.us> writes:
>
>> Many an interesting topic has been killed by the need to disect
>> a post. Remember, perl is a programming language, programmers
>> are people. Try to keep them distinct and apply some people
>> skills where appropriate, and by all means, share with us your
>> programming skills which the vast majority of you have in excess
>> of mine.
>
> Fortunately, there's a documented posted here regularly, clearly
> labeled as Posting Guidelines, that indicates quite clearly what
> people get their posts dissected for.
Well, still, as regular as the guidelines are posted (about every 2-3
days or so), with the amount of threads, it's not surprising that it
gets buried. Even worse, some news readers (that use a thread/tree view)
group separate identical posts (same subject, et al) into one big
thread. Maybe Tad should add a unique value into the subject line (like
the date, for instance) to ensure each posting shows as a separate
(single post) thread.
> Remember, Perl is a programming language, programmers are people, and
> expert programmers are *donating their time here* to help the novices.
> Ask a stupid question, or one that's advised against in the Posting
> Guidelines, and get a snippy, terse response
One has to know there are guidelines to read in the first place, so
given how easily the guideline thread gets buried, it's unfair to assume
one has seen it, or even knows to read it (a catch twenty two.)
> -- because the alternative is having the experts say, "@#$% this,
> I'm tired of answering the same four FAQs over again" and going
> off to do something else.
If one feels have have to respond in that way, then why respond at all?
> There's a reason Larry Wall doesn't post here, and Randal Schwartz
> posts only rarely. Do you want to chase the other experts off too?
With all due respect, there are many other reasons they don't post here,
so please don't try to say this the one single reason. Attitudes of many
people (many of which pass themselves off as authority figures) in this
group, and possibly UseNet in general, played a big role as well.
--
szr
------------------------------
Date: Fri, 30 May 2008 13:35:47 -0400
From: Joe Schaefer <joe+usenet@sunstarsys.com>
Subject: Re: Need help with a simple (I think) Perl script
Message-Id: <874p8fy9sc.fsf@gemini.sunstarsys.com>
"A. Sinan Unur" <1usa@llenroc.ude.invalid> writes:
> Joe Schaefer <joe+usenet@sunstarsys.com> wrote in
> news:87k5hcy1qn.fsf@gemini.sunstarsys.com:
[...]
>> for (scalar param("Month")) {
>> defined or die "Missing 'Month' parameter";
>> $month = $month_names{$_} or die "Bad 'Month' parameter:$_";
>> }
>
> So, let's suppose we use $month_names{$_} to do "impedance matching"
> to accomodate a different naming scheme where Jan maps to 0.
Interesting supposition - too bad it doesn't match the
OP's requirements. The point of the remark is that
the names used in his form don't need to map directly
to the text used in his file layout.
[...]
>> open my $pdfh, "<", $pdffile or die "Can't open file $pdffile:$!";
>>
>> print "Content-Type: application/pdf\n\n";
>> print while read $pdfh, $_, 8192;
>
> Both $pdfh and STDOUT should have binmode set.
Sure. Why not.
--
Joe Schaefer
------------------------------
Date: Fri, 30 May 2008 13:55:58 -0400
From: Joe Schaefer <joe+usenet@sunstarsys.com>
Subject: Re: Need help with a simple (I think) Perl script
Message-Id: <87y75rwua9.fsf@gemini.sunstarsys.com>
"John W. Krahn" <someone@example.com> writes:
> Joe Schaefer wrote:
[...]
>> for (scalar param("Year")) {
>> defined or die "Missing 'Year' parameter";
>> /^(\d{4})$/ or die "Bad 'Year' parameter:$_";
>> $year = $1;
>> }
>
> In all my (mumble, mumble) years of Perl programming I have never seen that
> particular idiom used. I have usually seen that written as:
>
> defined( my $year = param( 'Year' ) )
> or die "Missing 'Year' parameter";
> $year =~ /\A(\d{4})\z/ or die "Bad 'Year' parameter:$year";
> $year = $1;
Frankly that (reassignment) looks incredibly clumsy to me.
IMO it's easier to analyze the state of taintedness of
a variable if it's either never tainted or always tainted.
Changing the state of taintedness of a variable complexifies
the analysis of how and where it's used, so I try to avoid
doing that, but for a tiny script like this one it really
does not matter.
Note that the -T flag really has no impact whatsoever
in this script, because opening a file for read access
is not considered an unsafe operation by perl. So all
you can do is try to instill untainting as part of normal
CGI parameter handling.
--
Joe Schaefer
------------------------------
Date: Fri, 30 May 2008 17:57:03 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude.invalid>
Subject: Re: Need help with a simple (I think) Perl script
Message-Id: <Xns9AAE8DEA3FC2Dasu1cornelledu@127.0.0.1>
Joe Schaefer <joe+usenet@sunstarsys.com> wrote in
news:874p8fy9sc.fsf@gemini.sunstarsys.com:
> "A. Sinan Unur" <1usa@llenroc.ude.invalid> writes:
>
>> Joe Schaefer <joe+usenet@sunstarsys.com> wrote in
>> news:87k5hcy1qn.fsf@gemini.sunstarsys.com:
>
> [...]
>
>>> for (scalar param("Month")) {
>>> defined or die "Missing 'Month' parameter";
>>> $month = $month_names{$_} or die "Bad 'Month' parameter:$_";
>>> }
>>
>> So, let's suppose we use $month_names{$_} to do "impedance matching"
>> to accomodate a different naming scheme where Jan maps to 0.
>
> Interesting supposition - too bad it doesn't match the
> OP's requirements.
I don't understand the purpose of your %month_names then. What is the
point of that if not to enable the file naming convention to be changed
without changing the HTML front-end?
> The point of the remark is that
> the names used in his form don't need to map directly
> to the text used in his file layout.
Well, currently, they do. So, currently, there is no need for %
month_names.
The situation might change in the future. One possible change is mapping
January to 0. Therefore, check for existence rather than truth value.
Sinan
--
A. Sinan Unur <1usa@llenroc.ude.invalid>
(remove .invalid and reverse each component for email address)
comp.lang.perl.misc guidelines on the WWW:
http://www.rehabitation.com/clpmisc/
------------------------------
Date: Fri, 30 May 2008 14:12:38 -0400
From: Joe Schaefer <joe+usenet@sunstarsys.com>
Subject: Re: Need help with a simple (I think) Perl script
Message-Id: <87r6bjwtih.fsf@gemini.sunstarsys.com>
"A. Sinan Unur" <1usa@llenroc.ude.invalid> writes:
[...]
> I don't understand the purpose of your %month_names then.
> What is the point of that if not to enable the file
> naming convention to be changed without changing
> the HTML front-end?
What I had in mind was that the HTML front-end could present
and use full month names, while the OP maintains the 3 letter
abbreviations for the actual files. I'm sure you could do
this directly in HTML, but this offers another way.
>> The point of the remark is that
>> the names used in his form don't need to map directly
>> to the text used in his file layout.
>
> Well, currently, they do. So, currently, there is no need for %
> month_names.
There is a clear need to untaint param('Month') based on
how it's going to be used. The simplest way to do that,
based on what OP is actually doing with his form, is
to use a hash.
--
Joe Schaefer
------------------------------
Date: Fri, 30 May 2008 20:27:01 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Need help with a simple (I think) Perl script
Message-Id: <slrng40hnl.8cu.hjp-usenet2@hrunkner.hjp.at>
On 2008-05-30 17:57, A. Sinan Unur <1usa@llenroc.ude.invalid> wrote:
> Joe Schaefer <joe+usenet@sunstarsys.com> wrote in
> news:874p8fy9sc.fsf@gemini.sunstarsys.com:
>> "A. Sinan Unur" <1usa@llenroc.ude.invalid> writes:
>>> Joe Schaefer <joe+usenet@sunstarsys.com> wrote in
>>> news:87k5hcy1qn.fsf@gemini.sunstarsys.com:
>>
>>>> for (scalar param("Month")) {
>>>> defined or die "Missing 'Month' parameter";
>>>> $month = $month_names{$_} or die "Bad 'Month' parameter:$_";
>>>> }
>>>
>>> So, let's suppose we use $month_names{$_} to do "impedance matching"
>>> to accomodate a different naming scheme where Jan maps to 0.
>>
>> Interesting supposition - too bad it doesn't match the
>> OP's requirements.
>
> I don't understand the purpose of your %month_names then.
The purpose is to check if the passed monthname actually exists and to
untaint it if it does.
hp
------------------------------
Date: Fri, 30 May 2008 11:35:23 -0700
From: sln@netherlands.co
Subject: Re: Need help with a simple (I think) Perl script
Message-Id: <1sh044hfnka5db9loqfb47mcrm11m1qqke@4ax.com>
On Fri, 30 May 2008 14:12:38 -0400, Joe Schaefer <joe+usenet@sunstarsys.com> wrote:
>"A. Sinan Unur" <1usa@llenroc.ude.invalid> writes:
>
>[...]
>
>> I don't understand the purpose of your %month_names then.
>> What is the point of that if not to enable the file
>> naming convention to be changed without changing
>> the HTML front-end?
>
>What I had in mind was that the HTML front-end could present
>and use full month names, while the OP maintains the 3 letter
>abbreviations for the actual files. I'm sure you could do
>this directly in HTML, but this offers another way.
>
>>> The point of the remark is that
>>> the names used in his form don't need to map directly
>>> to the text used in his file layout.
>>
>> Well, currently, they do. So, currently, there is no need for %
>> month_names.
>
>There is a clear need to untaint param('Month') based on
>how it's going to be used. The simplest way to do that,
>based on what OP is actually doing with his form, is
>to use a hash.
In reality though the OP, who has been diss'd and is long gone,
states he uses the year/month html params directly to construct
the file name.
A little validation was in order though, so new idea's were
floated and crosschecked.
The fact of the matter is that the html parameters map to the
hash key, which maps to the file name. Its a one way street
past the hash key. If the key changes, the html changes and
visa versa.
sln
------------------------------
Date: Fri, 30 May 2008 18:39:55 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude.invalid>
Subject: Re: Need help with a simple (I think) Perl script
Message-Id: <Xns9AAE952F2F151asu1cornelledu@127.0.0.1>
Joe Schaefer <joe+usenet@sunstarsys.com> wrote in
news:87r6bjwtih.fsf@gemini.sunstarsys.com:
> "A. Sinan Unur" <1usa@llenroc.ude.invalid> writes:
>
> [...]
>
>> I don't understand the purpose of your %month_names then.
>> What is the point of that if not to enable the file
>> naming convention to be changed without changing
>> the HTML front-end?
>
> What I had in mind was that the HTML front-end could present
> and use full month names, while the OP maintains the 3 letter
> abbreviations for the actual files. I'm sure you could do
> this directly in HTML, but this offers another way.
>
>>> The point of the remark is that
>>> the names used in his form don't need to map directly
>>> to the text used in his file layout.
>>
>> Well, currently, they do. So, currently, there is no need for %
>> month_names.
>
> There is a clear need to untaint param('Month') based on
> how it's going to be used. The simplest way to do that,
> based on what OP is actually doing with his form, is
> to use a hash.
I am not sure that is the simplest. The identity transformation you used
is confusing IMHO because it is hard to see why it is needed.
#!/usr/bin/perl
use strict;
use warnings;
use CGI qw( :standard );
my $MONTH_RE = qr/^(Jan|Feb|Mar|Apr|May|Jun|Jul|Aug|Sep|Oct|Nov|Dec)$/;
my $month = do {
my $v = param( 'Month' );
die 'No month provided' unless defined $v;
die 'Invalid month' unless $v =~ $MONTH_RE;
$1;
};
print "Month is $month\n";
__END__
--
A. Sinan Unur <1usa@llenroc.ude.invalid>
(remove .invalid and reverse each component for email address)
comp.lang.perl.misc guidelines on the WWW:
http://www.rehabitation.com/clpmisc/
------------------------------
Date: Fri, 30 May 2008 11:43:55 -0700
From: sln@netherlands.co
Subject: Re: Need help with a simple (I think) Perl script
Message-Id: <bbi044l0a6636qigk72ll3ohe5veb6nlp0@4ax.com>
On Fri, 30 May 2008 13:08:48 GMT, "John W. Krahn" <someone@example.com> wrote:
>Joe Schaefer wrote:
>>
>> Here's some untested code to do that for you. It's
>> written idiomatically, which may be difficult to
> *********************
> *********************
>> understand without some experience with Perl.
>> Fortunately Perl has a very good documentation
>> system which will explain everything here.
>>
>> #!/usr/bin/perl -T
>> use strict;
>> use warnings;
>> use CGI qw/:standard :debug/; # drop the ":debug when going live"
>>
>> my $year;
>> my $month;
>>
>> for (scalar param("Year")) {
>> defined or die "Missing 'Year' parameter";
>> /^(\d{4})$/ or die "Bad 'Year' parameter:$_";
>> $year = $1;
>> }
>
>In all my (mumble, mumble) years of Perl programming I have never seen
>that particular idiom used. I have usually seen that written as:
>
>defined( my $year = param( 'Year' ) )
> or die "Missing 'Year' parameter";
[...]
What happens down here, in the following code?
"$year" is now a properly declaired variable.
Why? Because you declaired it as a new variable in global
scope, via a function parameter.
Is that really a good thing? Sure its close to the left, but
what if it was way out here:
functioncall (...................................., my $ucantfindme);
sln
------------------------------
Date: 30 May 2008 18:44:40 GMT
From: xhoster@gmail.com
Subject: Re: Need help with a simple (I think) Perl script
Message-Id: <20080530144442.744$Lv@newsreader.com>
"szr" <szrRE@szromanMO.comVE> wrote:
> Ben Bullock wrote:
> > On Fri, 30 May 2008 01:16:39 +0200, Gunnar Hjalmarsson wrote:
> >
> >> If you develop a Perl program in a CGI
> >> environment, you'd better make it a habit to
> >>
> >> use CGI::Carp 'fatalsToBrowser';
> >>
> >> It will make the browser display more meaningful error messages.
> >
> > That may not always be a good habit, since the error messages are
> > meaningful only to the programmer:
> >
> > http://schwern.org/~schwern/cgi-bin/unix2vms/
> >
> > One can look for the messages produced by "die" in the error log too,
> > and if the code is in use by people other than the CGI programmers
> > (which it probably will be) it's probably a better bet to not use the
> > above outside of testing, since it will produce something meaningless
> > and confusing.
I wouldn't find it meaningless and confusing. It is quite clear that an
error has occurred, that is neither meaningless nor confusing. It gives
extra information, but I think I (being hypothetically not a CGI
programmer) would know enough to expect that this is meaningful to someone
else, if not to me, and that if I wish to discuss the error with that
someone else, it might be helpful to quote parts of it to them, so in that
way it is meaningful as well as not confusing.
> One trick I used in the past was to have a $SIG{__DIE__} handler that
> check $ENV{REMOTE_ADDR} and if it was my own, print (custom) errors ($!
> and such), else just dies, leaving the error in the logs.
Unless by "just die" you mean use either the default CGI::Carp thing or
your own analog to it, by just dying you'd get an empty page, or a
partially rendered page, or a 500 error. I'd say that *that* is meaningless
and confusing!
Xho
--
-------------------- http://NewsReader.Com/ --------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.
------------------------------
Date: Fri, 30 May 2008 11:59:16 -0700
From: sln@netherlands.co
Subject: Re: Need help with a simple (I think) Perl script
Message-Id: <idj044lcqmb9qk5btjodojhu7rkgctkcid@4ax.com>
On Fri, 30 May 2008 18:39:55 GMT, "A. Sinan Unur" <1usa@llenroc.ude.invalid> wrote:
>Joe Schaefer <joe+usenet@sunstarsys.com> wrote in
>news:87r6bjwtih.fsf@gemini.sunstarsys.com:
>
>> "A. Sinan Unur" <1usa@llenroc.ude.invalid> writes:
>>
>> [...]
>>
>>> I don't understand the purpose of your %month_names then.
>>> What is the point of that if not to enable the file
>>> naming convention to be changed without changing
>>> the HTML front-end?
>>
>> What I had in mind was that the HTML front-end could present
>> and use full month names, while the OP maintains the 3 letter
>> abbreviations for the actual files. I'm sure you could do
>> this directly in HTML, but this offers another way.
>>
>>>> The point of the remark is that
>>>> the names used in his form don't need to map directly
>>>> to the text used in his file layout.
>>>
>>> Well, currently, they do. So, currently, there is no need for %
>>> month_names.
>>
>> There is a clear need to untaint param('Month') based on
>> how it's going to be used. The simplest way to do that,
>> based on what OP is actually doing with his form, is
>> to use a hash.
>
>I am not sure that is the simplest. The identity transformation you used
>is confusing IMHO because it is hard to see why it is needed.
>
>#!/usr/bin/perl
>
>use strict;
>use warnings;
>
>use CGI qw( :standard );
>
>my $MONTH_RE = qr/^(Jan|Feb|Mar|Apr|May|Jun|Jul|Aug|Sep|Oct|Nov|Dec)$/;
>
qr// is kind of anal for the OP's usage isin't it?
>my $month = do {
> my $v = param( 'Month' );
> die 'No month provided' unless defined $v;
> die 'Invalid month' unless $v =~ $MONTH_RE;
> $1;
>};
>
>print "Month is $month\n";
>
>__END__
No hash, so where's the filename? Maybe the filename is case sensitive.
So what now?
sln
------------------------------
Date: Fri, 30 May 2008 12:10:10 -0700
From: sln@netherlands.co
Subject: Re: Need help with a simple (I think) Perl script
Message-Id: <m4k044laj25i9hjt5hjnvfmeuuvkc2h4t3@4ax.com>
On Fri, 30 May 2008 13:08:48 GMT, "John W. Krahn" <someone@example.com> wrote:
>Joe Schaefer wrote:
>>
>> Here's some untested code to do that for you. It's
>> written idiomatically, which may be difficult to
> *********************
> *********************
>> understand without some experience with Perl.
>> Fortunately Perl has a very good documentation
>> system which will explain everything here.
>>
>> #!/usr/bin/perl -T
>> use strict;
>> use warnings;
>> use CGI qw/:standard :debug/; # drop the ":debug when going live"
>>
>> my $year;
>> my $month;
>>
>> for (scalar param("Year")) {
>> defined or die "Missing 'Year' parameter";
>> /^(\d{4})$/ or die "Bad 'Year' parameter:$_";
>> $year = $1;
>> }
>
>In all my (mumble, mumble) years of Perl programming I have never seen
>that particular idiom used. I have usually seen that written as:
>
>defined( my $year = param( 'Year' ) )
> or die "Missing 'Year' parameter";
>$year =~ /\A(\d{4})\z/ or die "Bad 'Year' parameter:$year";
[...]
I don't know the affectiveness of \A, \z without modifiers.
sln
------------------------------
Date: Fri, 30 May 2008 12:26:26 -0700
From: sln@netherlands.co
Subject: Re: Need help with a simple (I think) Perl script
Message-Id: <ovk04418kutquplug40ipj2v754j5beduk@4ax.com>
On Fri, 30 May 2008 11:59:16 -0700, sln@netherlands.co wrote:
>On Fri, 30 May 2008 18:39:55 GMT, "A. Sinan Unur" <1usa@llenroc.ude.invalid> wrote:
>
>>Joe Schaefer <joe+usenet@sunstarsys.com> wrote in
>>news:87r6bjwtih.fsf@gemini.sunstarsys.com:
>>
>>> "A. Sinan Unur" <1usa@llenroc.ude.invalid> writes:
>>>
>>> [...]
>>>
>>>> I don't understand the purpose of your %month_names then.
>>>> What is the point of that if not to enable the file
>>>> naming convention to be changed without changing
>>>> the HTML front-end?
>>>
>>> What I had in mind was that the HTML front-end could present
>>> and use full month names, while the OP maintains the 3 letter
>>> abbreviations for the actual files. I'm sure you could do
>>> this directly in HTML, but this offers another way.
>>>
>>>>> The point of the remark is that
>>>>> the names used in his form don't need to map directly
>>>>> to the text used in his file layout.
>>>>
>>>> Well, currently, they do. So, currently, there is no need for %
>>>> month_names.
>>>
>>> There is a clear need to untaint param('Month') based on
>>> how it's going to be used. The simplest way to do that,
>>> based on what OP is actually doing with his form, is
>>> to use a hash.
>>
>>I am not sure that is the simplest. The identity transformation you used
>>is confusing IMHO because it is hard to see why it is needed.
>>
>>#!/usr/bin/perl
>>
>>use strict;
>>use warnings;
>>
>>use CGI qw( :standard );
>>
>>my $MONTH_RE = qr/^(Jan|Feb|Mar|Apr|May|Jun|Jul|Aug|Sep|Oct|Nov|Dec)$/;
>>
>
>qr// is kind of anal for the OP's usage isin't it?
>
[..]
Caveat: Of course the OP is getting 10 million hits per second on his
file server site, and his module is servicing with a single instance.
Ok then.
sln
------------------------------
Date: Fri, 30 May 2008 12:33:56 -0700
From: sln@netherlands.co
Subject: Re: Need help with a simple (I think) Perl script
Message-Id: <4dl044hnaqp3gune705s45ahl8mksfh6iv@4ax.com>
On 30 May 2008 18:44:40 GMT, xhoster@gmail.com wrote:
>"szr" <szrRE@szromanMO.comVE> wrote:
>> Ben Bullock wrote:
>> > On Fri, 30 May 2008 01:16:39 +0200, Gunnar Hjalmarsson wrote:
>> >
>> >> If you develop a Perl program in a CGI
>> >> environment, you'd better make it a habit to
>> >>
>> >> use CGI::Carp 'fatalsToBrowser';
>> >>
>> >> It will make the browser display more meaningful error messages.
>> >
>> > That may not always be a good habit, since the error messages are
>> > meaningful only to the programmer:
>> >
>> > http://schwern.org/~schwern/cgi-bin/unix2vms/
>> >
>> > One can look for the messages produced by "die" in the error log too,
>> > and if the code is in use by people other than the CGI programmers
>> > (which it probably will be) it's probably a better bet to not use the
>> > above outside of testing, since it will produce something meaningless
>> > and confusing.
>
>I wouldn't find it meaningless and confusing. It is quite clear that an
>error has occurred, that is neither meaningless nor confusing. It gives
>extra information, but I think I (being hypothetically not a CGI
>programmer) would know enough to expect that this is meaningful to someone
>else, if not to me, and that if I wish to discuss the error with that
>someone else, it might be helpful to quote parts of it to them, so in that
>way it is meaningful as well as not confusing.
>
But, YOU won't be there. The whole idea is programmed error recovery.
To just die, unless you can't recover is not an option in the corporate world.
Built in recovery algo's are manditory in the money world.
sln
------------------------------
Date: Fri, 30 May 2008 12:33:57 -0700
From: "szr" <szrRE@szromanMO.comVE>
Subject: Re: Need help with a simple (I think) Perl script
Message-Id: <g1pkr501gl7@news4.newsguy.com>
xhoster@gmail.com wrote:
> "szr" <szrRE@szromanMO.comVE> wrote:
>> Ben Bullock wrote:
>>> On Fri, 30 May 2008 01:16:39 +0200, Gunnar Hjalmarsson wrote:
>>>
>>>> If you develop a Perl program in a CGI
>>>> environment, you'd better make it a habit to
>>>>
>>>> use CGI::Carp 'fatalsToBrowser';
>>>>
>>>> It will make the browser display more meaningful error messages.
>>>
>>> That may not always be a good habit, since the error messages are
>>> meaningful only to the programmer:
>>>
>>> http://schwern.org/~schwern/cgi-bin/unix2vms/
>>>
>>> One can look for the messages produced by "die" in the error log
>>> too, and if the code is in use by people other than the CGI
>>> programmers (which it probably will be) it's probably a better bet
>>> to not use the above outside of testing, since it will produce
>>> something meaningless and confusing.
>
> I wouldn't find it meaningless and confusing. It is quite clear that
> an error has occurred, that is neither meaningless nor confusing. It
> gives extra information, but I think I (being hypothetically not a CGI
> programmer) would know enough to expect that this is meaningful to
> someone else, if not to me, and that if I wish to discuss the error
> with that someone else, it might be helpful to quote parts of it to
> them, so in that way it is meaningful as well as not confusing.
True (though I did not write what you were responding to.)
>> One trick I used in the past was to have a $SIG{__DIE__} handler that
>> check $ENV{REMOTE_ADDR} and if it was my own, print (custom) errors
>> ($! and such), else just dies, leaving the error in the logs.
>
> Unless by "just die" you mean use either the default CGI::Carp thing
> or your own analog to it, by just dying you'd get an empty page, or a
> partially rendered page, or a 500 error. I'd say that *that* is
> meaningless and confusing!
I was talking about a generic case. I should of said a default error
page stating something weren't wrong, and a link allowing one to report
it. My point was this is one way one could have some simple debugging
when working on a live server (though I still recommend using a separate
dev environment.)
--
szr
------------------------------
Date: Fri, 30 May 2008 11:10:53 -0700 (PDT)
From: nolo contendere <simon.chao@fmr.com>
Subject: Re: Perl Special Variable Containing the name of the method currently in?
Message-Id: <5047148e-84f9-4592-990f-4b1355f142d0@w7g2000hsa.googlegroups.com>
On May 30, 2:06=A0pm, Nigel <nigelstu...@gmail.com> wrote:
> Hello,
>
> Just out of curiosity.
> Is there a way to get the name of the subroutine Perl is currently in
> when it is running?
> For example, if I have a subroutine declared with the name sub
> helloWorld, is there any way from within that subroutine to
> programmatically get 'helloWorld' without having to hardcode it?
yup. caller().
http://perldoc.perl.org/functions/caller.html
HTH,
------------------------------
Date: Fri, 30 May 2008 11:06:29 -0700 (PDT)
From: Nigel <nigelstuart@gmail.com>
Subject: Perl Special Variable Containing the name of the method currently in?
Message-Id: <de8822a9-7087-4006-a8ef-fd8c4b7e758a@z66g2000hsc.googlegroups.com>
Hello,
Just out of curiosity.
Is there a way to get the name of the subroutine Perl is currently in
when it is running?
For example, if I have a subroutine declared with the name sub
helloWorld, is there any way from within that subroutine to
programmatically get 'helloWorld' without having to hardcode it?
Thanks!
- Nigel
------------------------------
Date: Fri, 30 May 2008 18:19:35 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude.invalid>
Subject: Re: Perl Special Variable Containing the name of the method currently in?
Message-Id: <Xns9AAE91BC2E8FCasu1cornelledu@127.0.0.1>
Nigel <nigelstuart@gmail.com> wrote in news:de8822a9-7087-4006-a8ef-
fd8c4b7e758a@z66g2000hsc.googlegroups.com:
> Just out of curiosity.
> Is there a way to get the name of the subroutine Perl is currently in
> when it is running?
> For example, if I have a subroutine declared with the name sub
> helloWorld, is there any way from within that subroutine to
> programmatically get 'helloWorld' without having to hardcode it?
#!/usr/bin/perl
use strict;
use warnings;
sub whatismyname { (caller 1)[3] }
sub iknowmyname {
my $name = whatismyname();
print "My name is '$name'\n";
}
iknowmyname();
__END__
Make sure to read perldoc -f caller
Sinan
--
A. Sinan Unur <1usa@llenroc.ude.invalid>
(remove .invalid and reverse each component for email address)
comp.lang.perl.misc guidelines on the WWW:
http://www.rehabitation.com/clpmisc/
------------------------------
Date: Fri, 30 May 2008 08:16:32 -0700 (PDT)
From: Frank <fjrusso@yahoo.com>
Subject: Pop3 Email - Perl
Message-Id: <adea1fd1-75dd-4e30-aa88-5c4bacf9b3bf@k37g2000hsf.googlegroups.com>
Have I got the right group for asking question re: perl programing?
Just in case I do, I am looking for some code to read from my pop3
email box.
Anyone able to help me?
Frank
------------------------------
Date: Fri, 30 May 2008 15:23:33 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude.invalid>
Subject: Re: Pop3 Email - Perl
Message-Id: <Xns9AAE73E463BF7asu1cornelledu@127.0.0.1>
Frank <fjrusso@yahoo.com> wrote in news:adea1fd1-75dd-4e30-aa88-
5c4bacf9b3bf@k37g2000hsf.googlegroups.com:
> Have I got the right group for asking question re: perl programing?
ITYM Perl, not perl.
> Just in case I do, I am looking for some code to read from my pop3
> email box.
>
> Anyone able to help me?
Yes, there is a CPAN module for that purpose:
http://search.cpan.org/~gbarr/libnet-1.22/Net/POP3.pm
I no longer use the following script but it is a short and useful
example:
http://www.unur.com/comp/ppp/delallspam.html
If you want help with a specific problem, you should read the posting
guidelines for this group and follow them. And, no, we do not write
scripts to order.
Sinan
--
A. Sinan Unur <1usa@llenroc.ude.invalid>
(remove .invalid and reverse each component for email address)
comp.lang.perl.misc guidelines on the WWW:
http://www.rehabitation.com/clpmisc/
------------------------------
Date: Fri, 30 May 2008 10:59:57 -0700
From: "Gordon Etly" <asdf@fghj.dilivna>
Subject: Re: Pop3 Email - Perl
Message-Id: <6aatkuF36ik5sU1@mid.individual.net>
A. Sinan Unur wrote:
> Frank <fjrusso@yahoo.com> wrote:
> > Have I got the right group for asking question re: perl programing?
> ITYM Perl, not perl.
I think you know exactly what he meant, even if he didn't write it
perfectly...
> > Just in case I do, I am looking for some code to read from my pop3
> > email box.
> >
> > Anyone able to help me?
> Yes, there is a CPAN module for that purpose:
>
> http://search.cpan.org/~gbarr/libnet-1.22/Net/POP3.pm
And for POP3S:
http://search.cpan.org/author/TOKUHIROM/Net-POP3-SSLWrapper-0.01/lib/Net/POP3/SSLWrapper.pm
Or to interact with the user's mbox directly:
http://search.cpan.org/author/MARKOV/Mail-Box-2.082/lib/Mail/Box/POP3.pod
This might also be of use:
http://search.cpan.org/author/MARKOV/Mail-Box-2.082/lib/Mail/Transport/POP3.pod
Take a look around search around search.cpan.org
http://search.cpan.org/search?mode=module&query=pop3
--
G.Etly
------------------------------
Date: Fri, 30 May 2008 22:03:37 +0200
From: "John Thingstad" <jpthing@online.no>
Subject: Re: The Importance of Terminology's Quality
Message-Id: <op.ubzgobgsut4oq5@pandora.alfanett.no>
På Fri, 30 May 2008 02:56:37 +0200, skrev David Combs <dkcombs@panix.com>:
> In article <rem-2008may08-005@yahoo.com>,
> Robert Maas, http://tinyurl.com/uh3t
> <usenet1.3.CalRobert@SpamGourmet.Com> wrote:
>>> From: "xah...@gmail.com" <xah...@gmail.com>
>>> the importance of naming of functions.
>>
>
> Lisp is *so* early a language (1960?), preceeded mainly only by Fortran
> (1957?)?,
> and for sure the far-and-away the first as a platform for *so many*
> concepts
> of computer-science, eg lexical vs dynamic ("special") variables, passing
> *unnamed* functions as args (could Algol 60 also do something like that,
> via something it maybe termed a "thunk"), maybe is still the only one
> in which program and data have the same representation -- that it'd
> seem logical to use it's terminology in all languages.
>
> From C is the very nice distinction between "formal" and "actual" args.
>
> And from algol-60, own and local -- own sure beats "static"!
>
> And so on.
>
>
> To me, it's too bad that that hacker-supreme (and certified genius)
> Larry W. likes to make up his own terminology for Perl. Sure makes
> for a lot of otherwise-unnecessary pages in the various Perl texts,
> as well as posts here.
>
> Of course, a whole lot better his terminology than no language at all!
>
>
> David
>
>
Perl is solidly based in the UNIX world on awk, sed, bash and C.
I don't like the style, but many do.
--------------
John Thingstad
------------------------------
Date: Fri, 30 May 2008 16:28:08 GMT
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Using perl locally on a Windows XP system
Message-Id: <vea0449f4ii6el1jnpb8f6nudopmb77gh5@4ax.com>
"Peter J. Holzer" <hjp-usenet2@hjp.at> wrote:
>On 2008-05-29 22:42, Jürgen Exner <jurgenex@hotmail.com> wrote:
>> "Peter J. Holzer" <hjp-usenet2@hjp.at> wrote:
>>>On 2008-05-28 13:50, Jürgen Exner <jurgenex@hotmail.com> wrote:
>>>> Oh, you are not talking about Perl at all, you are talking about an HTTP
>>>> server. The "best" way to do that is to install a proxy server, which
>>>> redirects all requests to your test environment, in this case to
>>>> localhost.
>>>
>>>What do you need the proxy for?
>>
>> A proxy server is the easiest method to redirect traffic between the
>> live and test site.
>
>I find typing "http://test.example.com" instead of
>"http://www.example.com" into the URL bar much easier.
For simple web pages and only a few test runs certainly true.
Not so any more when talking about large sites with cross-linked pages
containing absolute URLs, and teams with dozens of testers and
developers.
jue
------------------------------
Date: Fri, 30 May 2008 11:49:59 -0700 (PDT)
From: Rodney <wizardofyendor@gmail.com>
Subject: Win32::IE::Mechanize can't upload
Message-Id: <4a053ac6-edb4-496b-b87e-743557d3b7d7@27g2000hsf.googlegroups.com>
I have a form on a webpage I am trying to automate. there is a 'file'
field that I can't get to accept data. I've mapped the path down to
the Win32::IE::Input module, and tried to set the value from that, but
still nothing.
Has anyone been able to get this to work?
------------------------------
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 V11 Issue 1596
***************************************
