and why can't I do my own CGI?

[Jeff 'japhy' Pinyan]

for example...

get input
know what you are doing with it
don't use it for things that can **** up your system unless you check it
what else is there?

You'd be surprised how hard it is to do these things right.

Are you dealing with POST or GET?

Are you dealing with a file upload? (That's not easy or fun to do from
scratch.)

Are you handling multiple fields with the same name properly?

Are you storing the data safely?

Etc.

(And you don't need to post each sentence of an idea as a separate article
in the newsgroup. And your attitude is likely to get you ignored by the
people that could help you the most.)

 

[Tassilo v. Parseval]

Also sprach Hudson:

like I said...know what you are doing with the data...it is not so hard...

Nothing appears to be hard for you. So what do you want from this group?
If things are really that simple but you nonetheless consult the group
for help, perhaps they are still too tall an order for you.

Tassilo

 

[Hudson]

I don't see why I have to use some huge module when the ideas behind it are
simple...

 

[Hudson]

I don't see why I have to use some huge module when the ideas behind it are
simple...

for example...

get input
know what you are doing with it
don't use it for things that can **** up your system unless you check it
what else is there?

 

[Hudson]

(And you don't need to post each sentence of an idea as a separate article
in the newsgroup. And your attitude is likely to get you ignored by the
people that could help you the most.)

what attitude? I just got attacked from uri because I dared to think different
than him...so of course it makes me pissed

 

[Hudson]

You'd be surprised how hard it is to do these things right.

Are you dealing with POST or GET?

Are you dealing with a file upload? (That's not easy or fun to do from
scratch.)

Are you handling multiple fields with the same name properly?

Are you storing the data safely?

like I said...know what you are doing with the data...it is not so hard...

 

[Randal L. Schwartz]

hudson> bah....I just thought this was the "abuse me please" channel. anyway,
hudson> as other people have mentioned before, this group does seem a bit
hudson> dogmatic on certain topics

s/dog/prag/, please.

We say what we say only because most of us have been around the block
a few times, gotten burned on bad practices, and are now passing along
good practices.

Hand-coding instead of using a well-established module is fine in the
privacy of your own cube, but don't post it on the net, or expect to
be applauded for it.

Now, if you had said instead "I've studied all of CGI.pm, and read
the bug log, and understand why each feature is there, and now
I've written something that does everything CGI.pm does and better,
and is more secure and faster", you'd get a hella lot respect.

Instead, you poo-poo the work that has happened before you in terms of
portability, usability, and security, and therefore practicality.

That will earn you no respect here. That's an immature programmer (of
any age) talking who thinks they know more about programming than we
know they know.

The most important thing to know (at least in this industry is
that YOU DON'T KNOW why someone else did something, until you look.

Presumption that you know is the kind of arrogance that causes shuttle
tanks to blow up, moon capsules to explode mid-way to the moon, and
ice damage to break up shuttles on reentry.

You're being given some good advice here... and it's consistent. It's
not just a few people. You walk into a discussion area and get a
consistent prodding to not reinvent a wheel you don't fully
understand. Your best plan at this point is to at least understand
why we're all saying that at the same time!

But, if you won't follow that advice, the best next advice is don't
post any more code, because you seem to be unable to handle the
feedback that a professional programmer gets and gives. No point
subjecting yourself to that here.

I've been writing code for over three decades. I still learn
something every day by looking at other people's code. Don't be so
close-minded so early in the cycle.

print "Just another Perl hacker,";

 

[Uri Guttman]

h> I think you are very wrong here in what you are saying. I just came
h> to say...hey...there are not really a lot of examples of using soap
h> with perl without the module and bam! I got slammed.

h> And using soap via IO::Socket is so easy. So I posted up my little
h> piece of code and people started calling me names.

you use the io::socket module? why not use real sockets. real
programmers do that.

you contradict yourself at every turn. and you have succeeded in
alienating the entire group. contragulations! and by the way, code
criticism is not hate. learn that too. that way lie moronzilla's
disease.

you have promised to shut up on this already. when will that happen? and
learn c. you will have so much fun reinventing all the problems
regarding pointers, memory management. i can see you now declaring that
all your c code is perfectly fine for mission critical systems.

uri

 

[hudson]

Nothing appears to be hard for you. So what do you want from this group?

If things are really that simple but you nonetheless consult the group
for help, perhaps they are still too tall an order for you.

bah....I just thought this was the "abuse me please" channel. anyway,
as other people have mentioned before, this group does seem a bit
dogmatic on certain topics

 

[Eric J. Roode]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

hey uri....I'm all ears...please tell me about it.

can you do real sockets in perl? or are you talking C function
calls....

<sigh>

Yes. Look up the following Perl builtin functions:

accept, bind, connect, getpeername, getsockname, getsockopt, listen,
recv, send, setsockopt, shutdown, socket, socketpair.

It's good to write things like soap, CGI, and socket stuff by hand from
scratch, but *only* as a programming exercise; never for the real world,
even if you only use it on your own play systems. I've done socket
programming in C, and in Perl using the above functions, and in Perl
using IO::Socket. I've done CGI programming by hand, using my own code
to parse the input data, and I've used CGI.pm. I've never done Soap in
any language; but you can be sure I'd use a module. In all cases, it is
instructive and illustrative to code it by hand, to understand what's
going on under the hood, but for anything approaching the real world, an
off-the-shelf module will almost certainly do the job better and more
efficiently than you (or I) can.

That said, one can't improve the state of Perl modules without knowing
what's going on under the hood and grokking the internals of the existing
modules. There are times when a wheel simply needs to be reinvented,
because the existing wheel is inadequate (example: Module::Build coming
out over the existing ExtUtils::MakeMaker). But -- not to sound
condescending -- "it is not yet time for you to leave, Grasshopper."



- --
Eric
$_ = reverse sort $ /. r , qw p ekca lre uJ reh
ts p , map $ _. $ " , qw e p h tona e and print

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>

iQA/AwUBPz702mPeouIeTNHoEQJIhACcDrGVotHxxa6xTT0QI+ct5LzWfisAn2iK
AlO2edijq3V+cToWJV7enHEj
=ctns
-----END PGP SIGNATURE-----

 

[hudson]

I think you are very wrong here in what you are saying. I just came to
say...hey...there are not really a lot of examples of using soap with
perl without the module and bam! I got slammed.

And using soap via IO::Socket is so easy. So I posted up my little
piece of code and people started calling me names.

 

[hudson]

you use the io::socket module? why not use real sockets. real

programmers do that.

hey uri....I'm all ears...please tell me about it.

can you do real sockets in perl? or are you talking C function
calls....

about my promise to learn C...it will take me a couple of years maybe.

 

[hudson]

<sigh>

OK...sorry to make you sign...

Yes. Look up the following Perl builtin functions:

accept, bind, connect, getpeername, getsockname, getsockopt, listen,
recv, send, setsockopt, shutdown, socket, socketpair.

It's good to write things like soap, CGI, and socket stuff by hand from
scratch, but *only* as a programming exercise; never for the real world,
even if you only use it on your own play systems. I've done socket
programming in C, and in Perl using the above functions, and in Perl
using IO::Socket. I've done CGI programming by hand, using my own code
to parse the input data, and I've used CGI.pm. I've never done Soap in
any language; but you can be sure I'd use a module. In all cases, it is
instructive and illustrative to code it by hand, to understand what's
going on under the hood, but for anything approaching the real world, an
off-the-shelf module will almost certainly do the job better and more
efficiently than you (or I) can.

That said, one can't improve the state of Perl modules without knowing
what's going on under the hood and grokking the internals of the existing
modules. There are times when a wheel simply needs to be reinvented,
because the existing wheel is inadequate (example: Module::Build coming
out over the existing ExtUtils::MakeMaker). But -- not to sound
condescending -- "it is not yet time for you to leave, Grasshopper."

perl is kind of built from other things, isn't it? sed, awk, C,
etc....maybe the correct way to learn perl is to understand
computers...since isn't that what those built in functions you are
talking about come from:

accept, bind, connect, getpeername, getsockname, getsockopt, listen,
recv, send, setsockopt, shutdown, socket, socketpair.

that's all from a sleepy grasshopper ;-)

 

[Tassilo v. Parseval]

Also sprach hudson:

perl is kind of built from other things, isn't it? sed, awk, C,
etc....maybe the correct way to learn perl is to understand
computers...since isn't that what those built in functions you are
talking about come from:

accept, bind, connect, getpeername, getsockname, getsockopt, listen,
recv, send, setsockopt, shutdown, socket, socketpair.

I think you can turn that around even. Understand computers (at least
some essential concepts relating to operating systems) by using and
learning Perl. Perl is suitable for that (and to some degrees more
suitable than other scripting languages) because it offers some very
low-level constructs (the ones you quoted above plus - among others -
the IPC-stuff as layed out in perlipc.pod) without negelecting the
high-level stuff.

Since you said you planned on picking up C: I owe to Perl everything I
learnt about C. Perl was my first language I became fluent with and
after a while I became interested in the Perl-internals and started
doing XS (essentially, writing Perl modules in C with the help of the
PerlAPI). It's an odd way of learning C because XS doesn't have the
reputation of being particularly beginners-friendly. But, alas, anything
can happen when doing Perl.

And then C helped me to understand more of Perl. I never understood how
to use pack() and unpack() till I realized how closely they ressemble
the way C handles different data-types and converts them into each
other. C:

/* an 'int' is four bytes on my machine */
unsigned char c[4] = { 255, 255, 255, 255 };
unsigned int *i = (int*)c;

Perl:

$i = unpack "L", chr(255).chr(255).chr(255).chr(255);

Tassilo

 

[Jonathan Stowe]

thank you Eric.

you know what...parsing CGI is kind of a bitch...maybe I should just
load in part of a module and not use the whole thing.

You might want to examine the code of CGI.pm: although the actual file is
quite large it employs a number of techniques to keep the load and parse
time to a minimum - whilst the entire file must be read by perl, on the most
part only those methods that are actually used are parsed and compiled, so
splitting the file up is unlikely to lead to a great improvement in
performance and is likely to introduce new bugs.

/J\

 

[Chris Mattern]

bah....I just thought this was the "abuse me please" channel. anyway,
as other people have mentioned before, this group does seem a bit
dogmatic on certain topics

They insist on code that works. How narrow-minded, indeed.

Chris Mattern

 

[hudson]

Thanks Tassilo,

I just read several books about unix and C and I am amazed at how much
it helped me understand Perl, so I totally agree with you.

 

[hudson]

One issue you didn't mention, which seems to me to be very relevant in

practice: even the simplest of hand-coded scripts has a tendency to
add features during its life. Maybe to support POST when it was
originally only to support GET - maybe to support file-upload when it
originally didn't - maybe to support re-writing an incomplete form and
prompting for required fields that had been left blank or wrongly
completed - and so on. If started off the right way, then CGI.pm
allows such features to be bolted on almost for free. If started off
with hand-coding, then such a script rapidly becomes an insecure and
unmaintainable quivering heap. I know - I've made just that mistake
for myself, in the early days.

this was a great post for me, since I can really relate to it ;-)