Re: Need help with a simple (I think) Perl script

Bill H <bill@xxxxxxxxx> wrote in
news:bec27717-a518-4a63-8270-851ee9ef780d@xxxxxxxxxxxxxxxxxxxxxxxxxxx:

On May 29, 5:50 pm, Ben Bullock <benkasminbull...@xxxxxxxxx> 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?

Sinan

--
A. Sinan Unur <1usa@xxxxxxxxxxxxxxxxxxx>
(remove .invalid and reverse each component for email address)

comp.lang.perl.misc guidelines on the WWW:
http://www.rehabitation.com/clpmisc/
.

Quantcast