Need help with a simple (I think) Perl script
Dick Sutton
hundred or more files in a directory on a web server (let's call it
'Library'). Each file is a pdf file and is named 'yyyymmm.pdf' where yyyy
is the year (i.e. 2007) and mmm is the first 3 letters of the month (i.e.
Jan). So a typical file name looks like '2007Jan.pdf'.
I wrote a simple html page using FORM that allows the user to select the
year and the month and then press the SUBMIT button and I want the
respective pdf file returned into the users browser. The problem is, I
don't know how to return a pdf file to the browser.
Here's what I have so far:
#!/usr/local/bin/perl -wT
use strict;
use CGI ':standard';
# declare variables...
my $year;
my $month;
my $pdffile;
# get the parameters...
$year = param('Year');
$month = param('Month');
# construct the relative pathname to the actual PDF file
$pdffile = '../Library/'.$Year.$Month.'.pdf';
print 'Content-type: application/pdf\n\n';
This is where I'm stuck. Can someone push me in the right direction. I
would think it should be trivial. I just don't know how to procede.
Thanks in advance...
Dick
Frank Seitz
>
> Here's what I have so far:
>
> #!/usr/local/bin/perl -wT
> use strict;
> use CGI ':standard';
>
> # declare variables...
> my $year;
> my $month;
> my $pdffile;
>
> # get the parameters...
> $year = param('Year');
> $month = param('Month');
>
> # construct the relative pathname to the actual PDF file
> $pdffile = '../Library/'.$Year.$Month.'.pdf';
>
> print 'Content-type: application/pdf\n\n';
>
> This is where I'm stuck. Can someone push me in the right direction. I
> would think it should be trivial. I just don't know how to procede.
$\ = undef;
open my $fh,'<',$pdffile or die $!;
print <$fh>;
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel
Uri Guttman
FS> $\ = undef;
that should be $/. this is another reason File::Slurp is useful. no need
to know this.
FS> open my $fh,'<',$pdffile or die $!;
FS> print <$fh>;
use File::Slurp ;
print read_file( $pdffile ) ;
uri
--
Uri Guttman ------ u...@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Free Perl Training --- http://perlhunter.com/college.html ---------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
Frank Seitz
>>>>>>"FS" == Frank Seitz <devnu...@web.de> writes:
>
> FS> $\ = undef;
>
> that should be $/.
You are right. The code works anyway (because
print provides a list context).
> this is another reason File::Slurp is useful. no need
> to know this.
>
> FS> open my $fh,'<',$pdffile or die $!;
> FS> print <$fh>;
>
> use File::Slurp ;
> print read_file( $pdffile ) ;
There is one disadvantage: File::Slurp is not in the core.
Bill H
Unless you do not want the visitor knowing where the pdffile is on
your server, I would use the following instead of the print 'Content-
type: application/pdf\n\n';
print "Location: yourwebdomain/Library/$pdffile\n\n";
This way you are not streaming the pdffile through perl and are
instead letting the server just serve it up. Also you should check
that the $year and $month are valid entries on the off chance that
someone tries to feed the script bogus or empty values.
Bill H
Dick Sutton
"Dick Sutton" <rsut...@comcast.net> wrote in message
news:m4OdnZttx5K6gaPV...@comcast.com...
Awsome feedback! Thanks to everyone who responded. I'm going to try each
suggestion and then I'll try to figure out what
each line does. ha-ha. I told you I was a novice Perl scripter. Many
thanks, again...
Dick
Dick Sutton
>that the $year and $month are valid entries on the off chance that
>someone tries to feed the script bogus or empty values.
>
>Bill H
Thanks for the reply, Bill H.
I have taken care of the validation aspect by using the drop-down list
approach in html (i.e. <select> & <option> stuff). I am going to look into
your suggestion that I 'hide' the servor directory as much as possible.
Good advice.
Thanks again...
Dick
A. Sinan Unur
>>Also you should check
>>that the $year and $month are valid entries on the off chance that
>>someone tries to feed the script bogus or empty values.
>>
>>Bill H
>
> Thanks for the reply, Bill H.
>
> I have taken care of the validation aspect by using the drop-down list
> approach in html (i.e. <select> & <option> stuff).
In that case, you have a lot to learn about security. That does not
restict in any way shape or form the values that can be submitted.
What you need to do is simple: Figure out the validity requirements for
every parameter that will be passed to the server side script and check
for those requirements on the server side.
> I am going to look
> into your suggestion that I 'hide' the servor directory as much as
> possible. Good advice.
Whatever that means.
perldoc perlsec
http://www.w3.org/Security/Faq/wwwsf4.html
You should not type another character of code until you know what you
are dealing with.
Sinan
--
A. Sinan Unur <1u...@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/
Uri Guttman
FS> Uri Guttman wrote:
>>>>>>> "FS" == Frank Seitz <devnu...@web.de> writes:
FS> open my $fh,'<',$pdffile or die $!;
FS> print <$fh>;
>>
>> use File::Slurp ;
>> print read_file( $pdffile ) ;
FS> There is one disadvantage: File::Slurp is not in the core.
but many use it anyway. the not in core module excuse is weak as is the
"i can't install/use cpan" excuse.
A. Sinan Unur
> First of all, I am a rank amateur at Perl. Here is my problem: I have
> a hundred or more files in a directory on a web server (let's call it
> 'Library'). Each file is a pdf file and is named 'yyyymmm.pdf' where
> yyyy is the year (i.e. 2007) and mmm is the first 3 letters of the
> month (i.e. Jan). So a typical file name looks like '2007Jan.pdf'.
>
> I wrote a simple html page using FORM that allows the user to select
> the year and the month and then press the SUBMIT button and I want the
> respective pdf file returned into the users browser. The problem is,
> I don't know how to return a pdf file to the browser.
>
> Here's what I have so far:
>
> #!/usr/local/bin/perl -wT
> use strict;
> use CGI ':standard';
>
> # declare variables...
There is no need to declare variables in a separate visual area. Declare
them in the smallest possible scope and as close to first use as
possible.
> my $year;
> my $month;
> my $pdffile;
>
> # get the parameters...
> $year = param('Year');
#!/usr/bin/perl
use strict;
use warnings;
use CGI qw( :standard );
use constant FIRST_YEAR => 1978;
use constant THIS_YEAR => 1900 + (localtime)[5];
my $year;
if ( param('Year') =~ /^(\d{4})$/
and $1 >= FIRST_YEAR
and $1 <= THIS_YEAR
) {
$year = $1;
}
die 'Invalid year' unless defined $year;
# validate some more ...
> $month = param('Month');
my $month;
if ( param('Month') =~ /^(\d{2})$/
and $1 >= 1
and $1 <= 12
) {
$month = $1;
}
die 'Invalid month' unless defined $month;
> # construct the relative pathname to the actual PDF file
> $pdffile = '../Library/'.$Year.$Month.'.pdf';
You should use File::Spec->catfile.
In your original script, you did not validate $Year and $Month. ... Wait
a second!!! There is no $Year or $Month variable in your original
script. It turns out not only are you incompetent but you are also a
liar. You did not have use strict originally, right? You just added that
as a cosmetic touch.
> print 'Content-type: application/pdf\n\n';
First of all, you are using single-quotes above, so the \n sequence does
not really do what you think it does.
Second, you are already using CGI.pm. Why not use it already?
print header('application/pdf');
> This is where I'm stuck. Can someone push me in the right direction.
First requirement is a change of attitude. Take programming seriously.
Don't lie. Make sure you read the posting guidelines and you have a
minimal but complete script before you post.
> I would think it should be trivial.
Well, it ain't trivial if you can't do it, right? Or, are you saying you
are just too dim?
> I just don't know how to procede.
Therefore, it ain't trivial.
> Thanks in advance...
Just confirming my bias against people who thank in advance.
> Dick
Ben Morrow
Quoth "A. Sinan Unur" <1u...@llenroc.ude.invalid>:
>
> #!/usr/bin/perl
You forgot -T.
> my $year;
>
> if ( param('Year') =~ /^(\d{4})$/
> and $1 >= FIRST_YEAR
> and $1 <= THIS_YEAR
> ) {
> $year = $1;
> }
>
> die 'Invalid year' unless defined $year;
my ($year) = param('Year') =~ /^(\d{4})$/
and $1 >= FIRST_YEAR
and $1 <= THIS_YEAR
or die 'Invalid year';
etc.
> > # construct the relative pathname to the actual PDF file
> > $pdffile = '../Library/'.$Year.$Month.'.pdf';
>
> You should use File::Spec->catfile.
And ->updir, if you're going to do that. IMHO when the paths are that
system-specific there's no harm in creating them directly, especially
given how hard it is to *actually* produce portable paths with
File::Spec (most people completely fail to handle volumes correctly).
Ben
--
We do not stop playing because we grow old;
we grow old because we stop playing.
b...@morrow.me.uk
szr
>>>>>> "FS" == Frank Seitz <devnu...@web.de> writes:
>
>> Uri Guttman wrote:
> >>>>>>> "FS" == Frank Seitz <devnu...@web.de> writes:
>
>> open my $fh,'<',$pdffile or die $!;
> >>
> >> use File::Slurp ;
> >> print read_file( $pdffile ) ;
>
>
> but many use it anyway. the not in core module excuse is weak as is
> the "i can't install/use cpan" excuse.
It's not necessarily weak, but just a disadvantage. I think one should
know how things like $/ and $\ work first (a basic working knowledge set
of base things in Perl that is) and then find a module to make life
easier, but you should still know how to do it without a module, and
that's what Frank was doing.
--
szr
Dick Sutton
> In your original script, you did not validate $Year and $Month. ... Wait
> a second!!! There is no $Year or $Month variable in your original
> script. It turns out not only are you incompetent but you are also a
> liar. You did not have use strict originally, right? You just added that
> as a cosmetic touch.
Mr. A. Sinan Unur,
First of all, I did declare $Year and $Month in my original post.
# get the parameters...
$year = param('Year');
$month = param('Month');
Second of all, I do not appreciate being called a liar. It is you who
cannot read! Lastly, it is YOU who has the 'attitude'. And you say I'm
'incompetent'. I never said the script worked; I said I needed help. You
gave abuse.
I do not need help from such as you.
Dick
Lawrence Statton
>
> First of all, I did declare $Year and $Month in my original post.
>
> # get the parameters...
> $year = param('Year');
Here you define $year. Not $Year.
> $month = param('Month');
Ditto.
> I do not need help from such as you.
Welcome to the world of killfiles.
--
Lawrence Statton - lawre...@abaluon.abaom s/aba/c/g
Computer software consists of only two components: ones and
zeros, in roughly equal proportions. All that is required is to
place them into the correct order.
nolo contendere
> > In your original script, you did not validate $Year and $Month. ... Wait
> > a second!!! There is no $Year or $Month variable in your original
> > script. It turns out not only are you incompetent but you are also a
> > liar. You did not have use strict originally, right? You just added that
> > as a cosmetic touch.
>
> Mr. A. Sinan Unur,
>
> First of all, I did declare $Year and $Month in my original post.
>
> # get the parameters...
> $year = param('Year');
> $month = param('Month');
Sinan was pointing out (not the most diplomatically) that you never
declared $Year and $Month, which you did not. You did declare $year
and $month.
They are two completely different variables which happen to look
similar.
Ted Zlatanov
LS> "Dick Sutton" <rsut...@comcast.net> writes:
>>
>> First of all, I did declare $Year and $Month in my original post.
>>
LS> No, you did not.
>> # get the parameters...
>> $year = param('Year');
LS> Here you define $year. Not $Year.
>> $month = param('Month');
LS> Ditto.
>> I do not need help from such as you.
LS> Welcome to the world of killfiles.
Did it perhaps occur to you that not everyone knows Perl variable names
are case-sensitive, and that not every programming language is like
Perl?
You and A. Sinan Unur are being nasty when a quick look at the original
script would have been sufficient to understand the miscommunication.
This obstinate need to insult someone because they don't know your
particular shibboleth reflects badly on the Perl community.
Ted
A. Sinan Unur
news:86od6og...@lifelogs.com:
> On 29 May 2008 12:08:32 -0500 Lawrence Statton
> <yankee...@gmail.com> wrote:
>
> LS> "Dick Sutton" <rsut...@comcast.net> writes:
>>>
>>> First of all, I did declare $Year and $Month in my original post.
>>>
> LS> No, you did not.
>
>>> # get the parameters...
>>> $year = param('Year');
>
> LS> Here you define $year. Not $Year.
>
>>> $month = param('Month');
>
> LS> Ditto.
>
>>> I do not need help from such as you.
>
> LS> Welcome to the world of killfiles.
>
> Did it perhaps occur to you that not everyone knows Perl variable
> names are case-sensitive, and that not every programming language is
> like Perl?
>
> You and A. Sinan Unur are being nasty when a quick look at the
> original script would have been sufficient to understand the
> miscommunication.
No.
In the original script, there is a
use strict;
line. Had that line actually been in the script rather than pasted into
the post as an after-thought, the typo would have been caught by the OP.
Hence, my belief that the poster intentionally misrepresented the
contents of the script. That is, he lied.
A. Sinan Unur
@osiris.mauzo.dyndns.org:
> Quoth "A. Sinan Unur" <1u...@llenroc.ude.invalid>:
...
>
>> > # construct the relative pathname to the actual PDF file
>> > $pdffile = '../Library/'.$Year.$Month.'.pdf';
>>
>> You should use File::Spec->catfile.
>
> And ->updir, if you're going to do that. IMHO when the paths are that
> system-specific there's no harm in creating them directly, especially
> given how hard it is to *actually* produce portable paths with
> File::Spec (most people completely fail to handle volumes correctly).
My 'solution' to that is to make the root path a configuration variable.
I have avoided dealing with volumes for a long time with that strategy.
my $APPROOT = 'C:/www/apps/catalog';
# ...
my $pdffile = File::Spec->catfile(
$APPROOT, 'Library', "$Year$Month.pdf" );
Gordon Etly
> On 29 May 2008 12:08:32 -0500 Lawrence Stattonwrote:
> > "Dick Sutton" <rsut...@comcast.net> writes:
> > > First of all, I did declare $Year and $Month in my original post.
> > No, you did not.
> > > # get the parameters...
> > > $year = param('Year');
> > Here you define $year. Not $Year.
> > > $month = param('Month');
> > Ditto.
> > > I do not need help from such as you.
> > Welcome to the world of killfiles.
> Did it perhaps occur to you that not everyone knows Perl variable
> names are case-sensitive, and that not every programming language
> is like Perl?
> You and A. Sinan Unur are being nasty when a quick look at the
> original script would have been sufficient to understand the
> miscommunication.
> This obstinate need to insult someone because they don't know your
> particular shibboleth reflects badly on the Perl community.
This is a common problem in this news group, as people like them keep
proving time and time again. Simply put, such negativity is just not
needed. If you feel you need to be nasty then it's plain better to just
move on to the next post of thread.
--
G.Etly
Ben Bullock
> Hence, my belief that the poster intentionally misrepresented the
> contents of the script. That is, he lied.
Why you (and John Bokma, and others) endlessly insult and harass newcomers to
this newsgroup I don't know, but I don't enjoy reading it, and I wish you'd
stop it.
Gordon Etly
...
> > Did it perhaps occur to you that not everyone knows Perl variable
> > names are case-sensitive, and that not every programming language is
> > like Perl?
> > You and A. Sinan Unur are being nasty when a quick look at the
> > original script would have been sufficient to understand the
> > miscommunication.
> No.
>
> In the original script, there is a
>
> use strict;
>
> line. Had that line actually been in the script rather than pasted
> into the post as an after-thought, the typo would have been caught by
> the OP.
>
> Hence, my belief that the poster intentionally misrepresented the
> contents of the script. That is, he lied.
How typical. Just assume he lied. I suppose it also didn't occur to you
that maybe he mistakenly capitalized the those variables in that one
line by mistake? Or maybe something happened when spellchecking. It
easily could have been just a harmless mistake, yet you act like he just
lied in court and you're the judge.
--
G.Etly
Bill H
Hear Hear!
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.
I was hesitant to answer the orginal post with my recommendation of
using print "location.." for fear of getting sent through the read the
faq and perldoc this and that wringer, but felt I should at least
offer my 2 cents.
Going off the ranch: I have noticed in my few years of reading this
group on a daily basis that a majority (whether large or slim) of the
questions seem to be concerning using perl in a cgi environment, but a
many of the answers to these questions seem to present solutions that
will not work in a cgi environment. For example the simple "die"
statement. If you use that in a cgi and call the perl from a web
browser you will get (or it has at least been my experience, I could
be wrong (and probably am)) a 500 internal server error.
The other suggestion of installing this or using that module, not
everyone who is programming in perl for cgi has their own server or
has the ability of adding new modules to the server (fortunatly I do)
and have to work within the capabilities of the system they are
running on. So if they post a problem and there is a solution that
wouldn't require them installing a module, recommend it, instead of
just saying use blah::blah.
Another 2 cents, makes 4 cents for the day. If I post another 198
times I will have paid for a gallon of gas.
Bill H
PS: feel free to rip this apart - but keep in mind I am a "people".
Gunnar Hjalmarsson
> I have noticed in my few years of reading this
> group on a daily basis that a majority (whether large or slim) of the
> questions seem to be concerning using perl in a cgi environment, but a
> many of the answers to these questions seem to present solutions that
> will not work in a cgi environment. For example the simple "die"
> statement. If you use that in a cgi and call the perl from a web
> browser you will get (or it has at least been my experience, I could
> be wrong (and probably am)) a 500 internal server error.
While I agree that questions on programs aimed to run as CGI programs
are often and unnecessarily twisted by some regulars, the example you
give is not a good one. 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.
> The other suggestion of installing this or using that module, not
> everyone who is programming in perl for cgi has their own server or
> has the ability of adding new modules to the server (fortunatly I do)
> and have to work within the capabilities of the system they are
> running on. So if they post a problem and there is a solution that
> wouldn't require them installing a module, recommend it, instead of
> just saying use blah::blah.
Sometimes when people say "can't" install this or that module, they
actually mean "don't know how to". For instance, I have never heard of a
situation when a pure Perl module can't be installed, in one way or
another. So encouraging people to learn how to make use of modules is
usually the right thing to do.
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
szr
> Bill H wrote:
[...]
>> The other suggestion of installing this or using that module, not
>> everyone who is programming in perl for cgi has their own server or
>> has the ability of adding new modules to the server (fortunatly I do)
>> and have to work within the capabilities of the system they are
>> running on. So if they post a problem and there is a solution that
>> wouldn't require them installing a module, recommend it, instead of
>> just saying use blah::blah.
>
> Sometimes when people say "can't" install this or that module, they
> actually mean "don't know how to". For instance, I have never heard
> of a situation when a pure Perl module can't be installed, in one way
> or another. So encouraging people to learn how to make use of modules
> is usually the right thing to do.
There are some modules, even pure Perl ones, that might have a
dependency on something that isn't installed, and the user is not able
to install said dependency. Or one doesn't have shell access or the
hosting account uses a Windows server (and most don't give you any sort
of shell or remote desktop access.) There can be many reasons why one
might not be able to install a module.
--
szr
Bill H
> Bill H wrote:
> > I have noticed in my few years of reading this
> > group on a daily basis that a majority (whether large or slim) of the
> > questions seem to be concerning using perl in a cgi environment, but a
> > many of the answers to these questions seem to present solutions that
> > will not work in a cgi environment. For example the simple "die"
> > statement. If you use that in a cgi and call the perl from a web
> > browser you will get (or it has at least been my experience, I could
> > be wrong (and probably am)) a 500 internal server error.
>
> While I agree that questions on programs aimed to run as CGI programs
> are often and unnecessarily twisted by some regulars, the example you
> give is not a good one. 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.
Gunar you are absolutly right on this. While I was typing the above I
wanted to type in "unless you use the CGI::Carp" but since I didnt
have the proper sytnax at hand I didnt want to type in the wrong
information (hence my "I could be wrong (and probably am)" :)
>
> > The other suggestion of installing this or using that module, not
> > everyone who is programming in perl for cgi has their own server or
> > has the ability of adding new modules to the server (fortunatly I do)
> > and have to work within the capabilities of the system they are
> > running on. So if they post a problem and there is a solution that
> > wouldn't require them installing a module, recommend it, instead of
> > just saying use blah::blah.
>
> Sometimes when people say "can't" install this or that module, they
> actually mean "don't know how to". For instance, I have never heard of a
> situation when a pure Perl module can't be installed, in one way or
> another. So encouraging people to learn how to make use of modules is
> usually the right thing to do.
I am sure that is the case many times. Personal experience on my end,
working with a clients hosting provider (network solutions) we needed
to install a simple Perl API from their merchant gateway to calculate
sales tax. Since the client was in a shared hosting environment they
couldn't do it, the only solution provided by netsol was to upgrade to
a virtual server environment. I ended up just writing the code in
their Perl order processor to replicate the API's function.
Bill H
Dick Sutton
"Gordon Etly" <n...@clpm.dilavni> wrote in message
news:6a8ncqF...@mid.individual.net...
Gordon Etly,
I am sure that people like Mr. Unur are a relatively small group. However,
I would like to point out that I had never 'run' the script because I didn't
know how to finish it. As I also pointed out, I am a new to Perl scripts.
Yes, I did mistype the lines in question. You may even find further syntax
errors in the piece of code that I presented. After all, I said I was
stuck, I hadn't finished it. I didn't paste in a line 'use strict;' just to
harass the newsgroup. I read that Perl programs should use that line, so I
placed it in there.
I really take offense at being called a liar and being incompetent. I am
trying to learn Perl on my own and I expect to make mistakes. But I don't
expect to be insulted.
Again, I thank those that made an honest attempt to help me, but I believe I
may be better served at this point to go to the library and check out a few
Perl books and continue learning on my own.
Dick
Gunnar Hjalmarsson
> Gunnar Hjalmarsson wrote:
>> Bill H wrote:
>>> The other suggestion of installing this or using that module, not
>>> everyone who is programming in perl for cgi has their own server or
>>> has the ability of adding new modules to the server (fortunatly I do)
>>> and have to work within the capabilities of the system they are
>>> running on. So if they post a problem and there is a solution that
>>> wouldn't require them installing a module, recommend it, instead of
>>> just saying use blah::blah.
>>
>> Sometimes when people say "can't" install this or that module, they
>> actually mean "don't know how to". For instance, I have never heard
>> of a situation when a pure Perl module can't be installed, in one way
>> or another. So encouraging people to learn how to make use of modules
>> is usually the right thing to do.
>
> There are some modules, even pure Perl ones, that might have a
> dependency on something that isn't installed, and the user is not able
> to install said dependency.
Well, I for one wouldn't say "pure Perl module" about a module that's
dependent on a non-core XS module.
> Or one doesn't have shell access or the
> hosting account uses a Windows server (and most don't give you any sort
> of shell or remote desktop access.)
You don't need shell access to install a pure Perl module. Sure, you
can't install it "the right way", but uploading a .pm file to a suitable
folder with e.g. FTP and adding a "use lib" statement is always possible.
szr
> szr wrote:
>> Gunnar Hjalmarsson wrote:
>>> Bill H wrote:
>>>> The other suggestion of installing this or using that module, not
>>>> everyone who is programming in perl for cgi has their own server or
>>>> has the ability of adding new modules to the server (fortunatly I
>>>> do) and have to work within the capabilities of the system they are
>>>> running on. So if they post a problem and there is a solution that
>>>> wouldn't require them installing a module, recommend it, instead of
>>>> just saying use blah::blah.
>>>
>>> Sometimes when people say "can't" install this or that module, they
>>> actually mean "don't know how to". For instance, I have never heard
>>> of a situation when a pure Perl module can't be installed, in one
>>> way or another. So encouraging people to learn how to make use of
>>> modules is usually the right thing to do.
>>
>> There are some modules, even pure Perl ones, that might have a
>> dependency on something that isn't installed, and the user is not
>> able to install said dependency.
>
> Well, I for one wouldn't say "pure Perl module" about a module that's
> dependent on a non-core XS module.
Where did I say XS module? I meant even a pure Perl module could still
require some facility on the system. Maybe a certain type of hardware,
or it scrapes the output of a specific program that spews a certain type
of data. The reason doesn't really matter, the point is it is quite
possible.
>> Or one doesn't have shell access or the
>> hosting account uses a Windows server (and most don't give you any
>> sort of shell or remote desktop access.)
>
> You don't need shell access to install a pure Perl module. Sure, you
> can't install it "the right way", but uploading a .pm file to a
> suitable folder with e.g. FTP and adding a "use lib" statement is
> always possible.
Yes, but that can still be problematic with certain kinds of hosting
setups (again, Windows setups would fall into that category.)
--
szr
Ben Morrow
Quoth "Dick Sutton" <rsut...@comcast.net>:
>
> I am sure that people like Mr. Unur are a relatively small group. However,
> I would like to point out that I had never 'run' the script because I didn't
> know how to finish it.
So write the bit you *do* know how to do, and run that. If you'd read
the posting guildlines you'd have found that posting code you haven't
run is unhelpful, as it's all too likely to contain error unrelated to
your real problem.
> As I also pointed out, I am a new to Perl scripts.
> Yes, I did mistype the lines in question. You may even find further syntax
> errors in the piece of code that I presented.
There is no need to post code with syntax errors. Even if you can't make
the code do what you want, you can still get it to the point where
'perl -c' doesn't complain. Anyone looking at it will have to do that
before anything else, so it's courteous to do it yourself.
> After all, I said I was
> stuck, I hadn't finished it. I didn't paste in a line 'use strict;' just to
> harass the newsgroup. I read that Perl programs should use that line, so I
> placed it in there.
Putting 'use strict' there is a good move, but the important part is
*fixing all the subsequent error messages*.
> I really take offense at being called a liar and being incompetent. I am
> trying to learn Perl on my own and I expect to make mistakes. But I don't
> expect to be insulted.
If you take offence that easily you should stay away from Usenet. While
rudeness may not be necessary or helpful, it is certainly common; and
many of those best placed to provide helpful advice are inclined to
expect those asking for it to help themselves as much as possible, and
are often rather sharp if they do not.
> Again, I thank those that made an honest attempt to help me, but I believe I
> may be better served at this point to go to the library and check out a few
> Perl books and continue learning on my own.
This could be described as 'making an honest attempt to help yourself'.
Why didn't you do that *before* asking a whole lot of people you've
never met to help you for free?
Ben
--
I've seen things you people wouldn't believe: attack ships on fire off
the shoulder of Orion; I watched C-beams glitter in the dark near the
Tannhauser Gate. All these moments will be lost, in time, like tears in rain.
Time to die. b...@morrow.me.uk
Joe Schaefer
> First of all, I am a rank amateur at Perl. Here is my problem: I have a
> hundred or more files in a directory on a web server (let's call it
> 'Library'). Each file is a pdf file and is named 'yyyymmm.pdf' where yyyy
> is the year (i.e. 2007) and mmm is the first 3 letters of the month (i.e.
> Jan). So a typical file name looks like '2007Jan.pdf'.
>
> I wrote a simple html page using FORM that allows the user to select the
> year and the month and then press the SUBMIT button and I want the
> respective pdf file returned into the users browser. The problem is, I
> don't know how to return a pdf file to the browser.
>
> Here's what I have so far:
>
> #!/usr/local/bin/perl -wT
> use strict;
> use CGI ':standard';
>
> # declare variables...
> my $year;
> my $month;
> my $pdffile;
>
> # get the parameters...
> $year = param('Year');
> $month = param('Month');
>
> # construct the relative pathname to the actual PDF file
> $pdffile = '../Library/'.$Year.$Month.'.pdf';
>
> print 'Content-type: application/pdf\n\n';
>
> This is where I'm stuck. Can someone push me in the right direction. I
> would think it should be trivial. I just don't know how to procede.
What you're about to do gets sticky because you need to
untaint the parameters you received. You need to untaint
them because if you don't, you could expose almost
every file on your filesystem to being readable
through your script.
The next step is to open the pdffile and read it
into a variable, then print that variable out
to the browser.
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;
}
# you can use this hash to do impedance matching
# between the parameters passed into your script
# and the naming conventions for your files
my %month_names = (
Jan => "Jan",
Feb => "Feb",
Mar => "Mar",
Apr => "Apr",
May => "May",
Jun => "Jun",
Jul => "Jul",
Aug => "Aug",
Sep => "Sep",
Oct => "Oct",
Nov => "Nov",
Dec => "Dec",
);
for (scalar param("Month")) {
defined or die "Missing 'Month' parameter";
$month = $month_names{$_} or die "Bad 'Month' parameter:$_";
}
my $pdffile = "../Library/$year$month.pdf";
open my $pdfh, "<", $pdffile or die "Can't open file $pdffile:$!";
print "Content-Type: application/pdf\n\n";
print while read $pdfh, $_, 8192;
exit 0;
Gunnar Hjalmarsson
> Gunnar Hjalmarsson wrote:
>> szr wrote:
>>> Gunnar Hjalmarsson wrote:
>>>> Bill H wrote:
>>>>> The other suggestion of installing this or using that module, not
>>>>> everyone who is programming in perl for cgi has their own server or
>>>>> has the ability of adding new modules to the server (fortunatly I
>>>>> do) and have to work within the capabilities of the system they are
>>>>> running on. So if they post a problem and there is a solution that
>>>>> wouldn't require them installing a module, recommend it, instead of
>>>>> just saying use blah::blah.
>>>> Sometimes when people say "can't" install this or that module, they
>>>> actually mean "don't know how to". For instance, I have never heard
>>>> of a situation when a pure Perl module can't be installed, in one
>>>> way or another. So encouraging people to learn how to make use of
>>>> modules is usually the right thing to do.
>>> There are some modules, even pure Perl ones, that might have a
>>> dependency on something that isn't installed, and the user is not
>>> able to install said dependency.
>> Well, I for one wouldn't say "pure Perl module" about a module that's
>> dependent on a non-core XS module.
>
> Where did I say XS module? I meant even a pure Perl module could still
> require some facility on the system.
Ok, you are right, any kind of dependency may prevent a module from working.
OTOH, the point I was trying to make is that non-module solutions to
presented problems should be a last resort, when suitable modules exist.
Hope you can agree to that. :)
>>> Or one doesn't have shell access or the
>>> hosting account uses a Windows server (and most don't give you any
>>> sort of shell or remote desktop access.)
>> You don't need shell access to install a pure Perl module. Sure, you
>> can't install it "the right way", but uploading a .pm file to a
>> suitable folder with e.g. FTP and adding a "use lib" statement is
>> always possible.
>
> Yes, but that can still be problematic with certain kinds of hosting
> setups (again, Windows setups would fall into that category.)
What kinds of setups are you thinking of? It certainly does not apply to
all Windows ditto.
szr
Yes, I can agree to that (though I thought we were talking about
installing modules; I didn't see anything mentioned about using
non-module solutions.)
>>>> Or one doesn't have shell access or the
>>>> hosting account uses a Windows server (and most don't give you any
>>>> sort of shell or remote desktop access.)
>>>
>>> You don't need shell access to install a pure Perl module. Sure, you
>>> can't install it "the right way", but uploading a .pm file to a
>>> suitable folder with e.g. FTP and adding a "use lib" statement is
>>> always possible.
>>
>> Yes, but that can still be problematic with certain kinds of hosting
>> setups (again, Windows setups would fall into that category.)
>
> What kinds of setups are you thinking of? It certainly does not apply
> to all Windows ditto.
Many shared hosting setups make difficult to use any module that doesn't
work out of the box ("out of the box" meaning pulling out the .pm's and
such into a dir and using 'use lib'.)
--
szr
A. Sinan Unur
news:bec27717-a518-4a63...@56g2000hsm.googlegroups.com:
> On May 29, 5:50 pm, Ben Bullock <benkasminbull...@gmail.com> wrote:
>> On Thu, 29 May 2008 21:05:15 +0000, A. Sinan Unur wrote:
>> > Hence, my belief that the poster intentionally misrepresented the
>> > contents of the script. That is, he lied.
>>
>> Why you (and John Bokma, and others) endlessly insult and harass
>> newcomers to this newsgroup I don't know, but I don't enjoy reading
>> it, and I wish you'd stop it.
>
> Hear Hear!
Well, I don't enjoy trying to help someone only to find out halfway
through that that someone posted a script that was *intentionally*
misleading.
If the OP had posted:
my $year;
# ...
$Year = 1999;
# ...
print "$year\n";
and then asked why he wasn't getting the expected output, I would not
have reacted strongly. In that case, I would have pointed out that in
Perl variable names are case sensitive: I.e. $year and $Year are
different variables. Told him that strict would have caught that error.
What the OP did was to put
use strict;
in his post when that statement had not been in the script he was
working on. The only reason he put it in there was to make his post look
good and he left it to others (namely the one person who pointed out
that the <select></select> in HTML does not eliminate the need for
server-side parameter validation, the one person who pointed out that he
was using \n inside of a single-quoted string etc) to find out in the
middle of trying to help him that he could not have been bothered to do
the minimal amount of work required to help himself.
> many of the answers to these questions seem to present solutions that
> will not work in a cgi environment. For example the simple "die"
> statement. If you use that in a cgi and call the perl from a web
> browser you will get (or it has at least been my experience, I could
> be wrong (and probably am)) a 500 internal server error.
And how would you suppose we deal with that? There are many ways one
could deal with that on a real server. We use die here as a shortcut
because we cannot be asked to write custom solutions for each person's
specific situation. It is up to the person who is developing the web
site to decide how to deal with errors and what information to present
to the web site user. Note that fatalsToBrowser should not be used on a
server facing the world. Never.
> The other suggestion of installing this or using that module, not
> everyone who is programming in perl for cgi has their own server or
> has the ability of adding new modules to the server (fortunatly I do)
> and have to work within the capabilities of the system they are
> running on. So if they post a problem and there is a solution that
> wouldn't require them installing a module, recommend it, instead of
> just saying use blah::blah.
As has been pointed out, there is almost never any good reason to avoid
using CPAN modules.
What do you want us to do? Re-create the same solutions over and over
and over in UseNet posts?
A. Sinan Unur
fbb25f...@m3g2000hsc.googlegroups.com:
> I am sure that is the case many times. Personal experience on my end,
> working with a clients hosting provider (network solutions) we needed
> to install a simple Perl API from their merchant gateway to calculate
> sales tax. Since the client was in a shared hosting environment they
> couldn't do it, the only solution provided by netsol was to upgrade to
> a virtual server environment. I ended up just writing the code in
> their Perl order processor to replicate the API's function.
First off, what is the point of doing e-commerce on shared hosting?
Second, are you claiming that you could not have copied files over FTP
to the same location where you were going to put the script?
> Bill H
>
>>
>> --
>> Gunnar Hjalmarsson
>> Email:http://www.gunnar.cc/cgi-bin/contact.pl
Do *NOT* quote sigs.
Ben Bullock
> 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.
Jürgen Exner
>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:
Plus it can provide information about the program, which could possibly
be used to exploit security holes in the program by crackers.
Therefore, as you said: don't use in production code.
jue
John W. Krahn
>
> 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";
$year = $1;
> # you can use this hash to do impedance matching
> # between the parameters passed into your script
> # and the naming conventions for your files
>
> my %month_names = (
> Jan => "Jan",
> Feb => "Feb",
> Mar => "Mar",
> Apr => "Apr",
> May => "May",
> Jun => "Jun",
> Jul => "Jul",
> Aug => "Aug",
> Sep => "Sep",
> Oct => "Oct",
> Nov => "Nov",
> Dec => "Dec",
> );
I don't do CGI so I don't know why you would need this hash?
> for (scalar param("Month")) {
> defined or die "Missing 'Month' parameter";
> $month = $month_names{$_} or die "Bad 'Month' parameter:$_";
> }
defined( my $month = param( 'Month' ) )
or die "Missing 'Month' parameter";
$month = $month_names{ $month } or die "Bad 'Month' parameter:$month";
> my $pdffile = "../Library/$year$month.pdf";
> open my $pdfh, "<", $pdffile or die "Can't open file $pdffile:$!";
I'm not sure but you probably need binary mode for a PDF file?
open my $pdfh, '<:raw', $pdffile or die "Can't open file $pdffile:$!";
> print "Content-Type: application/pdf\n\n";
> print while read $pdfh, $_, 8192;
>
> exit 0;
John
--
Perl isn't a toolbox, but a small machine shop where you
can special-order certain sorts of tools at low cost and
in short order. -- Larry Wall
A. Sinan Unur
news:87k5hcy...@gemini.sunstarsys.com:
> # you can use this hash to do impedance matching
> # between the parameters passed into your script
> # and the naming conventions for your files
How about: "you can use this hash to map parameters passed to your
script to the naming convention of your files".
> 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.
my %month_names = (
Jan => 0,
# ...
);
...
defined( my $month = param('Month') ) or die 'Missing month';
exists $month_names{ $month } or die 'Invalid month';
$month = $month_names{ $month };
> my $pdffile = "../Library/$year$month.pdf";
> 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.
> exit 0;
Not necessary.
Charlton Wilbur
BH> Many an interesting topic has been killed by the need to disect
BH> a post. Remember, perl is a programming language, programmers
BH> are people. Try to keep them distinct and apply some people
BH> skills where appropriate, and by all means, share with us your
BH> programming skills which the vast majority of you have in excess
BH> 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.
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 -- 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.
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?
Charlton
--
Charlton Wilbur
cwi...@chromatico.net
Peter J. Holzer
> What the OP did was to put
>
> use strict;
>
> in his post when that statement had not been in the script he was
> working on.
You don't know that. He could also have misspelt $year as $Year when
typing the script into his newsreader (a surprising number of people
here don't seem to know how to use cut and paste). Or he may never have
tried to invoke his script at all since wasn't yet complete.
> The only reason he put it in there was to make his post look
> good
Again, you don't know that.
hp
Ted Zlatanov
ASU> Ted Zlatanov <t...@lifelogs.com> wrote in
ASU> news:86od6og...@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 pasted into
ASU> the post as an after-thought, the typo would have 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?
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.
Ted
A. Sinan Unur
> On Thu, 29 May 2008 21:05:15 GMT "A. Sinan Unur"
> <1u...@llenroc.ude.invalid> wrote:
>
> ASU> Ted Zlatanov <t...@lifelogs.com> wrote in
> ASU> news:86od6og...@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.
szr
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
szr
> Bill H <bi...@ts1000.us> writes:
>
>> Many an interesting topic has been killed by the need to disect
>
> 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
Joe Schaefer
> Joe Schaefer <joe+u...@sunstarsys.com> wrote in
> news:87k5hcy...@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
Joe Schaefer
> 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
A. Sinan Unur
> "A. Sinan Unur" <1u...@llenroc.ude.invalid> writes:
>
>> Joe Schaefer <joe+u...@sunstarsys.com> wrote in
>> news:87k5hcy...@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.
Joe Schaefer
[...]
> 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
Peter J. Holzer
> Joe Schaefer <joe+u...@sunstarsys.com> wrote in
> news:874p8fy...@gemini.sunstarsys.com:
>> "A. Sinan Unur" <1u...@llenroc.ude.invalid> writes:
>>> Joe Schaefer <joe+u...@sunstarsys.com> wrote in
>>> news:87k5hcy...@gemini.sunstarsys.com:
>>
>>>> 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
s...@netherlands.co
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
A. Sinan Unur
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__
s...@netherlands.co
>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
xho...@gmail.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.
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.
s...@netherlands.co
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
s...@netherlands.co
>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
s...@netherlands.co
[..]
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
s...@netherlands.co
>"szr" <sz...@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
szr
> "szr" <sz...@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
comp.llang.perl.moderated
I've used a default page that exposes only a sanitized message and
then
mails debug back to me.
--
Charles DeRykus
szr
Yes I've used such things and can be convenient. It all depends on what
you're doing, and in what sort of environment.
--
szr
xho...@gmail.com
> >> >
> >> > 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.
I won't be where?
> The whole idea is programmed error recovery.
Presumably we've already tried that to the extent it can be done. Simple
errors that can be recovered should of course be recovered. But many
errors can't be recovered. If if a file that is critical can't be
accessed, or if a database that is critical cannot be connected to, then
there is no recovery to be done. Pretending otherwise is not error
recovery, it is just launching an infinitude of crap in which you refuse to
acknowledge the existence of a problem which obviously does exist.
> 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.
My paycheck never seems to bounce, so the world I live in seems to be money
world.
Martijn Lievaart
> Quoth "Dick Sutton" <rsut...@comcast.net>:
>
>> Again, I thank those that made an honest attempt to help me, but I
>> believe I may be better served at this point to go to the library and
>> check out a few Perl books and continue learning on my own.
>
> This could be described as 'making an honest attempt to help yourself'.
> Why didn't you do that *before* asking a whole lot of people you've
> never met to help you for free?
Better yet, do both.
Learning Perl is a lot easier with some good books. May I recommend the
O'Reillys? Stay away from all other books unless you know why you want
that other book. Go to a good bookstore so you can thumb the books, see
which one appeals to you.
But don't shy away from this group. The help here is awesome, once you
get the hang of the little rules of this group.
That's certainly not specific to this group. In any group, it is
recommended to "lurk" a while before posting. In a high volume group like
this, lurking is often best done by searching the archives for your
problem, by reading a few dozen threads you'll get a feel for the group.
Also, as Ben pointed out, if you are easily offended, stay away from
usenet in general. Besides some people being naturally rude, some people
are rude because they see the same question for the tenth time that day,
or didn't have their morning coffee yet, or read something into your post
you didn't mean to put there, or...
Or, and even more important, you take offense to a reply that wasn't
meant to be offensive. That may or may not apply to posts in this thread,
but this happens so often I have to mention it.
I think your first contact with this group was unfortunate. To you,
having a runnable program was not important, you just wanted some
pointers. To (most) others, having a runnable program is important, which
you didn't know yet.
I do hope you'll be back, people here are eager to help. Learn the little
rules of this group, ignore the more rude remarks, use Google first, ask
in the group second and try to make a honest attempt at something
runnable before you post.
Hope to see you back!
M4
s...@netherlands.co
>s...@netherlands.co wrote:
>> On 30 May 2008 18:44:40 GMT, xho...@gmail.com wrote:
>> >> Ben Bullock wrote:
>> >> >
>> >> > 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.
>
>I won't be where?
>
You not there and never will be.
>
>> The whole idea is programmed error recovery.
>
>Presumably we've already tried that to the extent it can be done. Simple
>errors that can be recovered should of course be recovered. But many
>errors can't be recovered. If if a file that is critical can't be
>accessed, or if a database that is critical cannot be connected to, then
>there is no recovery to be done. Pretending otherwise is not error
>recovery, it is just launching an infinitude of crap in which you refuse to
>acknowledge the existence of a problem which obviously does exist.
>
I guess the customer will not pretend an understanding of your frustration.
>> 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.
>
>My paycheck never seems to bounce, so the world I live in seems to be money
>world.
>
I doubt seriously if employment is of any concern to you.
sln