[23723] in Perl-Users-Digest
Perl-Users Digest, Issue: 5929 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Dec 11 21:10:39 2003
Date: Thu, 11 Dec 2003 18:10:11 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Thu, 11 Dec 2003 Volume: 10 Number: 5929
Today's topics:
Re: Server-side script executed on page load or event, <henryn@zzzspacebbs.com>
Re: Server-side script executed on page load or event, <spamfilter@dot-app.org>
Re: Server-side script executed on page load or event, <henryn@zzzspacebbs.com>
Re: Sorting dates...Argument "" isn't numeric <bik.mido@tiscalinet.it>
use CGI; vs use CGI qw(:standard); <someone@somewhere.nb.ca>
Re: use CGI; vs use CGI qw(:standard); <emschwar@pobox.com>
Re: use CGI; vs use CGI qw(:standard); (Malcolm Dew-Jones)
Re: use CGI; vs use CGI qw(:standard); <me@privacy.net>
Re: use CGI; vs use CGI qw(:standard); <matthew.garrish@sympatico.ca>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 11 Dec 2003 19:48:25 GMT
From: Henry <henryn@zzzspacebbs.com>
Subject: Re: Server-side script executed on page load or event, but not SSI
Message-Id: <BBFE0A07.19056%henryn@zzzspacebbs.com>
James:
Thanks for your reply on this thead:
in article 20031211122836.11c6c053.jwillmore@remove.adelphia.net, James
Willmore at jwillmore@remove.adelphia.net wrote on 12/11/03 9:28 AM:
> On Thu, 11 Dec 2003 16:57:01 GMT
> Henry <henryn@zzzspacebbs.com> wrote:
>> in article 20031210153122.43d1234b.jwillmore@remove.adelphia.net,
>> James Willmore at jwillmore@remove.adelphia.net wrote on 12/10/03
>> 12:31 PM:
>>> On Wed, 10 Dec 2003 04:19:06 GMT
>>> Henry <henryn@zzzspacebbs.com> wrote:
>
>> Gee, I'm sorry I used the term 'database'. For what I wanted to
>> ask, it really doesn't much matter what the raw material is.
>
> Well, in a way it does. If you're reading a CSV file, then the
> DBD::CSV module can aid in this task. OTOH, you know what you're
> doing with the information better than I do. So, I'll just move on
> :-)
Thanks, I didn't get that kind of meaning from the docs. If I ever have a
standard format I'll know there's help.
What I'm reading is law codes. I've searched all the usual places and some
unusual ones for help parsing these, but without success.
>
>
>> Are there any other perl alternatives? I guess I can run
>> javascript or tcl from any intrinsic event --per the html 4 standard
>> chapter 18-- but I don't seem to be able to do this with perl,
>> right? I'm not up to learning yet another language at this
>> point -- my hands are full with perl.
>
> You can use Perl for the task you're suggesting. What are you using
> now to display the pages? Are they static?
The base/home/initial page is static html. Everything else is CGI-generated.
> If so, would you be adverse to having the pages be dynamic on the server side
> (meaning, have a CGI script display the pages)? Just off the top of my head,
> you could use a single script to execute a command (like finding out if the
> pages are up to date), then redirect the user to the appropriate page. No
> 'form' required :-) That could be one solution.
>
> I know it can be done with Perl. You just need to re-think what you
> want and how to get there (outside the box, as it where).
Right, I see what you mean.
Actually, after I sent my last response, I reversed myself (interesting
concept!) and decided, what-the-heck, to try SSIs. Enabled the Apache
server, and Shazam! Full access to perl scripting without the user being
necessarily aware or doing anything specific, which is what I wanted. It's
clear I'll be able to do what I want with this mechanism.
I guess I was reluctant to use SSIs because I thought I recalled some
security issues or unusual complexity, but --upon second view-- this seems
pretty bulletproof and simple to implement.
Yes, it's a question of conceptualization...and knowledge. Partly as simple
as this: Can the index/home/base page itself be (be generated by) a cgi
script, i.e., will Apache look for index.cgi if it doesn't find index.html,
etc.?
Partly an issue of understanding the HTML standards with respect to
scripting, reading behind the lines to understand what scripting languages
are supported by the SCRIPT tag, e.g.
<SCRIPT type="[something]" src="[something else]">
Apparently, JavaScript, VBA, Tcl are options, but perl isn't.
Thanks,
Henry
henryn@zzzspacebbs.com remove 'zzz'
>
> HTH
------------------------------
Date: Thu, 11 Dec 2003 20:50:42 GMT
From: Sherm Pendley <spamfilter@dot-app.org>
Subject: Re: Server-side script executed on page load or event, but not SSI
Message-Id: <CM4Cb.12633$NN.2119650@news1.news.adelphia.net>
Henry wrote:
> as this: Can the index/home/base page itself be (be generated by) a cgi
> script, i.e., will Apache look for index.cgi if it doesn't find index.html,
> etc.?
Apache *can* be configured to do that.
It's a two-step process - first, you have to configure it to treat *.cgi
files as CGI's instead of just serving their contents statically:
AddHandler cgi-script .cgi
Also, you need to include index.cgi to the list of default documents:
DirectoryIndex index.cgi index.shtml index.html
Having said that, whether your provider has done the above, will do it,
or will let you do it via .htaccess, are all questions I can't answer
for you. :-(
> Partly an issue of understanding the HTML standards with respect to
> scripting, reading behind the lines to understand what scripting languages
> are supported by the SCRIPT tag, e.g.
>
> <SCRIPT type="[something]" src="[something else]">
>
> Apparently, JavaScript, VBA, Tcl are options, but perl isn't.
Strictly speaking, the script element simply defines its contents as a
script - supported languages are beyond the scope of any HTML standard.
In practical terms, some form of JavaScript (AKA ECMAScript) is the only
option that's supported by all script-aware browsers. Even so, not all
browsers are script-aware, and many users choose to disable scripting
for various reasons. There are also many versions of JS in use, so
writing portable JS is a bit of a chore.
Other languages are options for some browsers. IE/Windows, for example,
allows any language that's available via the Windows Scripting interface
- including VBScript, ActiveState's Perl, and many others. There are
other options, such as browser plugins.
In short, if you're writing for a captive audience and you're able to
dictate what browser they use and what plugins they have, you have many
options for browser-side scripting. If you're serving pages to the
general public, JavaScript is your only semi-practical option - and even
JS has issues.
sherm--
------------------------------
Date: Thu, 11 Dec 2003 22:17:06 GMT
From: Henry <henryn@zzzspacebbs.com>
Subject: Re: Server-side script executed on page load or event, but not SSI
Message-Id: <BBFE2CDC.19071%henryn@zzzspacebbs.com>
Sherm:
Thanks for your reply on this thread:
in article CM4Cb.12633$NN.2119650@news1.news.adelphia.net, Sherm Pendley at
spamfilter@dot-app.org wrote on 12/11/03 12:50 PM:
> Henry wrote:
>
>> as this: Can the index/home/base page itself be (be generated by) a cgi
>> script, i.e., will Apache look for index.cgi if it doesn't find index.html,
>> etc.?
>
> Apache *can* be configured to do that.
>
> It's a two-step process - first, you have to configure it to treat *.cgi
> files as CGI's instead of just serving their contents statically:
>
> AddHandler cgi-script .cgi
I'm pretty sure that's already there, enabled.
>
> Also, you need to include index.cgi to the list of default documents:
>
> DirectoryIndex index.cgi index.shtml index.html
So _that_ is how it is done! This has been a minor mystery for me since I
found a list that purported to be the start page file name/search order
followed by _every_ web server...and I quickly found that this wasn't true
with the first server I checked.
>
> Having said that, whether your provider has done the above, will do it,
> or will let you do it via .htaccess, are all questions I can't answer
> for you. :-(
>
I can. It's my own server, so I have complete control. (Just what I need,
another responsibility.)
>> Partly an issue of understanding the HTML standards with respect to
>> scripting, reading behind the lines to understand what scripting languages
>> are supported by the SCRIPT tag, e.g.
>>
>> <SCRIPT type="[something]" src="[something else]">
>>
>> Apparently, JavaScript, VBA, Tcl are options, but perl isn't.
>
> Strictly speaking, the script element simply defines its contents as a
> script - supported languages are beyond the scope of any HTML standard.
Right, that's what I get for looking at a standard, rather than a practical
document. Still, the standard does give examples...for JS, etc. and it
appears these are practical, not theoretical
>
> In practical terms, some form of JavaScript (AKA ECMAScript) is the only
> option that's supported by all script-aware browsers.
So it seems. I've found a JS module that did what I needed (collapsing
lists) and I managed to install it, purely by imitation, on one of my pages.
But I don't speak JS, and would not undertake to learn yet another
technology at this point. Since I started learning perl, I've seen an
ever-expanding set of things to learn.
> Even so, not all
> browsers are script-aware, and many users choose to disable scripting
> for various reasons. There are also many versions of JS in use, so
> writing portable JS is a bit of a chore.
Yet two more reasons to avoid JS. Well, for the moment, I have a captive
audience for my work (just me) so I can pick the browser. Safari works well
for me.
If I'm tempted to use JS, I've got a colleague who --if I buy him a cup of
coffee, or even if I don't-- will gladly go on at great length about why I
would not, should not. (I didn't tell him about the collapsing lists
exercise -- no sense in getting him exercised.)
>
> Other languages are options for some browsers. IE/Windows, for example,
> allows any language that's available via the Windows Scripting interface
> - including VBScript, ActiveState's Perl, and many others. There are
> other options, such as browser plugins.
OK. I could do that, but I'm already pretty standardized on MacOS X.
>
> In short, if you're writing for a captive audience and you're able to
> dictate what browser they use and what plugins they have, you have many
> options for browser-side scripting. If you're serving pages to the
> general public, JavaScript is your only semi-practical option - and even
> JS has issues.
Wow, as a newcomer to this technology (I'm an embedded systems designer) it
seems awfully chaotic. Can you give me a sentence or two on why this is so?
Is it a matter of creativity or commercial interests trying to build in
market share, or what?
>
> sherm--
Thanks,
Henry
henryn@zzzspacebbs.com remove 'zzz'
------------------------------
Date: 11 Dec 2003 21:31:57 GMT
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: Sorting dates...Argument "" isn't numeric
Message-Id: <e9fstv8jvdc3qssm9hgiodnkqq4srcaiif@4ax.com>
On Wed, 10 Dec 2003 13:55:23 -0600, tadmc@augustmail.com (Tad
McClellan) wrote:
> my @sorted = sort datecompare grep length(), @date;
my @sorted = sort datecompare grep $_, @date; #?
Michele
--
# This prints: Just another Perl hacker,
seek DATA,15,0 and print q... <DATA>;
__END__
------------------------------
Date: Thu, 11 Dec 2003 23:15:37 GMT
From: "Guy" <someone@somewhere.nb.ca>
Subject: use CGI; vs use CGI qw(:standard);
Message-Id: <tU6Cb.9864$IF6.450695@ursa-nb00s0.nbnet.nb.ca>
I used to always start my Perl scripts with the following:
#!/usr/bin/perl
use CGI qw(:standard);
But in my search to create a script that would upload a file upon submission
from a web site, I found that these scripts begin with:
#!/usr/bin/perl
use CGI;
And then they continue with code like:
$query=new CGI;
$fname=$query->param("document");
$fhandle=$query->upload("document");
Is this a new flavor of Perl, or is it just a new library...?
Will a Perl script written with use CGI qw(:standard); work if
this one line is changed to use CGI;
In other words, does use CGI; do everything that use CGI
qw(:standard:); does and then some?
Thanks for all
G.Doucet
------------------------------
Date: Thu, 11 Dec 2003 16:32:43 -0700
From: Eric Schwartz <emschwar@pobox.com>
Subject: Re: use CGI; vs use CGI qw(:standard);
Message-Id: <eto3cbrue04.fsf@fc.hp.com>
"Guy" <someone@somewhere.nb.ca> writes:
> I used to always start my Perl scripts with the following:
>
> #!/usr/bin/perl
> use CGI qw(:standard);
Don't forget
use warnings;
use strict;
> But in my search to create a script that would upload a file upon submission
> from a web site, I found that these scripts begin with:
>
> #!/usr/bin/perl
> use CGI;
>
> And then they continue with code like:
>
> $query=new CGI;
> $fname=$query->param("document");
> $fhandle=$query->upload("document");
>
> Is this a new flavor of Perl, or is it just a new library...?
Neither; it's just another way to use the same library you're using
now. When you call param(), upload(), or whatever, CGI.pm is creating
a "query object" behind the scenes, and passing those methods to it.
The form you're asking about just does that explicitly.
If you read the CGI.pm docs, you'll see how to use both forms. If you
want to learn more about object-oriented Perl, read 'perldoc perltoot'.
-=Eric
--
Come to think of it, there are already a million monkeys on a million
typewriters, and Usenet is NOTHING like Shakespeare.
-- Blair Houghton.
------------------------------
Date: 11 Dec 2003 15:56:41 -0800
From: yf110@vtn1.victoria.tc.ca (Malcolm Dew-Jones)
Subject: Re: use CGI; vs use CGI qw(:standard);
Message-Id: <3fd90439@news.victoria.tc.ca>
Guy (someone@somewhere.nb.ca) wrote:
: I used to always start my Perl scripts with the following:
: #!/usr/bin/perl
: use CGI qw(:standard);
: But in my search to create a script that would upload a file upon submission
: from a web site, I found that these scripts begin with:
: #!/usr/bin/perl
: use CGI;
: And then they continue with code like:
: $query=new CGI;
: $fname=$query->param("document");
: $fhandle=$query->upload("document");
: Is this a new flavor of Perl, or is it just a new library...?
: Will a Perl script written with use CGI qw(:standard); work if
: this one line is changed to use CGI;
: In other words, does use CGI; do everything that use CGI
: qw(:standard:); does and then some?
: Thanks for all
: G.Doucet
perldoc CGI
will explain it all.
The CGI library (there is just one if it) has supported both access
techniques for many years, none of the above is at all new.
------------------------------
Date: Fri, 12 Dec 2003 12:56:30 +1300
From: "Tintin" <me@privacy.net>
Subject: Re: use CGI; vs use CGI qw(:standard);
Message-Id: <brb093$1got1$1@ID-172104.news.uni-berlin.de>
"Guy" <someone@somewhere.nb.ca> wrote in message
news:tU6Cb.9864$IF6.450695@ursa-nb00s0.nbnet.nb.ca...
> I used to always start my Perl scripts with the following:
>
> #!/usr/bin/perl
> use CGI qw(:standard);
>
> But in my search to create a script that would upload a file upon
submission
> from a web site, I found that these scripts begin with:
>
> #!/usr/bin/perl
> use CGI;
>
> And then they continue with code like:
>
> $query=new CGI;
> $fname=$query->param("document");
> $fhandle=$query->upload("document");
>
> Is this a new flavor of Perl, or is it just a new library...?
Neither. It's all fully explained in the CGI module documentation which it
appears you haven't read.
>
> Will a Perl script written with use CGI qw(:standard); work if
> this one line is changed to use CGI;
No.
>
> In other words, does use CGI; do everything that use CGI
> qw(:standard:); does and then some?
Mostly. See documentation as previously mentioned.
------------------------------
Date: Thu, 11 Dec 2003 18:48:38 -0500
From: "Matt Garrish" <matthew.garrish@sympatico.ca>
Subject: Re: use CGI; vs use CGI qw(:standard);
Message-Id: <5n7Cb.9848$aF2.1108535@news20.bellglobal.com>
"Guy" <someone@somewhere.nb.ca> wrote in message
news:tU6Cb.9864$IF6.450695@ursa-nb00s0.nbnet.nb.ca...
> I used to always start my Perl scripts with the following:
>
> #!/usr/bin/perl
> use CGI qw(:standard);
>
> But in my search to create a script that would upload a file upon
submission
> from a web site, I found that these scripts begin with:
>
> #!/usr/bin/perl
> use CGI;
>
> And then they continue with code like:
>
> $query=new CGI;
> $fname=$query->param("document");
> $fhandle=$query->upload("document");
>
> Is this a new flavor of Perl, or is it just a new library...?
>
It's neither. It's just a different way of accessing the functions in
CGI.pm. When you add qw(:standard), you are asking Perl to import than
"standard" functions for the module. If you don't import them, you could
still create a new CGI object ($query) to access the functions. Or if you
don't like either method, you could qw(param), for example, and just import
the specific functions you need (I use param as an example because its one
of the only functions I ever use from the module).
> Will a Perl script written with use CGI qw(:standard); work if
> this one line is changed to use CGI;
>
Unlikely. You'd have to import the functions you're using or rewrite the
script using a CGI object as per above
Matt
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
The Perl-Users Digest is a retransmission of the USENET newsgroup
comp.lang.perl.misc. For subscription or unsubscription requests, send
the single line:
subscribe perl-users
or:
unsubscribe perl-users
to almanac@ruby.oce.orst.edu.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
To request back copies (available for a week or so), send your request
to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
where x is the volume number and y is the issue number.
For other requests pertaining to the digest, send mail to
perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
sending perl questions to the -request address, I don't have time to
answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V10 Issue 5929
***************************************
