[32577] in Perl-Users-Digest
Perl-Users Digest, Issue: 3849 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Jan 1 09:09:18 2013
Date: Tue, 1 Jan 2013 06:09:05 -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 Tue, 1 Jan 2013 Volume: 11 Number: 3849
Today's topics:
Re: CGI Question <edgrsprj@ix.netcom.com>
Re: CGI Question <hjp-usenet2@hjp.at>
Re: CGI Question <rweikusat@mssgmbh.com>
Re: CGI Question <cwilbur@chromatico.net>
Re: CGI Question <sbryce@scottbryce.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 31 Dec 2012 06:47:30 -0600
From: "E.D.G." <edgrsprj@ix.netcom.com>
Subject: Re: CGI Question
Message-Id: <sPCdnc_4SYP_FHzNnZ2dnUVZ_qidnZ2d@earthlink.com>
"E.D.G." <edgrsprj@ix.netcom.com> wrote in message
news:zN6dneyLzP8dvULNnZ2dnUVZ_radnZ2d@earthlink.com...
Posted by E.D.G. on December 31, 2012
This post is a continuation of a CGI programming discussion that I
started on the Perl Newsgroup a few days ago.
- The first part of this post has to do with Internet Server CGI
programs that can create picture files such as PNG files.
- The second part of this post is a somewhat philosophical computer
programming discussion that is intended for the people who are developing
the Perl and Gnuplot languages.
At the moment I am using ActiveState Perl (both older and newer
versions), an older version of Gnuplot, and Xampp on my Windows XP and Vista
PCs. And I can create and run Perl language CGI programs on my Internet
Server.
On my PC, Perl sends Gnuplot plot information through files, and
command information through Windows pipes. Those pipes don't appear to be
very good for sharing large blocks of plotting data. Things tend to get
lost. But they are great for sending relatively small numbers of commands
to Gnuplot.
CGI PICTURE FILE QUESTIONS
After preparing for this for quite a few years I am now finally
starting to create Perl programs for use as CGI programs that will run at my
Web sites. The first one that should be running within a few days will be a
relatively simple variation of Matt Wright's Perl language WWWBoard program.
It was selected largely because I was able to get it to run with the Xampp
computer program that makes it possible for a Windows PC to look like an
Internet Server and respond when an html file SUBMIT button is pressed for
example.
Question: What graphics program will work with Perl on an Internet Server
computer and allow Perl to draw picture files such as charts with a PNG
extension and store them at the site?
If Gnuplot will run on an Internet Server and work with Perl then
that might take care of the matter. However, after visiting some Web sites
and doing some reading on the subject I was not able to determine if this is
actually possible.
Question: If Gnuplot can be used for Internet Server applications, then can
anyone point to a Web site where a discussion of that subject can be found
that would be understandable to an intermediate level programmer?
Question: If Gnuplot is not recommended for use with Perl for Internet
Server CGI file work, then what graphics program should be used?
The following is an indirect URL for the type of picture file work
that is planned. And I am not sending people to that Freewebs site to get
points. Indirect addresses like that are being used in part in the hopes of
keeping as much spam mail etc. as possible away from E-mail addresses listed
on my actual science research Web sites.
http://www.freewebs.com/eq-forecasting/Demo-Program.html
PHILOSOPHICAL PROGRAMMING DISCUSSION FOR PERL AND GNUPLOT DEVELOPERS
This first part of the following discussion is intended to be
humorous, not some type of scientific fact. It has been my experience that
if that humor statement is not added, some people who might be speaking
English as a second or third language could get confused.
When the Great Rain finally ended and his Arc neared land, Noah
assembled all of the Arc animals on the top deck and said to them,
"Evolve or Perish!"
Unfortunately, the dinosaurs had been out partying the night before.
They missed the lecture. And now they can be found only in Natural History
museums and paleontological digs.
Some time ago ago I asked the ActiveState people if they would be
interested in developing a version of Gnuplot that could be used as a
downloadable module for Perl and enable Perl programs to use the
sophisticated Gnuplot chart drawing resources.
If I remember correctly, they stated that they would rather focus on
developing chart creation resources for their downloadable version of
Python.
What I have recommended in my posts in the past is that some
combination of Perl and Gnuplot language development personnel create a
module version of Gnuplot that can be downloaded and used with Perl. It is
my understanding that they are both written using one of the C languages.
So such a module development effort shouldn't be too difficult. And Gnuplot
commands in the Perl programs could begin with "gnu" as in "gnuprint" to
keep them from conflicting with similar Perl commands.
There are modules that make it possible for Perl programs to interact
with Gnuplot. But from what I have seen, data still need to be sent to
Gnuplot through files or some type of "pipe." And I am not sure if this
would work on an Internet Server computer.
Some of the advantages of having a Perl module version of Gnuplot
might be the following:
- This could greatly enhance Perl's chart drawing capabilities.
- It could greatly enhance Gnuplot's array manipulation and perhaps
its string manipulation capabilities.
- Both Perl and Gnuplot would become more attractive to prospective
users because of their increased power. And they would both become less
likely to eventually join the dinosaurs in some museum.
Happy Holiday Season to all,
E.D.G.
------------------------------
Date: Mon, 31 Dec 2012 14:56:38 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: CGI Question
Message-Id: <slrnke36cn.7u1.hjp-usenet2@hrunkner.hjp.at>
On 2012-12-30 04:43, ccc31807 <cartercc@gmail.com> wrote:
> On Saturday, December 29, 2012 4:47:36 PM UTC-5, Peter J. Holzer wrote:
>> > I don't like that at all. If you use CGI, you shouldn't have any HTML
>> > files -- all your HTML content should be generated by your CGI
>> > scripts.
>>
>> Why?
>
> There are probably more than four approaches to creating HTML, but I'll only mention four.
[...]
> In short, I like the idea of building a factory to spit out HTML
> rather than handcrafting each HTML page individually.
I don't think you answered the question: Why should all HTML content be
generated by CGI IF there is one CGI script on the site?
Suppose I have a website with 100 static HTML pages. Every now and then
I add a new static page. Now, for some reason, I want to add some
content which cannot be represented in a static page, so I add a CGI
script. Why should I convert my 100 static pages to CGI at this point?
Or a more complex example: I have a web site with a few dozen GB of
static content, a Java-based CMS and web shop and a CGI based database
interface. Why should that not be allowed? What do I gain by putting the
static content behind a CGI script? Or, even worse,
There are reasons why it may be useful to keep static content in a
different form (database, files in XML or Wiki syntax, ...) and generate
the final HTML on the fly (e.g. consistent layout, more flexible, reuse
of content, ...). But none of these has anything to with whether some
other content on the site is generated with CGI.
hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | Sysadmin WSR | Man feilt solange an seinen Text um, bis
| | | hjp@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
------------------------------
Date: Mon, 31 Dec 2012 13:57:04 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: CGI Question
Message-Id: <87vcbis4sv.fsf@sapphire.mobileactivedefense.com>
"E.D.G." <edgrsprj@ix.netcom.com> writes:
> "Charlton Wilbur" <cwilbur@chromatico.net> wrote in message
> news:87ip7i3hf8.fsf@new.chromatico.net...
>> Perhaps I misspoke: you will produce better results with less effort and
>> with less outside support required if you install one of the decent
>> freely-available open-source bulletin boards that has seen ongoing
>> development in the past year.
>
> Again, thanks for the comment.
>
> I fully agree that there are numerous sophisticated bulletin boards
> programs available. But I wanted a Perl language bulletin board
> program to get started with that will work with the Xampp CGI program
> development program so that highly specialized features could be
> added. And WWWBoard is a relatively simple Perl program.
After a (cursory) look at the code, I have to agree with Charton
Wilbur that I certainly wouldn't want to use this as base for any
development of my own and surely wouldn't recommend it to others. That
subroutines are consistently invoked as &name(a, b, c) can be regarded
as relatively harmless archaism, although including the & despite it
performs no useful function whatsoever is something I consider to be
poor style (basically, this is just white noise and makes the code
harder to read and understand because of that). A much more serious
problem is that this code doesn't declare any variables so the only
way to determine which variables are being used where is to read
through the code. It also rarely uses local which means that all
'script variables' are visible and modifiable from any
subroutine. Consequently, adding a new variable or changing the way an
existing one is used requires being aware of all of 'the global
context' to avoid using identifiers already used by other code or
using such identifiers in a way which conflicts with their use by
other code. Considering that this is really a 'tinygram' (461 LOC),
the statement 'The current release in 2.0 ALPHA 2.1, which means there
still are a few bugs.' is quite telling in this context: It implies
that the author has already lost this 'global understanding' and that
parts of the code already conflict with other parts of the code
because of that, a totally self-inflicted wound. Lastly, there's too
much "copy'n'paste" coding in there, as shown by statement blocks a la
print "<input type=hidden name=\"origsubject\" value=\"$FORM{'origsubject'}\">\n";
print "<input type=hidden name=\"origname\" value=\"$FORM{'origname'}\">\n";
print "<input type=hidden name=\"origemail\" value=\"$FORM{'origemail'}\">\n";
print "<input type=hidden name=\"origdate\" value=\"$FORM{'origdate'}\">\n";
print "<input type=hidden name=\"followup\" value=\"$FORM{'followup'}\">\n";
Code of this kind makes it extremly difficult to modify the created
HTML, except 'adding more of the same', and is also needlessly
complicated to understand. This (with no regard for other parts of the
script) should really rather be something like this (untested)
sub hidden
{
return sprintf('<input type=hidden name="%s" value="%s">',
$_[0], $FORM{$_[0]});
}
print(hidden($_), "\n") for qw(origsubject origname origdate followup);
------------------------------
Date: Mon, 31 Dec 2012 11:08:01 -0500
From: Charlton Wilbur <cwilbur@chromatico.net>
Subject: Re: CGI Question
Message-Id: <87ehi62oim.fsf@new.chromatico.net>
>>>>> "EDG" == E D G <edgrsprj@ix.netcom.com> writes:
EDG> And WWWBoard is a relatively simple Perl program.
More to the point: it is badly written, riddled with security holes, and
has been disclaimed and abandoned by its original author.
You have made a decision that, on the spectrum between 'foolish' and
'idiotic', is far closer to the latter end. It *will* come back to bite
you in the fundament, and it will probably bite several thousand other
people as well when your site is compromised and used as a spam and
malware relay host.
Charlton
--
Charlton Wilbur
cwilbur@chromatico.net
------------------------------
Date: Mon, 31 Dec 2012 14:34:28 -0700
From: Scott Bryce <sbryce@scottbryce.com>
Subject: Re: CGI Question
Message-Id: <kbt0dl$pq3$1@dont-email.me>
This is a little OT here, but since you haven't had a good answer to
your question....
On 12/29/2012 9:55 AM, E.D.G. wrote:
> What permissions should the password and Perl language files have?
Perl script: 755. Password file: I believe 666 will work.
But more important than that...
> Also in that directory will be the password file that will have a
> .txt extension.
Don't do that. Move the password file to a directory above the document
root where it cannot be accessed via the internet. (The passwords are
encrypted, aren't they?)
------------------------------
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:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#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 3849
***************************************
