[31255] in Perl-Users-Digest
Perl-Users Digest, Issue: 2495 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Jul 2 18:18:31 2009
Date: Thu, 2 Jul 2009 11:41:08 -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 Thu, 2 Jul 2009 Volume: 11 Number: 2495
Today's topics:
Best way to do server side tasks with new ISP <paul@peschoen.com>
Re: Best way to do server side tasks with new ISP <hjp-usenet2@hjp.at>
Re: Best way to do server side tasks with new ISP <paul@peschoen.com>
Re: Best way to do server side tasks with new ISP <jurgenex@hotmail.com>
Re: Best way to do server side tasks with new ISP <paul@peschoen.com>
Re: Best way to do server side tasks with new ISP <uri@stemsystems.com>
Re: Best way to do server side tasks with new ISP <vilain@NOspamcop.net>
Re: Best way to do server side tasks with new ISP <noreply@gunnar.cc>
Re: Best way to do server side tasks with new ISP <cwilbur@chromatico.net>
Re: Best way to do server side tasks with new ISP <cwilbur@chromatico.net>
Re: Best way to do server side tasks with new ISP <hjp-usenet2@hjp.at>
Re: Best way to do server side tasks with new ISP <hjp-usenet2@hjp.at>
Re: Best way to do server side tasks with new ISP <hjp-usenet2@hjp.at>
Re: Best way to do server side tasks with new ISP <paul@peschoen.com>
Re: Best way to do server side tasks with new ISP <noreply@gunnar.cc>
Re: Best way to do server side tasks with new ISP <ben@morrow.me.uk>
Re: Best way to do server side tasks with new ISP <tadmc@seesig.invalid>
Re: Best way to do server side tasks with new ISP <hjp-usenet2@hjp.at>
Re: Best way to do server side tasks with new ISP <paul@peschoen.com>
Re: Best way to do server side tasks with new ISP <uri@stemsystems.com>
Re: Best way to do server side tasks with new ISP <mvdwege@mail.com>
Re: Best way to do server side tasks with new ISP <cwilbur@chromatico.net>
Re: Best way to do server side tasks with new ISP <jurgenex@hotmail.com>
Re: Best way to do server side tasks with new ISP <cartercc@gmail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 29 Jun 2009 01:05:05 GMT
From: "Paul E. Schoen" <paul@peschoen.com>
Subject: Best way to do server side tasks with new ISP
Message-Id: <5rU1m.1832$NF6.165@nwrddc02.gnilink.net>
This is my first post here and I have never used Perl, so please bear with
me. I am mostly a hardware guy but I have done a lot of programming since
the punchcard days of the IBM 7094 in 1967, and MSDOS and Windows apps
using BASIC, Pascal, C, and assembly, and embedded Z80 and PIC projects
using assembly and C. More recently I have done some scripting in
JavaScript and VB, and I have done some simple HTML for my website.
I have been with the same dialup ISP, smart.net, since 1996, and I have
been happy enough with the default performance and tools I have used,
particularly a hit counter and the ability to view a directory that does
not have an index.htm. But now I have switched to Verizon FIOS, and their
10M of web space has a broken web counter tool, and viewing of the files in
a directory is forbidden. Also it seems that they do not allow a CGI-BIN
for their residential service.
So I am looking elsewhere for a website host. I could stay with Smart.net
but their web space seems rather expensive. The domain registrar I use,
MyDomain.com, has 10G webspace for about $6/month, and they say they have a
full line of tools like a hit counter and they allow CGI-BIN, but they have
permanantly disabled directory listing of files.
It seems that JavaScript does not provide access to server-side file
directories, and on one forum it was advised to look at
http://us.php.net/manual/en/function.opendir.php. It looks like PHP is
composed of elements of C, Java, and Perl. So I decided to look at Perl,
and I have scanned much of the FAQ. It is rather overwhelming to analyze
and compare the features of so many similar languages and attempt to become
proficient in one or more, especially when I only need to accomplish a few
rather simple things that have probably been done many times before.
I plan to use Borland Delphi for all my local applications, and perhaps use
JScript or VBScript with the WSH for simple local tasks. I also need to use
JavaScript for programming PDF documents using Nitro Pro or Adobe Pro. And
of course some applications such as Access require VBA. And I have also
written some more complex apps in Delphi that use the automation interface
to utilize methods, properties, and events of objects in other programs.
Thus I am just trying to determine if I should attempt to use Perl, or
perhaps PHP or some other language, to do what I want to do. Mostly, I
would like to make a simple index.htm that can display a list of files in
its directory so that users can simply click on any one for download.
Mostly these will be JPG or TXT, but possibly also XLS, DOC, ZIP, or other
common types.
And I would also like to be able to implement a simple form that would have
its results emailed to me, which of course is a common task, but I assume I
would need a CGI application to do that.
Thanks for any advice you may be able to provide.
Paul E. Schoen
www.pstech-inc.com
------------------------------
Date: Mon, 29 Jun 2009 23:34:45 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Best way to do server side tasks with new ISP
Message-Id: <slrnh4icrl.ap0.hjp-usenet2@hrunkner.hjp.at>
On 2009-06-29 01:05, Paul E. Schoen <paul@peschoen.com> wrote:
> This is my first post here and I have never used Perl, so please bear with
> me. I am mostly a hardware guy but I have done a lot of programming since
> the punchcard days of the IBM 7094 in 1967, and MSDOS and Windows apps
> using BASIC, Pascal, C, and assembly, and embedded Z80 and PIC projects
> using assembly and C. More recently I have done some scripting in
> JavaScript and VB, and I have done some simple HTML for my website.
>
> I have been with the same dialup ISP, smart.net, since 1996, and I have
> been happy enough with the default performance and tools I have used,
> particularly a hit counter and the ability to view a directory that does
> not have an index.htm.
[...]
> but their web space seems rather expensive. The domain registrar I use,
> MyDomain.com, has 10G webspace for about $6/month, and they say they have a
> full line of tools like a hit counter and they allow CGI-BIN, but they have
> permanantly disabled directory listing of files.
>
> It seems that JavaScript does not provide access to server-side file
> directories,
This is correct for JavaScript running in the browser (some web servers
offer server side JavaScript - this has of course access to server-side
resources, but not to browser resources).
> and on one forum it was advised to look at
> http://us.php.net/manual/en/function.opendir.php. It looks like PHP is
> composed of elements of C, Java, and Perl.
And Perl is composed of elements of C, awk, and sh (with a little bit of
OOP and functional programming thrown into the mix).
> So I decided to look at Perl,
> and I have scanned much of the FAQ. It is rather overwhelming to analyze
> and compare the features of so many similar languages and attempt to become
> proficient in one or more, especially when I only need to accomplish a few
> rather simple things that have probably been done many times before.
[...]
> Thus I am just trying to determine if I should attempt to use Perl, or
> perhaps PHP or some other language, to do what I want to do.
You could try to solve your problem in Perl, PHP, and a few other
languages and see which one you like best.
Here is a Perl solution which assumes that you can put Perl CGI programs
directly into "normal" directories and aren't constrained to using
cgi-bin:
#!/usr/bin/perl
use warnings;
use strict;
use CGI;
my $cgi = CGI->new();
print "Content-Type: text/html; charset='UTF-8'\n";
print "\n";
print "<title>Directory listing of ",
$cgi->escapeHTML($cgi->self_url),
"</title>\n";
print "<ul>\n";
opendir(my $dh, ".");
for (readdir($dh)) {
print "<li><a href='", $cgi->escapeHTML($_), "'>",
$cgi->escapeHTML($_),
"</a></li>\n";
}
print "</ul>\n";
__END__
Making the output more beautiful, adding metadata (size, modified date,
etc.) and other embellishments are left as an exercise to the reader
;-).
hp
------------------------------
Date: Tue, 30 Jun 2009 03:05:34 GMT
From: "Paul E. Schoen" <paul@peschoen.com>
Subject: Re: Best way to do server side tasks with new ISP
Message-Id: <2if2m.2033$NF6.24@nwrddc02.gnilink.net>
"Peter J. Holzer" <hjp-usenet2@hjp.at> wrote in message
news:slrnh4icrl.ap0.hjp-usenet2@hrunkner.hjp.at...
[snip]
>
> Making the output more beautiful, adding metadata (size, modified date,
> etc.) and other embellishments are left as an exercise to the reader
> ;-).
Thanks for the response. That code looks rather intimidating, compared to
JavaScript. But at least it's a start, and perhaps I can get used to the
syntax and make sense of it.
Paul
------------------------------
Date: Mon, 29 Jun 2009 20:43:30 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Best way to do server side tasks with new ISP
Message-Id: <4d2j45hrinb4es5bq0gilo75ujt36t7kju@4ax.com>
"Paul E. Schoen" <paul@peschoen.com> wrote:
>That code looks rather intimidating, compared to
>JavaScript.
Well, what do you expect? The one is a simple DHTLM scripting language,
the other is a fully-featured general purpose programming langauge.
jue
------------------------------
Date: Tue, 30 Jun 2009 06:07:31 GMT
From: "Paul E. Schoen" <paul@peschoen.com>
Subject: Re: Best way to do server side tasks with new ISP
Message-Id: <DYh2m.2067$NF6.116@nwrddc02.gnilink.net>
"Jürgen Exner" <jurgenex@hotmail.com> wrote in message
news:4d2j45hrinb4es5bq0gilo75ujt36t7kju@4ax.com...
> "Paul E. Schoen" <paul@peschoen.com> wrote:
>>That code looks rather intimidating, compared to
>>JavaScript.
>
> Well, what do you expect? The one is a simple DHTLM scripting language,
> the other is a fully-featured general purpose programming langauge.
Well, I am used to C and Pascal (Delphi), and a little bit of Visual Basic.
I can do just about anything I need on my local machine with those
languages. Then I tried some JavaScript and VBScript using the WSH for some
simple file manipulation scripts, and found some limitations. I also used
some JavaScript in a PDF, and ran into a few more limitations.
But I am coming to understand the issues of security when one includes code
(script) in an HTML document that is downloaded on someone else's machine.
And another level of security when dealing with server-side CGI where even
reading a directory or doing some simple file I/O can be dangerous.
It's already a big leap from embedded assembly and C routines where all of
the hardware and software are visible and under control of the designer, to
applications that run in the context of an OS on a local machine, and then
finally to an instruction set that works in the context of a web page in
someone's browser, or a CGI program that accesses files and resources on a
server.
But mostly I can't understand why well-known languages such as C and
Pascal, or even VB and .NET, are not used for CGI apps (although maybe they
are), and instead require rather arcane-seeming code such as Perl and PHP.
I will need to look into the language a bit more before I can really make a
judgment as to its suitability for my purposes. For now, though, it just
seems confusing.
Paul
------------------------------
Date: Tue, 30 Jun 2009 02:33:09 -0400
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: Best way to do server side tasks with new ISP
Message-Id: <87eit2ut7e.fsf@quad.sysarch.com>
>>>>> "PES" == Paul E Schoen <paul@peschoen.com> writes:
PES> But mostly I can't understand why well-known languages such as C
PES> and Pascal, or even VB and .NET, are not used for CGI apps
PES> (although maybe they are), and instead require rather
PES> arcane-seeming code such as Perl and PHP. I will need to look
PES> into the language a bit more before I can really make a judgment
PES> as to its suitability for my purposes. For now, though, it just
PES> seems confusing.
then you have never tried to do major text munging in c with all of its
problems of memory management, poor string handling, etc. this is true
for most compiled languages. perl was the best dynamic language when cgi
came forth and became the defacto language of the web in those days. its
ease of handling strings and memory made it popular with cgi and many
other application areas. and thinking today that perl is still mostly
used in cgi is way off base as it is used in many more areas and with
major amounts of code (see cpan).
and calling pascal well known today is just being silly. cobol is more
well known and is still being coded.
uri
--
Uri Guttman ------ uri@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 ---------
------------------------------
Date: Mon, 29 Jun 2009 23:47:49 -0700
From: Michael Vilain <vilain@NOspamcop.net>
Subject: Re: Best way to do server side tasks with new ISP
Message-Id: <vilain-0E3EB7.23474929062009@individual.net>
In article <DYh2m.2067$NF6.116@nwrddc02.gnilink.net>,
"Paul E. Schoen" <paul@peschoen.com> wrote:
> "Jürgen Exner" <jurgenex@hotmail.com> wrote in message
> news:4d2j45hrinb4es5bq0gilo75ujt36t7kju@4ax.com...
> > "Paul E. Schoen" <paul@peschoen.com> wrote:
> >>That code looks rather intimidating, compared to
> >>JavaScript.
> >
> > Well, what do you expect? The one is a simple DHTLM scripting language,
> > the other is a fully-featured general purpose programming langauge.
>
> Well, I am used to C and Pascal (Delphi), and a little bit of Visual Basic.
> I can do just about anything I need on my local machine with those
> languages. Then I tried some JavaScript and VBScript using the WSH for some
> simple file manipulation scripts, and found some limitations. I also used
> some JavaScript in a PDF, and ran into a few more limitations.
>
> But I am coming to understand the issues of security when one includes code
> (script) in an HTML document that is downloaded on someone else's machine.
> And another level of security when dealing with server-side CGI where even
> reading a directory or doing some simple file I/O can be dangerous.
>
> It's already a big leap from embedded assembly and C routines where all of
> the hardware and software are visible and under control of the designer, to
> applications that run in the context of an OS on a local machine, and then
> finally to an instruction set that works in the context of a web page in
> someone's browser, or a CGI program that accesses files and resources on a
> server.
>
> But mostly I can't understand why well-known languages such as C and
> Pascal, or even VB and .NET, are not used for CGI apps (although maybe they
> are), and instead require rather arcane-seeming code such as Perl and PHP.
> I will need to look into the language a bit more before I can really make a
> judgment as to its suitability for my purposes. For now, though, it just
> seems confusing.
>
> Paul
C and Pascal can be used as CGI applications. But Perl and PHP
applications can be run within the context of the web server, thereby
scaling a whole lot better (e.g. each connection is still running inside
the web server's process space rather than as a separate CGI process).
Add access to MySQL and you have a full-service application platform.
Just as C and Pascal had their day, there are other web-technologies
attempting to replace Perl and PHP. Most web hosting companies offer
Perl, PHP, and MySQL. Good luck finding Cold Fusion. Or open your
wallet _yearly_ for Microsoft-based development environments. In this
area, the standard development cycle of edit, compile/build, test is
shortened by removing the compile/build phase.
I guess it's time you decide if you want to do web development or
continue doing your C and Pascal programs on DOS. I've been programming
for 30+ years. I learned new languages when I needed to. Fortran,
PDP-11, DEC-10, or VAX assembly couldn't do it all as it turns out.
Just remember that the penalty for complaining is that you'll live
longer (and continue using Pascal). At this rate, you'll outlive a lot
of us. And you'll still be complaining about C and Pascal.
--
DeeDee, don't press that button! DeeDee! NO! Dee...
[I filter all Goggle Groups posts, so any reply may be automatically by ignored]
------------------------------
Date: Tue, 30 Jun 2009 11:23:34 +0200
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: Best way to do server side tasks with new ISP
Message-Id: <7au3t6F20t7uiU1@mid.individual.net>
Michael Vilain wrote:
> C and Pascal can be used as CGI applications. But Perl and PHP
> applications can be run within the context of the web server, thereby
> scaling a whole lot better (e.g. each connection is still running inside
> the web server's process space rather than as a separate CGI process).
> Add access to MySQL and you have a full-service application platform.
>
> ...
Maybe it's time to slow down a bit. The OP wants to be able to list one
or more directories and a hit counter and a form-to-mail app.
Directory listing is a web server thing in the first place. Assuming
Apache, an .htaccess file with this content:
Options +Indexes
might do. If not, it ought to be possible to ask the web hosting
provider to allow directory listing for a specific account, or for one
or more specified directories.
As regards hit counters and form-to-mail scripts, there are numerous of
them out there that may or may not fit the OP's needs. In any case, I
can't see anything wrong with using C for those apps instead of learning
a new language. (The latter presupposes that the hosting provider allows
compiling C programs.)
Scalability, mod_perl and stuff seems not to be a major concern.
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: Tue, 30 Jun 2009 10:37:41 -0400
From: Charlton Wilbur <cwilbur@chromatico.net>
Subject: Re: Best way to do server side tasks with new ISP
Message-Id: <864otxaitm.fsf@mithril.chromatico.net>
>>>>> "PES" == Paul E Schoen <paul@peschoen.com> writes:
PES> But mostly I can't understand why well-known languages such as
PES> C and Pascal, or even VB and .NET, are not used for CGI apps
PES> (although maybe they are), and instead require rather
PES> arcane-seeming code such as Perl and PHP.
Here's an exercise that should illuminate things. If you solve this in
idiomatic C and in idiomatic Perl, you'll start to see the advantage of
Perl.
Given the following line:
foo=1;bar=yes;baz=c;baz=b;baz=c;quux=seven;quux=;submit=true
Produce the following output:
* An alphabetically sorted list of the values assigned to each variable
* The count of values assigned to each variable
* The result of foo * 27 + 3
You can do this in about 20 lines of Perl, using several builtin
functions. C operates at a much lower level, so instead of using Perl
builtins, you have to write your own parser (instead of split), you have
to worry about your data structures (instead of using a hash), you have
to handle memory allocation manually (instead of just letting things go
out of scope), you have to manually convert the value of foo to a number
(instead of just treating it as a number and letting Perl do it for
you).
Now, to be sure, you can write a nice big C library to handle this for
you. But when you're done, you'll have a one-off library that hasn't
been extensively tested, and it will really just be a poor
reimplementation of Perl -- which has been extensively tested for the
past two decades.
(And C *is* used for CGI. At a PPOE, one of my coworkers, who had moved
from the embedded systems world to the web world, had written a number
of CGI programs in C. They were a nightmare to deal with, because
somewhere along the way -- this shop did not really believe in version
control, and backups were a polite fiction -- the source code had been
lost. Given the way his PHP code looked, though, I think that happy
accident saved me some sanity points.)
Charlton
--
Charlton Wilbur
cwilbur@chromatico.net
------------------------------
Date: Tue, 30 Jun 2009 10:39:18 -0400
From: Charlton Wilbur <cwilbur@chromatico.net>
Subject: Re: Best way to do server side tasks with new ISP
Message-Id: <86zlbp946h.fsf@mithril.chromatico.net>
>>>>> "MV" == Michael Vilain <vilain@NOspamcop.net> writes:
MV> C and Pascal can be used as CGI applications. But Perl and PHP
MV> applications can be run within the context of the web server,
MV> thereby scaling a whole lot better (e.g. each connection is
MV> still running inside the web server's process space rather than
MV> as a separate CGI process). Add access to MySQL and you have a
MV> full-service application platform.
Er, C can be used within the context of the web server as well, and the
last time I looked, there were C libraries for MySQL.
Charlton
--
Charlton Wilbur
cwilbur@chromatico.net
------------------------------
Date: Tue, 30 Jun 2009 22:25:36 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Best way to do server side tasks with new ISP
Message-Id: <slrnh4kt61.mqq.hjp-usenet2@hrunkner.hjp.at>
On 2009-06-30 03:43, Jürgen Exner <jurgenex@hotmail.com> wrote:
> "Paul E. Schoen" <paul@peschoen.com> wrote:
>>That code looks rather intimidating, compared to
>>JavaScript.
How is that code "intimidating"? It's just a bunch of print statements
and a simple loop.
Assuming you had access to a directory, how would that code be simpler
in JavaScript?
> Well, what do you expect? The one is a simple DHTLM scripting language,
> the other is a fully-featured general purpose programming langauge.
JavaScript is a fully-featured general purpose programming language. In
fact, if you look at the standard, you won't find HTML mentioned at all,
except maybe in the preface. The DOM tree is just a data structure
provided by the environment, not something built into the language.
hp
------------------------------
Date: Tue, 30 Jun 2009 22:51:33 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Best way to do server side tasks with new ISP
Message-Id: <slrnh4kumm.mqq.hjp-usenet2@hrunkner.hjp.at>
On 2009-06-30 06:07, Paul E. Schoen <paul@peschoen.com> wrote:
> "Jürgen Exner" <jurgenex@hotmail.com> wrote in message
> news:4d2j45hrinb4es5bq0gilo75ujt36t7kju@4ax.com...
>> "Paul E. Schoen" <paul@peschoen.com> wrote:
>>>That code looks rather intimidating, compared to
>>>JavaScript.
>>
>> Well, what do you expect? The one is a simple DHTLM scripting language,
>> the other is a fully-featured general purpose programming langauge.
>
> Well, I am used to C and Pascal (Delphi), and a little bit of Visual Basic.
> I can do just about anything I need on my local machine with those
> languages.
[...]
> But mostly I can't understand why well-known languages such as C and
> Pascal, or even VB and .NET, are not used for CGI apps (although maybe
> they are),
They are. I wrote some web applications in C myself. But that was for an
embedded system where the whole system (kernel, web server, application,
and the data it processed) had to fit into a few MB of flash. It would
have been quite a lot faster to develop the thing in Perl, but there
simply wasn't space for a perl interpreter on the system (and using a
bigger flash would have cost a lot more than my few hundred hours of
work).
> and instead require rather arcane-seeming code such as Perl
> and PHP.
Mass hosters can only offer a few technologies, and they will offer what
their customers demand. Theses days this is usually PHP, plus a little
bit of Perl, Python and Ruby, at least on Linux hosts. On Windows hosts,
they may also offer VB and .NET, but I'm not a Windows guy so I wouldn't
know that.
If you want to write your web apps in C, it's probably best if you get a
virtual host (I've seen some offers for less than 10¤/month). Of course
then you wouldn't need to write a CGI app just to print a directory
listing because you can just configure your web server.
hp
------------------------------
Date: Tue, 30 Jun 2009 22:54:45 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Best way to do server side tasks with new ISP
Message-Id: <slrnh4kusl.mqq.hjp-usenet2@hrunkner.hjp.at>
On 2009-06-30 09:23, Gunnar Hjalmarsson <noreply@gunnar.cc> wrote:
> Directory listing is a web server thing in the first place. Assuming
> Apache, an .htaccess file with this content:
>
> Options +Indexes
>
> might do. If not, it ought to be possible to ask the web hosting
> provider to allow directory listing for a specific account, or for one
> or more specified directories.
The OP already wrote that he asked them and that it is *not* possible to
turn on directory listings and that they won't make an exception for
him.
hp
------------------------------
Date: Tue, 30 Jun 2009 21:54:02 GMT
From: "Paul E. Schoen" <paul@peschoen.com>
Subject: Re: Best way to do server side tasks with new ISP
Message-Id: <_Pv2m.84$P5.52@nwrddc02.gnilink.net>
"Peter J. Holzer" <hjp-usenet2@hjp.at> wrote in message
news:slrnh4kt61.mqq.hjp-usenet2@hrunkner.hjp.at...
> On 2009-06-30 03:43, Jürgen Exner <jurgenex@hotmail.com> wrote:
>> "Paul E. Schoen" <paul@peschoen.com> wrote:
>>>That code looks rather intimidating, compared to
>>>JavaScript.
>
> How is that code "intimidating"? It's just a bunch of print statements
> and a simple loop.
Well, it's probably just about learning the syntax:
my $cgi = CGI->new(); // I don't understand what this does, except
possibly assign string $cgi to something
opendir(my $dh, "."); // I assume $dh is a string containing the
directory in text form
for (readdir($dh)) { // So this apparently reads the string one line
at a time
print "<li><a href='", $cgi->escapeHTML($_), "'>",
$cgi->escapeHTML($_),
"</a></li>\n"; // I know this must create HTML code for
hyperlinks to the directory items
The single and double quotes and various other characters and symbols
probably make perfect sense to a Perl programmer, but they seem difficult
to read and understand.
>
> Assuming you had access to a directory, how would that code be simpler
> in JavaScript?
I'm not very fluent in JavaScript, but if I had access to an MSDOS command
shell I would just execute a
dir > dirfile.txt
and then I would just parse the filenames and add appropriate HTML to
prepend the URL of the directory to make them hyperlinks.
>> Well, what do you expect? The one is a simple DHTLM scripting language,
>> the other is a fully-featured general purpose programming langauge.
>
> JavaScript is a fully-featured general purpose programming language. In
> fact, if you look at the standard, you won't find HTML mentioned at all,
> except maybe in the preface. The DOM tree is just a data structure
> provided by the environment, not something built into the language.
I found JavaScript very limited when used in the context of the Windows
Script Host, as it is designed to run in the context of a browser and an
HTML document. It does have some file manipulation capability if you use an
ActiveX FileSystemObject, where you can create directories and text files
which can be written and read, and files can be copied from one place to
another. But a local machine is a much different environment than a web
server!
Thanks for your patience in helping me understand more about various
languages and their appropriateness to different environments. I don't
think I want to learn Perl for the limited use I will probably have for it.
I can see where it is a very powerful tool for text manipulation and
negotiating the environment of the web server and user interaction with an
HTML document, and gathering information. But it seems to be difficult to
follow because of its shorthand notation for complex tasks.
Paul
------------------------------
Date: Wed, 01 Jul 2009 00:13:16 +0200
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: Best way to do server side tasks with new ISP
Message-Id: <7avh0eF1vjdq2U1@mid.individual.net>
Peter J. Holzer wrote:
> On 2009-06-30 09:23, Gunnar Hjalmarsson <noreply@gunnar.cc> wrote:
>> Directory listing is a web server thing in the first place. Assuming
>> Apache, an .htaccess file with this content:
>>
>> Options +Indexes
>>
>> might do. If not, it ought to be possible to ask the web hosting
>> provider to allow directory listing for a specific account, or for one
>> or more specified directories.
>
> The OP already wrote that he asked them and that it is *not* possible to
> turn on directory listings and that they won't make an exception for
> him.
Even if that may be the case, it's not what he wrote. He said with
respect to his current provider that "viewing of the files in a
directory is forbidden", and that's what Apache tells you if directory
listing is not enabled.
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: Wed, 1 Jul 2009 00:03:29 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Best way to do server side tasks with new ISP
Message-Id: <17iqh6-6a01.ln1@osiris.mauzo.dyndns.org>
Quoth "Paul E. Schoen" <paul@peschoen.com>:
>
> Well, it's probably just about learning the syntax:
>
> my $cgi = CGI->new(); // I don't understand what this does, except
> possibly assign string $cgi to something
$cgi is a variable. Scalar (single-valued) variables in Perl always
begin with a '$'. 'my' declares a new lexically-scoped variable.
'CGI->new()' is a method call on the class 'CGI': '->' is the Perl
equivalent of '.' in JavaScript. A rough translation to JS might be
var cgi = CGI.new();
or
var cgi = new CGI ();
since JS has a special syntax for constructors (in Perl they are just
ordinary calss method calls). This isn't strictly accurate since JS has
weird scoping rules for 'var' variables.
Oh, and comments in Perl begin with '#', not '//'.
> opendir(my $dh, "."); // I assume $dh is a string containing the
> directory in text form
No, $dh holds a directory handle open on the directory. A dir handle is
like a file handle, but, err, different. (I've never understood why this
was a necessary distinction. The OS should just treat read(2) on a dir
as getdents(2), and Perl should treat <$DH> and readdir($DH).)
> for (readdir($dh)) { // So this apparently reads the string one line
> at a time
No, it reads all the entries from the dir handle into a list, then
iterates over the list. This is not the best way to write this: a while
loop
while ($_ = readdir($dh)) {
(with appropriate 'local $_', 'local *_' or 'my $_') will read the
entries one at a time and process each antry as it is read.
> print "<li><a href='", $cgi->escapeHTML($_), "'>",
> $cgi->escapeHTML($_),
> "</a></li>\n"; // I know this must create HTML code for
> hyperlinks to the directory items
>
> The single and double quotes and various other characters and symbols
> probably make perfect sense to a Perl programmer, but they seem difficult
> to read and understand.
Really? The '$cgi->escapeHTML()' bits are just method calls on the $cgi
object. $_ is a magic variable that is set by 'for' to the current item
in its list (this is really the only bit that is non-obvious). The
double-quotes understand \-escapes (just like in JS) and interpolate
variables. 'print' is a builtin that joins all its arguments together
and writes the result to the standard output. Equivalent JS might be
print("<li><a href='", cgi.escapeHTML(it), "'>",
cgi.escapeHTML(it), "</a></li>\n");
assuming a loop like
var entries = readdir(dh);
for (var i = 0; i < entries.length; i++) {
var it = entries[i];
(Notice how Perl makes the rather common operation of 'iterate over all
the entries in a list' much easier than JS does. JS 1.6 has
entries.forEach(function { print(...) });
but that isn't exactly pretty.)
> I'm not very fluent in JavaScript, but if I had access to an MSDOS command
> shell I would just execute a
>
> dir > dirfile.txt
>
> and then I would just parse the filenames and add appropriate HTML to
> prepend the URL of the directory to make them hyperlinks.
You can do that in Perl, if you like. It's not really a good idea,
especially since your webserver is probably Unix-based and doesn't have
a 'dir' command, but it's perfectly possible.
> Thanks for your patience in helping me understand more about various
> languages and their appropriateness to different environments. I don't
> think I want to learn Perl for the limited use I will probably have for it.
Oh, right. You could have said that first...
> I can see where it is a very powerful tool for text manipulation and
> negotiating the environment of the web server and user interaction with an
> HTML document, and gathering information. But it seems to be difficult to
> follow because of its shorthand notation for complex tasks.
Having simple notation for complex but common tasks actually makes
programs *easier* to read.
Ben
------------------------------
Date: Tue, 30 Jun 2009 18:29:51 -0500
From: Tad J McClellan <tadmc@seesig.invalid>
Subject: Re: Best way to do server side tasks with new ISP
Message-Id: <slrnh4l7p3.njc.tadmc@tadmc30.sbcglobal.net>
Paul E. Schoen <paul@peschoen.com> wrote:
>
> "Peter J. Holzer" <hjp-usenet2@hjp.at> wrote in message
> news:slrnh4kt61.mqq.hjp-usenet2@hrunkner.hjp.at...
>> On 2009-06-30 03:43, Jürgen Exner <jurgenex@hotmail.com> wrote:
>>> "Paul E. Schoen" <paul@peschoen.com> wrote:
>>>>That code looks rather intimidating, compared to
>>>>JavaScript.
>>
>> How is that code "intimidating"? It's just a bunch of print statements
>> and a simple loop.
>
> Well, it's probably just about learning the syntax:
>
> my $cgi = CGI->new(); // I don't understand what this does, except
> possibly assign string $cgi to something
There is no string there.
It is creating an object.
Are you familiar with object oriented programming?
> opendir(my $dh, "."); // I assume $dh is a string containing the
> directory in text form
The only string there is the one containing a dot.
$dh is a dirhandle, it is not a string.
Had you bothered to read the documentation for the function
being used, that should have been fairly obvious:
perldoc -f opendir
opendir DIRHANDLE,EXPR
> for (readdir($dh)) { // So this apparently reads the string one line
> at a time
Finally, a statement that _does_ have a string associated with it.
Besides what you have in your (non-Perl) comment, it also assigns
that string to the $_ variable.
> print "<li><a href='", $cgi->escapeHTML($_), "'>",
> $cgi->escapeHTML($_),
> "</a></li>\n"; // I know this must create HTML code for
> hyperlinks to the directory items
Along with some method calls on the CGI object.
> The single and double quotes and various other characters and symbols
> probably make perfect sense to a Perl programmer, but they seem difficult
> to read and understand.
The funny characters in the Cyrillic alphabet probably make perfect
sense to a Russian speaker, but they seem difficult to read and
understand.
Well duh, foreign languages seem, well, foreign (until you learn them).
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"
------------------------------
Date: Wed, 1 Jul 2009 01:47:47 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Best way to do server side tasks with new ISP
Message-Id: <slrnh4l913.p3q.hjp-usenet2@hrunkner.hjp.at>
On 2009-06-30 22:13, Gunnar Hjalmarsson <noreply@gunnar.cc> wrote:
> Peter J. Holzer wrote:
>> The OP already wrote that he asked them and that it is *not* possible to
>> turn on directory listings and that they won't make an exception for
>> him.
>
> Even if that may be the case, it's not what he wrote. He said with
> respect to his current provider that "viewing of the files in a
> directory is forbidden", and that's what Apache tells you if directory
> listing is not enabled.
To quote from the first posting in this thread:
| they say they have a full line of tools like a hit counter and they
| allow CGI-BIN, but they have permanantly disabled directory listing of
| files.
hp
------------------------------
Date: Wed, 01 Jul 2009 03:03:24 GMT
From: "Paul E. Schoen" <paul@peschoen.com>
Subject: Re: Best way to do server side tasks with new ISP
Message-Id: <0mA2m.1871$9l4.368@nwrddc01.gnilink.net>
"Peter J. Holzer" <hjp-usenet2@hjp.at> wrote in message
news:slrnh4l913.p3q.hjp-usenet2@hrunkner.hjp.at...
> On 2009-06-30 22:13, Gunnar Hjalmarsson <noreply@gunnar.cc> wrote:
>> Peter J. Holzer wrote:
>>> The OP already wrote that he asked them and that it is *not* possible
>>> to
>>> turn on directory listings and that they won't make an exception for
>>> him.
>>
>> Even if that may be the case, it's not what he wrote. He said with
>> respect to his current provider that "viewing of the files in a
>> directory is forbidden", and that's what Apache tells you if directory
>> listing is not enabled.
>
>
> To quote from the first posting in this thread:
>
> | they say they have a full line of tools like a hit counter and they
> | allow CGI-BIN, but they have permanantly disabled directory listing of
> | files.
Actually my current dialup ISP allows CGI and shows a directory when there
is no index. But my new high speed ISP, verizon.net, apparently does not
allow either, and their hit counter is broken. I get 10 M free, but I would
like a little more. So I am really just shopping for webspace, and perhaps
there are providers that will give me what I want for a reasonable amount,
like $5/mo for 100 M or so.
Thanks for the interesting discussion.
Paul
------------------------------
Date: Tue, 30 Jun 2009 23:20:36 -0400
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: Best way to do server side tasks with new ISP
Message-Id: <871vp1m6m3.fsf@quad.sysarch.com>
>>>>> "PES" == Paul E Schoen <paul@peschoen.com> writes:
PES> Actually my current dialup ISP allows CGI and shows a directory
PES> when there is no index. But my new high speed ISP, verizon.net,
PES> apparently does not allow either, and their hit counter is
PES> broken. I get 10 M free, but I would like a little more. So I am
PES> really just shopping for webspace, and perhaps there are
PES> providers that will give me what I want for a reasonable amount,
PES> like $5/mo for 100 M or so.
jeez, do you know how many web hosters there are out there? and that you
can get decent deals for $5 or more a month? using your isp for a web
host is usually a poor idea and even worse using them for the email
domain. since you seem to have your own domain why don't you move it to
a hoster that has what you want. most have large checklists of features
for each plan they offer so it would be easy to find one that matches
your needs.
uri
--
Uri Guttman ------ uri@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 ---------
------------------------------
Date: Wed, 01 Jul 2009 08:57:55 +0200
From: Mart van de Wege <mvdwege@mail.com>
Subject: Re: Best way to do server side tasks with new ISP
Message-Id: <864otw7uvg.fsf@gareth.avalon.lan>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth "Paul E. Schoen" <paul@peschoen.com>:
>
> (Notice how Perl makes the rather common operation of 'iterate over all
> the entries in a list' much easier than JS does. JS 1.6 has
>
> entries.forEach(function { print(...) });
>
> but that isn't exactly pretty.)
>
Erm.
JavaScript 1.5 *does* have the equivalent construct:
'for (var in list)'.
Mart
--
"We will need a longer wall when the revolution comes."
--- AJS, quoting an uncertain source.
------------------------------
Date: Wed, 01 Jul 2009 11:49:32 -0400
From: Charlton Wilbur <cwilbur@chromatico.net>
Subject: Re: Best way to do server side tasks with new ISP
Message-Id: <86fxdg8ktv.fsf@mithril.chromatico.net>
PES> "Peter J. Holzer" <hjp-usenet2@hjp.at> wrote in message
PES> news:slrnh4kt61.mqq.hjp-usenet2@hrunkner.hjp.at...
>> How is that code "intimidating"? It's just a bunch of print
>> statements and a simple loop.
PES> Well, it's probably just about learning the syntax:
It *is* just about learning the syntax. Well, and the semantics.
Perl is not Javascript, C, VB, or Pascal. You need to get your head
around that concept first. You can use what you know of other languages
to help you get a handle on Perl, but the sooner you accept Perl for
what it is, and stop trying to understand it as if it were some other
language with lots of errors, the sooner you'll start making progress.
PES> The single and double quotes and various other characters and
PES> symbols probably make perfect sense to a Perl programmer, but
PES> they seem difficult to read and understand.
Fortunately, there are plenty of resources to help you learn to read and
understand them.
All languages have learning curves. Why did you accept C and Pascal's,
but balk at Perl's?
Charlton
--
Charlton Wilbur
cwilbur@chromatico.net
------------------------------
Date: Wed, 01 Jul 2009 08:57:25 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Best way to do server side tasks with new ISP
Message-Id: <rk1n4510vesltitlseveiliiejmuhs9ja7@4ax.com>
Charlton Wilbur <cwilbur@chromatico.net> wrote:
> PES> The single and double quotes and various other characters and
> PES> symbols probably make perfect sense to a Perl programmer, but
> PES> they seem difficult to read and understand.
>
>All languages have learning curves. Why did you accept C and Pascal's,
>but balk at Perl's?
Well, VB, Pascal, C, they are all the same anyway.
Try Lisp, Prolog, and APL. After you got familiar with those Perl will
feel like a vacation on a tropical island with a light breeze and a pina
colada in your hands.
jue
------------------------------
Date: Wed, 1 Jul 2009 09:37:50 -0700 (PDT)
From: ccc31807 <cartercc@gmail.com>
Subject: Re: Best way to do server side tasks with new ISP
Message-Id: <77d0a8a7-62b0-437f-a30c-7f4c328e4ecd@r10g2000yqa.googlegroups.com>
On Jun 28, 9:05=A0pm, "Paul E. Schoen" <p...@peschoen.com> wrote:
> And I would also like to be able to implement a simple form that would ha=
ve
> its results emailed to me, which of course is a common task, but I assume=
I
> would need a CGI application to do that.
>
> Thanks for any advice you may be able to provide.
Please permit me to make a couple of late comments.
I am a heavy user of Perl in my job, which is mostly slicing and
dicing data. Perl is a special purpose tool which is exceptionally
good at its intended purpose: string handling. As most web apps are
applications of handling strings, Perl is exceptionally good at
writing web apps. It's also very good at database and networking
applications ... but don't think that Perl is a good general purpose
language, because it wasn't designed to be.
I'll be glad to share code with you privately if you will email me at /
c c c 3 1 8 0 7 at y a h o o dot c o m/. About 90 percent of the code
will be instantly recognizable to you as HTML, CSS, or JavaScript. The
other ten percent will probably strike you as obfuscated and obscure
Perl, but hey, Perl by nature is obfuscated and obscure, which is why
it's good at what it does.
CC
------------------------------
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 2495
***************************************
