COMPGROUPS.NET | Search | Post Question | Groups | Stream | About | Register

Bareword errors?

• Email
• Follow

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; } }   0 Reply gcr 11/28/2006 7:45:51 PM See related articles to this posting gcr wrote: > if (!HASH{search2}) { -------^ >$search = "search1 only";
> }
> if (!HASH{search1} && !HASH{search2}){
-------^

Something is missing there...

--
Email: http://www.gunnar.cc/cgi-bin/contact.pl

 0

gcr <reviewyourdemo@hotmail.com> writes:

> I'll hack around this but curious why first use passes.

The first use passes because it doesn't have the same error.

> -----snip -----
>
> #!/usr/bin/perl
>
> use strict;

use warnings;
use CGI;
use CGI::Carp qw(fatalsToBrowser);

> my $search; > my %HASH; > my$name;
> my $value; > my @pairs; > my$buffer;
> my $pair; > > getweb(); Why are you reinventing that wheel? Have a look at the CGI module - it's the standard for a reason. (If you're using a book that told you to do that, take that book back for a refund, and buy one whose author actually knows what he or she is talking about.) Also, why are you using global variables for everything, and giving them nonsensical names like %HASH? Those are bad habits in *any* language. > if (!$HASH{search1}) {
> $search = "search2 only"; > } > > if (!HASH{search2}) { ^$HASH

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

sherm--

--
Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net

 0

In article <4t3hedF121424U1@mid.individual.net>,

> gcr wrote:
> > if (!HASH{search2}) {
> -------^
>
> > $search = "search1 only"; > > } > > if (!HASH{search1} && !HASH{search2}){ > -------^ > > Something is missing there... Ouch!! My bad - no sleep. Thanks and sorry for stupid question.   0 Reply gcr 11/28/2006 9:18:16 PM In article <m264czmjxe.fsf@Sherm-Pendleys-Computer.local>, Sherm Pendley <spamtrap@dot-app.org> wrote: 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 <reviewyourdemo@hotmail.com> writes: > > > I'll hack around this but curious why first use passes. > > The first use passes because it doesn't have the same error. > > > -----snip ----- > > > > #!/usr/bin/perl > > > > use strict; > > use warnings; > use CGI; > use CGI::Carp qw(fatalsToBrowser); > > > my$search;
> > my %HASH;
> > my $name; > > my$value;
> > my @pairs;
> > my $buffer; > > my$pair;
> >
> > getweb();
>
> Why are you reinventing that wheel? Have a look at the CGI module - it's
> the standard for a reason. (If you're using a book that told you to do
> that, take that book back for a refund, and buy one whose author actually
> knows what he or she is talking about.)
>
> Also, why are you using global variables for everything, and giving them
> nonsensical names like %HASH? Those are bad habits in *any* language.
>
> > if (!$HASH{search1}) { > >$search = "search2 only";
> > }
> >
> > if (!HASH{search2}) {
>        ^
>        $HASH > > >$search = "search1 only";
> > }
> > if (!HASH{search1} && !HASH{search2}){
>        ^                 ^
>        $HASH$HASH
>
> > $search = "no search"; > > } > > sherm--   0 Reply gcr 11/28/2006 9:20:46 PM gcr <reviewyourdemo@hotmail.com> writes: > Side point - I've been burned a few times by cgi.pm so I gave up on it If you get "burned" by something that literally *thousands* of other people are using successfully, giving up and blaming the module is just silly. > I didn't reinvent this wheel, though, I got it from someone and have > been using it for a while. 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, when the author of the code you're using now doesn't even know how to return a value from a subroutine? sherm-- -- Web Hosting by West Virginians, for West Virginians: http://wv-www.net Cocoa programming in Perl: http://camelbones.sourceforge.net   0 Reply Sherm 11/28/2006 10:23:07 PM In article <m21wnnmcs4.fsf@Sherm-Pendleys-Computer.local>, Sherm Pendley <spamtrap@dot-app.org> wrote: > gcr <reviewyourdemo@hotmail.com> writes: > > > Side point - I've been burned a few times by cgi.pm so I gave up on it > > 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.   0 Reply gcr 11/29/2006 12:23:19 AM gcr <reviewyourdemo@hotmail.com> wrote: > In article <m21wnnmcs4.fsf@Sherm-Pendleys-Computer.local>, > Sherm Pendley <spamtrap@dot-app.org> wrote: > >> gcr <reviewyourdemo@hotmail.com> writes: >> >> > Side point - I've been burned a few times by cgi.pm so I gave up on it >> >> 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. Line breaks don't generally matter in the output of a CGI program (HTML). -- Tad McClellan SGML consulting tadmc@augustmail.com Perl programming Fort Worth, Texas   0 Reply Tad 11/29/2006 1:49:58 AM Sherm Pendley wrote: > gcr writes: >>I didn't reinvent this wheel, though, I got it from someone and have >>been using it for a while. > > 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.

--
Email: http://www.gunnar.cc/cgi-bin/contact.pl

 0

gcr <reviewyourdemo@hotmail.com> writes:

> 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.

You didn't get it. There's nothing in the relevant standards the requires
line breaks to be consistent.

> 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 highly doubt that. You're using homemade code instead of CGI.pm (spelling
matters) to parse input from a form. That particular use of CGI.pm hasn't
been the subject of any serious debate, at least among people who know what

There *has* been some debate about the inclusion in CGI.pm of HTML-generating
functions. But those aren't what we're discussing here, and that train left
the station a long time ago anyway.

And, of course, there have been many discussions like this one, between
people who actually know what they're doing and others who seem to take
some kind of strange pride in writing bad code.

> I've also fixed other peoples broken cgi's (again, linebreak issues) by
> taking cgi.pm out and using regexes. YMMV.

Let me get this straight - you don't know what a global is, you don't know
what it means to return a value from a subroutine, and you *still* think
you're in a position to judge whether CGI.pm is worth using? You actually
believe you're qualified to not only call code that uses CGI.pm "broken",
but also that you're qualified to "fix" it????

Unbelieveable.

> Unclear what you mean - again purely my ignorance. Like I said, this
> code has run in various places for a while with no problems

You can repeat that as many times as you like - it won't change the fact
that rolling your own CGI parsing code is foolish, *especially* given the
low level of knowledge you've shown here concerning not only the CGI spec,
but programming in general.

Anyway, since you're apparently more interested in defending your ignorance
than curing it, I'm done with this.

sherm--

--
Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net

 0

Gunnar Hjalmarsson <noreply@gunnar.cc> wrote:

> . 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?

--
Fort Worth, Texas

 0

Quoth Gunnar Hjalmarsson <noreply@gunnar.cc>:
> Sherm Pendley wrote:
> > gcr writes:
> >>I didn't reinvent this wheel, though, I got it from someone and have
> >>been using it for a while.
> >
> > 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.

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::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

--
Joy and Woe are woven fine,
A Clothing for the Soul divine       William Blake
Under every grief and pine          'Auguries of Innocence'
Runs a joy with silken twine.                         benmorrow@tiscali.co.uk

 0

Tad McClellan wrote:
>>. 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).

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. ;-)

--
Email: http://www.gunnar.cc/cgi-bin/contact.pl

 0

Gunnar Hjalmarsson <noreply@gunnar.cc> writes:

> 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.

In situations where efficiency matters, I'll take mod_perl any day. :-)

But seriously - the OP doesn't know what a global is. He doesn't know what
"return a value from a subroutine" means. Do you really think he profiled
his app and found CGI.pm to be a significant bottleneck?

I don't find it upsetting when a skilled developer has a good reason (such
as a profiler-verified bottleneck) for choosing not to use CGI.pm.

I find it quite upsetting when a newbie refuses to use it, and then argues
about it and invents specious excuses for what basically amounts to simple
contrariness.

sherm--

--
Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net

 0

>>>>> "SP" == Sherm Pendley <spamtrap@dot-app.org> writes:

>> 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.

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
cwilbur@chromatico.net

 0

>>>>> "GH" == Gunnar Hjalmarsson <noreply@gunnar.cc> writes:

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

--
Charlton Wilbur
cwilbur@chromatico.net

 0

Gunnar Hjalmarsson <noreply@gunnar.cc> wrote:

> 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!

--
Fort Worth, Texas

 0

>>>>> "TMcC" == Tad McClellan <tadmc@augustmail.com> writes:

>> 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. ;-)

TMcC> Because there are now eight less regulars!

Eight fewer *knowledgeable* regulars, surely.

Charlton

--
Charlton Wilbur
cwilbur@chromatico.net

 0

Tad McClellan wrote:
>
>>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!

Probably up north helping Santa this time of the year.  :-)

John
--
Perl isn't a toolbox, but a small machine shop where you can special-order
certain sorts of tools at low cost and in short order.       -- Larry Wall

 0

Charlton Wilbur <cwilbur@chromatico.net> wrote:
>
>
>     >> 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. ;-)
>
>    TMcC> Because there are now eight less regulars!
>
> Eight fewer *knowledgeable* regulars, surely.

Or eight fewer *curmudgeonly* regulars, frankly.

--
Fort Worth, Texas

 0

John W. Krahn <someone@example.com> wrote:
>>
>>>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!
>
> 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...

--
Fort Worth, Texas

 0

Ben Morrow wrote:
> If you can do it *correctly* more efficiently than CGI.pm can,

Of course I can; just did.

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.

--
Email: http://www.gunnar.cc/cgi-bin/contact.pl

 0

Quoth Gunnar Hjalmarsson <noreply@gunnar.cc>:
> Ben Morrow wrote:
> > If you can do it *correctly* more efficiently than CGI.pm can,
>
> Of course I can; just did.
>
> 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?

> > 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.

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

--
I must not fear. Fear is the mind-killer. I will face my fear and
I will let it pass through me. When the fear is gone there will be
nothing. Only I will remain.
benmorrow@tiscali.co.uk                                   Frank Herbert, 'Dune'

 0

Ben Morrow wrote:
>>Ben Morrow wrote:
>>>If you can do it *correctly* more efficiently than CGI.pm can,
>>
>>Of course I can; just did.
>>
>>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?

Yes, several years ago.

> Can we see the results?

Sure.

>>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.

Spurious? BS! By making such a claim, without presenting any proofs,

If this _really_ was about the value of code reuse via modules, why does
nobody object to e.g. this message:

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.

--
Email: http://www.gunnar.cc/cgi-bin/contact.pl

 0

Quoth Gunnar Hjalmarsson <noreply@gunnar.cc>:
> Ben Morrow wrote:
> >>Ben Morrow wrote:
> >>>If you can do it *correctly* more efficiently than CGI.pm can,
> >>
> >>Of course I can; just did.
> >>
> >>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?
>
> Yes, several years ago.
>
> > Can we see the results?
>
> Sure.

OK, I can see there may be situations where that level of performance is
important. I still maintain it would be better practice to direct people
to a more efficient module if and when it becomes necessary, rather than
towards copy/pasting code.

> >>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.
>
> Spurious? BS! By making such a claim, without presenting any proofs,

Note the 'almost certainly' :). On the point of raw-speed-of-startup I
stand corrected. Whether this is the limiting factor in any one case
depends on what the CGI is doing, of course; I will believe you if you
say there are cases where it matters.

> If this _really_ was about the value of code reuse via modules, why does
> nobody object to e.g. this message:

I would have, in principle. Those two programs are (IMHO) nasty, and are
wrong in several particulars. They should be replaced with LWP.

In practice, I don't correct every piece of bad code that passes through
my newsreader: I simply don't have the energy. You may have noticed that
I am rarely one of those who jumps on people who aren't using CGI.pm, I
am merely defending what I see as good practice on behalf of those who
do.

Ben

--
Musica Dei donum optimi, trahit homines, trahit deos. |
Musica truces mollit animos, tristesque mentes erigit.|benmorrow@tiscali.co.uk
Musica vel ipsas arbores et horridas movet feras.     |

 0


On Nov 28, 6:23 pm, gcr <reviewyourd...@hotmail.com> wrote:
>  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.

What makes Perl so great is CPAN and all the available reliable
well-mantained quality modules.

Countless programmers have spent hours writing and mantaining module
code so we can have the capabilities to perform certain operations
trouble and stress free. This saves us from unneccessary development
time and headachs. You wouldn't spend hours and hours trying to
reinvent the wheel when the wheel is right infront of you ready to be
used.

What you have is a piece of code that dumps all parameters into Global
variables regardless of size. This will be stored in memory during the
duration of run time. Your sub form parsing technique is dated and
though may get the job done it also does ZERO error and safety handling
which makes it open to all sorts of future and present catastrophes.

You claim you want full control over how the form data is processed yet
you use it in the most generic way which makes your statement reflect
your inexperience even more so. If you have several CGIs and each use
the same copied sub-routine you are actually limiting functionality and
mantainability. Eventually you'd end up dumping the code in a module.
Then you will soon or later be forced into spending hours trying to
make your code more strict and bug free. Which would be reinventing the
wheel.

Modules are created for a reason. It's so programmers can use reliable
safe code instead of trying to reinvent the functionality of an
operation for every project. CGI.pm is the standard for parsing form
data if you choose not to use it you are only limiting yourself and
putting your web site, server and users at risk.


 0

krakle@visto.com wrote:
> ... it also does ZERO error and safety handling
> which makes it open to all sorts of future and present catastrophes.

<snip>

> CGI.pm is the standard for parsing form
> data if you choose not to use it you are only limiting yourself and
> putting your web site, server and users at risk.

Another one who naively believes that using CGI.pm for parsing the input
makes a significant difference as regards security.

It does not.

--
Email: http://www.gunnar.cc/cgi-bin/contact.pl

 0

Gunnar Hjalmarsson <noreply@gunnar.cc> writes:

> krakle@visto.com wrote:
>> ... it also does ZERO error and safety handling which makes it open
>> to all sorts of future and present catastrophes.
>
> <snip>
>
>> CGI.pm is the standard for parsing form data if you choose not to
>> use it you are only limiting yourself and putting your web site,
>> server and users at risk.
>
> Another one who naively believes that using CGI.pm for parsing the
> input makes a significant difference as regards security.
>
> It does not.

Gunnar, why do you persist with that straw-man argument? Pointing out the
fact that CGI.pm securely parses CGI arguments does not imply a claim that
doing so is all that's needed to securely write CGI applications.

This whole "skilled developers can improve upon CGI.pm, and shouldn't be
chastised for doing so" argument, while quite true, is irrelevant in this
case because is in fact *not* such a developer.

The OP frankly admitted to being incapable of even *using* CGI.pm correctly,
much less improving on it. He also admitted that he simply copy-and-pasted
the alternative code and doesn't understand how it works any more than he
does CGI.pm.

Such an individual is blindly trusting code he doesn't understand whether
he uses CGI.pm or not; the question is whether he should place such trust in
code that's been extensively community-reviewed, or in code he copied from
his neighbor's cousin's best friend's roommate.

sherm--

--
Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net

 0

Sherm Pendley wrote:
>>krakle@visto.com wrote:
>>>... it also does ZERO error and safety handling which makes it open
>>>to all sorts of future and present catastrophes.
>>
>><snip>
>>
>>>CGI.pm is the standard for parsing form data if you choose not to
>>>use it you are only limiting yourself and putting your web site,
>>>server and users at risk.
>>
>>Another one who naively believes that using CGI.pm for parsing the
>>input makes a significant difference as regards security.
>>
>>It does not.
>
> Gunnar, why do you persist with that straw-man argument?

It's not straw-man, it's both true and significant.

> Pointing out the
> fact that CGI.pm securely parses CGI arguments does not imply a claim that
> doing so is all that's needed to securely write CGI applications.

1. He didn't just claim that CGI.pm makes a difference as regards
security, he talked about "putting your web site, server and users at
risk" if you choose to not use it.

2. My objection above does not include the message you indicate.

3. Still, my belief is that using such arguments for advocating the use
of CGI.pm _does_ give the incorrect impression that you write
significantly more secure CGI programs only by using it.

> This whole "skilled developers can improve upon CGI.pm, and shouldn't be
> chastised for doing so" argument, while quite true, is irrelevant in this
> case because is in fact *not* such a developer.

While I don't defend everything the OP in this thread said, neither do I
think that _anybody_ should be chastised for using a totally harmless
piece of code.

Point out the value of code reuse through modules, fine, that's good
advice. For god's sake, I'm also a module user (and author). I'm even
using CGI.pm from time to time. :)

But try to relax, and let it stay with that. Try to believe that the
readers of this group are grown-up people, who are capable of making
their own decisions on programming style.

--
Email: http://www.gunnar.cc/cgi-bin/contact.pl

 0


On Dec 3, 4:37 pm, Gunnar Hjalmarsson <nore...@gunnar.cc> wrote:
> 3. Still, my belief is that using such arguments for advocating the use
> of CGI.pm _does_ give the incorrect impression that you write
> significantly more secure CGI programs only by using it.

Gunnar, would you agree that if a programmer chooses to parse his/her
own form data the algorithm he/she uses must be thorough, complete and
well tested for reliability?

If so, would you advocate against using an identical sub-routine copied
through out 10 CGI scripts? Programming with practical and logical
sense you'd recommend the programmer to create a module with his/her
thorough reliable code, right?

If so (once again), why would you waste time rewriting an existing
module if it meets HTTP standards if you're only going to use it in the
most generic form?

Would you really tell someone who is inexperienced (or even
experienced) to go a head and waste their time and their employers buck
producing some over the night immature code? I wouldn't hire you.

Even you yourself use CGI.pm. In Contact::Form (the module you are the
author of) you have:

# create hash reference to the form data
my $in = new CGI->Vars; Interesting.   0 Reply krakle 12/3/2006 11:06:39 PM Gunnar Hjalmarsson <noreply@gunnar.cc> writes: > While I don't defend everything the OP in this thread said, neither do > I think that _anybody_ should be chastised for using a totally > harmless piece of code. My point isn't that the specific code used by the OP was harmful. It is that the OP (by his own admission) lacks the experience to judge whether it is harmful or not. That being the case, the wisest course is to use the widely-known standard, at least until one gains the experience to make an informed decision in the matter for one's self. To do otherwise, to choose code of unknown provenance that hasn't had the extensive amount of community review that CGI.pm has had, is both risky and foolish. I do agree with you to the extent that there are occasions where using CGI.pm is not the best choice. Do you seriously believe that "I couldn't figure out how to make it work" is such an occasion? Review the thread - that's exactly the reason the OP gave for not using CGI.pm. sherm-- -- Web Hosting by West Virginians, for West Virginians: http://wv-www.net Cocoa programming in Perl: http://camelbones.sourceforge.net   0 Reply Sherm 12/3/2006 11:23:53 PM krakle@visto.com wrote: > On Dec 3, 4:37 pm, Gunnar Hjalmarsson wrote: >>3. Still, my belief is that using such arguments for advocating the use >>of CGI.pm _does_ give the incorrect impression that you write >>significantly more secure CGI programs only by using it. > > Gunnar, would you agree that if a programmer chooses to parse his/her > own form data the algorithm he/she uses must be thorough, complete and > well tested for reliability? > > If so, would you advocate against using an identical sub-routine copied > through out 10 CGI scripts? Programming with practical and logical > sense you'd recommend the programmer to create a module with his/her > thorough reliable code, right? > > If so (once again), why would you waste time rewriting an existing > module if it meets HTTP standards if you're only going to use it in the > most generic form? > > Would you really tell someone who is inexperienced (or even > experienced) to go a head and waste their time and their employers buck > producing some over the night immature code? I wouldn't hire you. > > Even you yourself use CGI.pm. In Contact::Form (the module you are the > author of) you have: > > # create hash reference to the form data > my$in = new CGI->Vars;
>
> Interesting.

--
Email: http://www.gunnar.cc/cgi-bin/contact.pl

 0

Ben Morrow wrote:
>>Ben Morrow wrote:
>>>as for 'more efficient', did you benchmark it?
>>
>>Yes, several years ago.
>>
>>>Can we see the results?
>>
>>Sure.
>
> OK, I can see there may be situations where that level of performance is
> important. I still maintain it would be better practice to direct people
> to a more efficient module if and when it becomes necessary, rather than
> towards copy/pasting code.

If somebody asks "how do I parse CGI data?" I don't give him/her any
code, but rather point at the applicable FAQ entry. This situation was
slightly different...

>>>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,
>
> Note the 'almost certainly' :).

Hmm... Okay.

> On the point of raw-speed-of-startup I
> stand corrected. Whether this is the limiting factor in any one case
> depends on what the CGI is doing, of course; I will believe you if you
> say there are cases where it matters.

That's all I say. There are also a lot of cases where it doesn't matter.

--
Email: http://www.gunnar.cc/cgi-bin/contact.pl

 0

On  3 Dec 2006, noreply@gunnar.cc wrote:

krakle@visto.com wrote:
>> ... it also does ZERO error and safety handling which makes it open
>> to all sorts of future and present catastrophes.
>
> <snip>
>
>> CGI.pm is the standard for parsing form data if you choose not to
>> use it you are only limiting yourself and putting your web site,
>> server and users at risk.
>
> Another one who naively believes that using CGI.pm for parsing the
> input makes a significant difference as regards security.
>
> It does not.

While your argument is interesting on its own, note that krakle didn't
specifically point to security, and the risk he mentions in your quote
is actually the risk of downtime and bugs.  Security is not mentioned
in the article he posted.  I checked carefully--at least that's how I

Ted

 0

Ted Zlatanov wrote:
> On  3 Dec 2006, noreply@gunnar.cc wrote:
>> krakle@visto.com wrote:
>>>... it also does ZERO error and safety handling which makes it open
>>>to all sorts of future and present catastrophes.
>>
>><snip>
>>
>>>CGI.pm is the standard for parsing form data if you choose not to
>>>use it you are only limiting yourself and putting your web site,
>>>server and users at risk.
>>
>>Another one who naively believes that using CGI.pm for parsing the
>>input makes a significant difference as regards security.
>>
>>It does not.
>
> While your argument is interesting on its own, note that krakle didn't
> specifically point to security,

Note that not even krakle objected to my interpretation:

Anyway, as long as we are agreed that CGI.pm has little to do with
security, there is no point in speculating in what krakle actually meant.

--
Email: http://www.gunnar.cc/cgi-bin/contact.pl

 0


On Dec 4, 8:36 pm, Gunnar Hjalmarsson <nore...@gunnar.cc> wrote:
> Note that not evenkrakleobjected to my interpretation:http://groups.google.com/group/comp.lang.perl.misc/msg/c09c0e267b8edf66
>
> Anyway, as long as we are agreed that CGI.pm has little to do with
> security, there is no point in speculating in whatkrakleactually meant.

I didn't say anything about security. Since I referred ro CGI.pm's code
as "thorough, complete, and well tested for reliability" and the other
code as "limiting functionality and
mantainability" I didn't think I had to specify.


 0


On Dec 3, 5:35 pm, Gunnar Hjalmarsson <nore...@gunnar.cc> wrote:
>
>


 0

On Tue, 05 Dec 2006 01:25:57 +0000, Ted Zlatanov wrote:

> On  3 Dec 2006, noreply@gunnar.cc wrote:
>
> krakle@visto.com wrote:
>>> ... it also does ZERO error and safety handling which makes it open
>>> to all sorts of future and present catastrophes.
>>
>> <snip>
>>
>>> CGI.pm is the standard for parsing form data if you choose not to
>>> use it you are only limiting yourself and putting your web site,
>>> server and users at risk.
>>
>> Another one who naively believes that using CGI.pm for parsing the
>> input makes a significant difference as regards security.
>>
>> It does not.
>
> While your argument is interesting on its own, note that krakle didn't
> specifically point to security, and the risk he mentions in your quote
> is actually the risk of downtime and bugs.  Security is not mentioned
> in the article he posted.  I checked carefully--at least that's how I
> read it, and I think most would agree with my reading.

Just as an aside, security typically consists of CIA, Confidentially,
Integrity, Availability. Somehow, people often only look at the C when
thinking about security. Downtime is A and is important from a security
stance (and can have C and I impact as well). Bugs can lead to breaches of
any of the catagories so are a scurity hazard as well.

Security is the science of managing risks due to unforseen errors. It
should always be a analysis of risks versus the cost of avoiding them. But
making this analysis can be very hard in some situations. However, one can
avoid some of this analysis by laying a baseline of contra measures.
Secure coding should always be one of those baselines. If you google on it
there are some guidelines for that on the net.

(Do note that security guidelines are hard to find in general, because
many companies make their money that way and are not going to put there
guidelines up for the public).

M4
--
Redundancy is a great way to introduce more single points of failure.


 0

37 Replies
851 Views

Similar Articles

12/12/2013 2:28:15 PM
[PageSpeed]

Similar Artilces:

@@Error not catching error.
Hi all, I want to catch error in stored procedure and return error message. I want to catch error 'Syntax error converting the varchar value 'a' to a column of data type int.' Means error occuring if i enter wrong value. Say suppose i have statment like select * from emp where rowid = 'a' PRINT @@ERROR print 'reach' here rowid is integer value so i am getting above mention error. So what i am expecting is it should print error and then print 'reach' which is not happening. can anyone tell me reason behind this and how to overcome this problem. than...

Robust error handling, an error while handling another error
I've been having this discussion a lot with my colleagues at work. A buffered file writer is the classic example. #include <fstream> int main() { std::ofstream fout("foo.txt"); if ( ! fout) return 1; //write important data to file //let the destructor implicitly close the file handle } The ofstream destructor will call flush then free the file handle, return it to the operating system. However, flush can fail. The disk can be full, for example. When flush fails, it sets a state flag, but there is no opportunity for the user to examine this state fl...

Re: ERROR: Error fetching from cursor. ORACLE error is ORA-01555: #3
Consider first fetching the subset of DW_CDR_ACCOUNT_DAY that you want w/a pass-through query & then running through it in a datastep. Something like: Proc sql ; connect to oracle as ora (blah blah blah) ; create table gnu as select * from connection to ora (select day accnt_id record_type record_subtype paid_mou bonus_mou cust_type COS from DW_CDR_ACCOUNT_DAY where day <= to_date(&orastartdate) and cust_type='Consumer' and record_type in ('VOICE','SMS','XTRAS') and COS in (10,20,30,40,60) ) ; disconnect from ...

Error reporting (for syntactic errors)
This may be a quite basic question. I am contemplating writing a compiler for a language similar to java, though with some innovative (hah!) features added, etc etc. I started out with regular BNF, but have eliminated left recursion from the grammar through allowing the grammar to directly support lists with separators. I use no tools, all is written from scratch, and so can create new grammar constructs as I want. The grammar is supposed to be (mostly) context free, but as the grammar is implemented directly as java code, each production being a class, which at the same time is a node in the...

Error: missing ) in parenthetical error
Hi, Trying the following ... function getCurrentVal(poValue) { var lcCurrentVal = 0; if (isNaN(parseInt(poValue))) { var loValue = poValue.toUpperCase(); if (loValue == "/") { lcCurrentVal = "/"; } if (loValue == "X") ( lcCurrentVal = "X"; { } else { lcCurrentVal = parseInt(poValue); } if(lcCurrentVal) { return lcCurrentVal; } } and am getting the error Error: missing ) in parenthetical Line: 189, Column: 23 Source Code: lcCurrentVal = "X"; I can't for the life of me figure it out. If i comment this line out it works fine (but then t...

Error: Errors occurred
Hi, Can any one help me out or explain the procedure to eliminate the error mentioned below while using the Generate code only via Configuration Parameters for the Target TI6000 DM6437. *********************************************************** Error building Real-Time Workshop target for block diagram 'EdgeDetection'. MATLAB error message: Error using ==> tlc_new Error: Errors occurred - aborting. *********************************************************** The Model is build without any errors and when the execution of the model starts there are no errors, b...

Error
Hi All, I created a virtual directory VD for the physical directory C:\XYZ\ABC\. on a machine 10.10.9.9 The physical directory has got a file timer.exe and i am trying to access this from my client m/c. I created a hyperlink and the link rightly takes me to that file, the status bar shows that. like http://10.10.9.9/VD/timer.exe. when i download that file an error is thrown error. CGI Error The specified CGI application misbehaved by not returning a complete set of HTTP headers. The headers it did return are: Can someone help me out in rectifying the same. Regards Venkat PS: The apps are ...

error
after compiling and wrting the design i am getting an error as follows Warning: There is a data discrepancy between synopsys database and the output file. (VHDL-286) what cud be the reason ? thanks Hi, Provide more details as to: Is this simulation or synthesis? Which tool? As this is a Warning, what happens after this? Are you still able to go thro' the flow? Ajeetha, CVC www.noveldv.com i am able to go ahead i am sythesizing a simple vhdl adder I believe the error code VHDL-286 is documented in their docs, you may get lucky if you look in that. Ajeetha, CVC www.noveldv.c...

E2900 error on boot: TL = 1, TT = 32. ERROR: Data Access Error -- Help??
Can someone help decipher this error below? Had Sun CE install 32Gb memory into 2 system boards (64Gb total), and now we are getting this error. We tried powering it back up with each system board individually, and get same error no matter which board is in, or both. So we're pretty sure it's not a single dimm that is the problem Sun Fire E2900 OpenFirmware version 5.19.4 (01/19/06 18:06) Copyright 2006 Sun Microsystems, Inc. All rights reserved. Use is subject to license terms. SmartFirmware, Copyright (C) 1996-2001. All rights reserved. 32768 MB memory installed, TL = 1, TT = 32....

E2900 error on boot: TL = 1, TT = 32. ERROR: Data Access Error -- Help?? #2
Can someone help decipher this error below? Had Sun CE install 32Gb memory into 2 system boards (64Gb total), and now we are getting this error. We tried powering it back up with each system board individually, and get same error no matter which board is in, or both. So we're pretty sure it's not a single dimm that is the problem Sun Fire E2900 OpenFirmware version 5.19.4 (01/19/06 18:06) Copyright 2006 Sun Microsystems, Inc. All rights reserved. Use is subject to license terms. SmartFirmware, Copyright (C) 1996-2001. All rights reserved. 32768 MB memory installed, TL = 1, TT = 3...

ODBC Error: SQLSTATE = S1000, Native error code = -4977 The data buffer parameter is too short(Btrieve Error 22)
HI all, I am trying to insert a new record into a table and got the following error message ODBC Error: SQLSTATE = S1000, Native error code = -4977 The data buffer parameter is too short(Btrieve Error 22) Here is the query I am using. insert into amgr_user_fields_tbl values ('123456789012345678901234',0,38,0,0, '2003-11-01',0.0, '123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890', '123456789012','2003-12-10','16:18:13','1234') Here is the table defination create...

transform
Hi, I get a compiler error when trying to use std::transform to iteratate/modify a list. If I write the same code by hand, it compiles fine. Am I misusing transform, or is this a compiler bug? The types involved are complex templates, but I don't think this should have any bearing on things. ------------------------------- const UserIFSeq& uList; UserIFSeq::const_iterator i; UserISeq users; // // Compiles Fine. // for (i = uList.begin(); i != uList.end(); i++) users.push_back(UserIPrx::uncheckedCast(*i)); // // Produces Error. // std::transform(uList.begin(), uList...

Mapping error codes to error messages
I need to make an error handling framework to be used by C++ applications running on HP-UX. In this, the application error codes can be mapped to pre-defined error messages. The framework would have C++ exception classes for error information propagation. I however have no clue on how to map the error codes to the messages, and efficiently access the messages through a simple mapping class or function. I know this is not exactly a UNIX question that we are discussing, but is anybody aware of any implementation techniques. Should it necessarily be a static array indexed by error codes or some r...

chemmacros, exp13.sty error error
Hi, I'm trying to write chemistry with oxidation numbers and if I google correctly chemmacros appear to be a good way to do this. But when I try to use it I get complaines about exp13.sty, about which I can find nothing useful. Code: \documentclass[a4paper,12pt]{article} \usepackage[version=3]{mhchem} \usepackage{chemmacros} \begin{document} \ce{\ox{1,H}} \end{document} And the error message is: ! LaTeX Error: File `exp13.sty' not found. Any suggestions? Par -- Par usenet@hunter-gatherer.org What was it they were saying about arn...

CGIWrap error: exec format error
This message usually indicates there is a problem with the script itself. Often this indicates either that the #! line of the script is incorrect, or the script was uploaded in binary mode instead of ascii mode. Check to make sure that the script does not have control-M's at the end of every line. That will prevent it from executing. An easy fix that takes care of this most of the time is to put '#!/.../perl --' instead of '#!/.../perl' on the first line of the script. This is typically a problem if the script was edited or uploaded from a DOS/Windows/Macintosh station to ...

ERROR:MDT
Hi, I start to work on FPGA Embedded system. I am trying to port the MonstaVista Linux on the system. First I built the system with EDK, the option for my system is: XUPV2P: powerPC 405 300MHz Bus 100MHz RS232_Uart_1 OPB UART 1655 (interrupt) Ethernet_MAC OPB ETHERNET (interrupt) SysACE_Compact Flash (interrupt) DDR_512MB I continue to work on software platform which is: Linux_mv131 version 1.01.b MEM_SIZE 0x10000000 PLB_CLOCK_FREQ_HZ 100000000 (100 MHz) Connected_periphs RS232_Uart_1, Ethernet_MAC, SysACE_CompactFlash, opb_intc_0 After generate the bitstream, then Generate Librari...

Error with script
Hi I'm been having this error nad can't seem to locate the source of the problem. I though the the error was the variables but even after isolating them, the error message: <<The server encountered an internal error or misconfiguration and was unable to complete your request.>> Still shows up. Does any have any idea what the cause is. Any help would be appreciated. HTML FILE________________________________________________________ <!-- ** INFORMATION ON THE PAGE **************************** Page name _________________ : PY_iPass.html Version ___________________ : 1.2...

what is the error
//a single link list,the nodes contain an integer value called value void handler::delete(){ int del; cout<<"which number do u want to delete"<<endl; cin>>del; node *previous;//always behind the sth node for(node *sth=head;sth!=NULL;sth=sth->next){ if(sth->value==del) { if(sth==head) { node *deleted=head; head=head->next; delete deleted; } else { node *deleted=sth; previous->next=deleted->next; delete deleted; } previous=sth; } } } jw wrote: > //a single link list,the nodes contain an integer value ...

Error...
Hi I try to make a vpn tunnel site to site with pdm and i have some error crypto map outside_map 220 set peer xx.xx.xx.xx WARNING:This crypto map is incomplete to remedy the situation add a peer and a valid access-list to this crypto map. what's is wrong.. regards Tomek W. wrote: > Hi > I try to make a vpn tunnel site to site with pdm > and i have some error > crypto map outside_map 220 set peer xx.xx.xx.xx > WARNING:This crypto map is incomplete > to remedy the situation add a peer and a valid access-list to this crypto > map. It's only a warn just add...

error,again
tentaively, got: create #table(a,b,c,d) insert into #table select A,B,C,D from s,t,x,y,z where y.price > 20 select *, (select max(D) from (select distinct top 2 with ties from #temp v where v.B=W.B and v.C = W.c), (select min(D) from (select distinct top 2 with ties from #temp v where v.B=W.B and v.C = W.c) from #temp w drop Table #temp This works, but if y.price > 20 condition is not met, unsupported error message gets produced within crystal report. i expected blank field report instead in this case, included If exists around the select statement , still same error. BTW, is ther...