Bareword errors?

[Gunnar Hjalmarsson]

if (!HASH{search2}) { -------^

$search = "search1 only";
}
if (!HASH{search1} && !HASH{search2}){

-------^

Something is missing there...

 

[gcr]

Thanks for any opinions / advice / explanations / flames;

Short version -
getting an inconsistant (?) bareword error
strict accepts the first use of the bareword(?) but not later -
(not under strict one runs - the other gives error.

Long version:
how come the first bareword at line 15 passes? - right under getweb()

---snip
Bareword "search2" not allowed while "strict subs" in use at ./s1why.cgi
line 19.
Bareword "search1" not allowed while "strict subs" in use at ./s1why.cgi
line 22.
Bareword "search2" not allowed while "strict subs" in use at ./s1why.cgi
line 22.
----snip
when 'strict' isn't used:
----snip
Can't locate object method "HASH" via package "search2" (perhaps you
forgot to load "search2"?) at ./s1why.cgi line 19.

I'll hack around this but curious why first use passes.
This is perl, v5.8.1-RC3 built for darwin-thread-multi-2level
os x 10.3.9



-----snip -----

#!/usr/bin/perl

use strict;

my $search;
my %HASH;
my $name;
my $value;
my @pairs;
my $buffer;
my $pair;

getweb();

if (!$HASH{search1}) {
$search = "search2 only";
}

if (!HASH{search2}) {
$search = "search1 only";
}
if (!HASH{search1} && !HASH{search2}){
$search = "no search";
}

sub getweb() {
if ($ENV{'REQUEST_METHOD'} eq 'GET')
{
@pairs = split(/&/, $ENV{'QUERY_STRING'});
}
elsif ($ENV{'REQUEST_METHOD'} eq 'POST')
{
read(STDIN, $buffer, $ENV{'CONTENT_LENGTH'});
@pairs = split(/&/, $buffer);
}

foreach $pair (@pairs)
{
($name, $value) = split(/=/, $pair);
$name =~ tr/+/ /;
$name =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;

$value =~ tr/+/ /;
$value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;

$value =~ s/<!--(.|\n)*-->//g;
$HASH{$name} = $value;
}
}

 

[gcr]

-------^

Something is missing there...

Ouch!! My bad - no sleep. Thanks and sorry for stupid question.

 

[gcr]

Ouch! My Bad. Sorry, no sleep.

Side point - I've been burned a few times by cgi.pm so I gave up on it -
I didn't reinvent this wheel, though, I got it from someone and have
been using it for a while.

Sorry for the stupid question.

 

[gcr]

If you get "burned" by something that literally *thousands* of other people
are using successfully, giving up and blaming the module is just silly.

Line breaks - cgi.pm was inconsistent. This is a while back, may have
been fixed by now or maybe I didn't get it back then. There were also
big back and forths on the newsgroup by those more knowledgable than I
(that would be everyone) about the pluses and minuses of cgi.pm. I
haven't been burned *yet* by using the regexes and it's been in pretty
constant use for a while. I like to be able to control what is being
decoded for various reasons which I wasn't able to figure out in cgi.pm.
I've also fixed other peoples broken cgi's (again, linebreak issues) by
taking cgi.pm out and using regexes. YMMV.

So? It's still awful code, regardless of how long you've been using it. It
uses global variables, for pity's sake.

I added strict when posting to the NG and defined the variables on the
fly at the head for the example. The main HASH{} could be named WEB{} I
guess but I'm the only maintainer so it hasn't bothered me.

You're claiming that the standard
module is somehow inferior,

Not at all. *I* couldn't make it work, fault probably lies here. The
other code worked and hasn't broken yet. I moved on.

when the author of the code you're using now
doesn't even know how to return a value from a subroutine?

Unclear what you mean - again purely my ignorance. Like I said, this
code has run in various places for a while with no problems (besides
sheer idiocy like my parent posting which wasn't the code but PEBKAC)

Thanks for getting, anyways.

 

[Tad McClellan]

Line breaks - cgi.pm was inconsistent.

Line breaks don't generally matter in the output of a CGI program (HTML).

 

[Gunnar Hjalmarsson]

So? It's still awful code, regardless of how long you've been using it. It
uses global variables, for pity's sake. You're claiming that the standard
module is somehow inferior,

As you well know, it _is_ inferior in one way: efficiency. Personally I
often use it because it's convenient, but in situations when efficiency
matters I don't. I have never understood why some regulars here get so
upset as soon as they see a piece of trivial CGI parsing code.

when the author of the code you're using now
doesn't even know how to return a value from a subroutine?

So, let's improve it a little:

my %HASH = getcgi();

sub getcgi {
my ($buffer, %params);
if ( $ENV{REQUEST_METHOD} eq 'POST' ) {
my $len = $ENV{CONTENT_LENGTH};
$len <= 131072 or die "Too much data submitted.\n";
binmode STDIN;
read( STDIN, $buffer, $len ) == $len
or die "Reading of posted data failed.\n";
} else {
$buffer = $ENV{QUERY_STRING};
}
$buffer =~ tr/+/ /;
for ( split /[&;]/, $buffer ) {
my ($name, $value) =
map { s/%(..)/chr(hex $1)/eg; $_ } split /=/, $_, 2;
$params{$name} = $value;
}
wantarray ? %params : \%params;
}

As regards the line

$value =~ s/<!--(.|\n)*-->//g;

in the OP's code, it's probably there to take care of <!--exec ... -->
constructs. Personally I always let user input pass this (or some
similar) function:

sub entify {
my $ref = defined wantarray ? [ @_ ] : \@_;
my %ent = ('&'=>'amp', '"'=>'quot', '<'=>'lt', '>'=>'gt');
s/([&"<>])/&$ent{$1};/g for grep defined, @$ref;
if ( defined wantarray ) {
@$ref > 1 ? @$ref : $$ref[0];
}
}

before it's presented in an HTML context. That takes care also of the
<!--exec ... --> issue.

 

[Tad McClellan]

. I have never understood why some regulars here get so
upset as soon as they see a piece of trivial CGI parsing code.

Then you probably were not here when 20% of all posts here got
it "trivially" wrong (mid '90's).

Since it is not in your experience, you will never understand,
so can you quit harping on it?

 

[Ben Morrow]

As you well know, it _is_ inferior in one way: efficiency. Personally I
often use it because it's convenient, but in situations when efficiency
matters I don't. I have never understood why some regulars here get so
upset as soon as they see a piece of trivial CGI parsing code.

Because parsing CGI isn't as trivial as people think, and rewriting
rather than reusing even a fairly simple piece of code is a very bad
programming practice. If you can do it *correctly* more efficiently than
CGI.pm can, then by all means please release your code as
CGI::VeryEfficient or something, and then the rest of us can get the
benefit as well.

Personally, for the tiny amount of CGI stuff I've done I used CGI::Lite,
simply because the size of CGI.pm's perldoc daunted me somewhat; but
rewriting it for every CGI script is just daft.

Ben

 

[Gunnar Hjalmarsson]

Then you probably were not here when 20% of all posts here got
it "trivially" wrong (mid '90's).

Right, I wasn't.

Mid 90's. Ten years. Maybe it's time to relax?

Since it is not in your experience, you will never understand,

Probably not. Which is true also for other relative newcomers who are
picked on. While the tone occationally used, when commenting on this
matter here, serves no useful purpose, I'm convinced it unnecessarily
scares away a few.

so can you quit harping on it?

I will, when the tone gets more sober.

But hey, things have improved. A couple of years ago, when someone
revealed that they were using their own code for parsing CGI, about 10
regulars told that person that s/he was stupid. Nowadays only one or two
regulars do the same thing. ;-)

 

[Charlton Wilbur]

SP> I highly doubt that.

She whom I am not going to name - but she misspelled both Perl and
Girl in her nom de net - delivered frequent tirades about how useless
CGI.pm was. This might easily have been mistaken for a "big back and
forth" with significant support on both sides, especially as there
were more reasonable people who stepped forth with more nuanced
opinions about various parts of the CGI.pm module.

Charlton

 

[Charlton Wilbur]

GH> I have never understood why some regulars here get so upset as
GH> soon as they see a piece of trivial CGI parsing code.

Because CGI parsing is not trivial. It's the same reaction I have to
parsing HTML or XML with a complicated regular expression, or using
regular expressions for arithmetic: the fact that someone's trying it
seriously in the first place shows that they don't understand the
problem or the tool.

It's not a matter of being upset. It's a reaction to someone doing
something that is, in the vast majority of scenarios, somewhere
between misguided and idiotic; and in those scenarios where it isn't
counterproductive, there are other solutions with a much better return
on the investment of time.

Charlton

 

[Tad McClellan]

But hey, things have improved. A couple of years ago, when someone
revealed that they were using their own code for parsing CGI, about 10
regulars told that person that s/he was stupid. Nowadays only one or two
regulars do the same thing. ;-)

Because there are now eight less regulars!

 

[Charlton Wilbur]

TMcC> Because there are now eight less regulars!

Eight fewer *knowledgeable* regulars, surely.

Charlton

 

[John W. Krahn]

Because there are now eight less regulars!

Probably up north helping Santa this time of the year.



John

 

[Tad McClellan]

TMcC> Because there are now eight less regulars!

Eight fewer *knowledgeable* regulars, surely.

Or eight fewer *curmudgeonly* regulars, frankly.

 

[Tad McClellan]

Probably up north helping Santa this time of the year.

Well that's where the nice ones probably are.

The naughty ones are probably still here though...

 

[Gunnar Hjalmarsson]

If you can do it *correctly* more efficiently than CGI.pm can,

Of course I can; just did.
http://groups.google.com/group/comp.lang.perl.misc/msg/827b6bb5568885f3

I.e. it does *correctly* what it's supposed to do. (It's not supposed to
handle e.g. multivalue fields or file uploads.)

then by all means please release your code as CGI::VeryEfficient or
something, and then the rest of us can get the benefit as well.

Since there already are alternative CGI parsing modules, there is no
need to release another one. If one of them was included in the standard
Perl distro, people might be more inclined to use it. I know I would.

 

[Ben Morrow]

Of course I can; just did.
http://groups.google.com/group/comp.lang.perl.misc/msg/827b6bb5568885f3

I.e. it does *correctly* what it's supposed to do. (It's not supposed to
handle e.g. multivalue fields or file uploads.)

I'm not really competent to judge whether it's correct, not having read
the CGI spec recently; as for 'more efficient', did you benchmark it?
Can we see the results?

Since there already are alternative CGI parsing modules, there is no
need to release another one.

Then might I respectfully suggest that you point people at one of those,
instead of encouraging them to cargo-cult CGI-parsing code that a lot of
the time is either incorrect or not properly understood? It's hard
enough to get beginning programmers to understand the value of
modularity and code reuse as it is, without a whole lot of (almost
certainly spurious) argument about the efficiency or otherwise of
CGI.pm.

If one of them was included in the standard Perl distro, people might
be more inclined to use it. I know I would.

With pure-perl module such as we are talking it really doesn't matter if
it's in the perl core or not. It's trivial to install the module by hand
and point perl at it in even the most restricted of hosting
environments. XS modules are another matter, of course.

Ben

 

[Gunnar Hjalmarsson]

Quoth Gunnar Hjalmarsson:

I'm not really competent to judge whether it's correct, not having read
the CGI spec recently; as for 'more efficient', did you benchmark it?

Yes, several years ago.

Can we see the results?
Sure.
http://groups.google.com/group/comp.lang.perl.misc/msg/d922a0fabe3ce436


Then might I respectfully suggest that you point people at one of those,
instead of encouraging them to cargo-cult CGI-parsing code that a lot of
the time is either incorrect or not properly understood? It's hard
enough to get beginning programmers to understand the value of
modularity and code reuse as it is, without a whole lot of (almost
certainly spurious) argument about the efficiency or otherwise of
CGI.pm.

Spurious? BS! By making such a claim, without presenting any proofs,
your credibility is eroded.

If this _really_ was about the value of code reuse via modules, why does
nobody object to e.g. this message:
http://groups.google.com/group/comp.lang.perl.misc/msg/1b4d3a3b268bf35c

No, because people know and enjoy that TIMTOWTDI. But that philosophy
seems to not be applicable to the sacred cow CGI.pm. For some reason.
Understood only by those who were here 10 years ago.