Subroutines and '&'

[Eric Schwartz]

~greg> It is still required,
~greg> but only when dealing with references (I think)

Or when dealing with a subroutine that is the same name as a built-in.
See my other post.

That falls under my "But Doctor, it hurts when I do that" rule.
Naming your subs with the same name as a built-in is a bad idea, and I
don't mind in the slightest that perl warns you about it (you *did*
enable warnings, didn't you?).

-=Eric

 

[Paul Lalli]

I see where that would be possible. But would a user not need
to know the name of a subroutine in my script?

Yes he would. But how difficult is that? How difficult is it to just
*guess* for starters, but more specifically, your form's parameter
list is giving him at least a subset of all options.

My goal is to try and combine as many functions as possible into
one script, rather than have 5 or 6 separate scripts to maintain.

I have no idea what this issue has to do with the issue being
discussed.

Which brings up a question: if a user
can call any subroutine in my script, what's to stop them from
running a separate script as well?

.... absolutely nothing. You should write ALL scripts residing on a
publically accessable webserver to be secure, and to check that only
those who are running the script "correctly" can do anything. If I
randomly type the address to one of your CGI scripts into my browser's
address bar, passing it data of my own creation, your script should be
able to handle that gracefully and not do anything it shouldn't do.

If there is no secure way to do this with this particular method I
would like to know so as to fix it.

You've already been given (or considered yourself) a few ways to do
this correctly. Either create a dispatch table as Anno demonstrated,
or check the value of each parameter to make sure it matches an
acceptable value.

Paul Lalli

 

[Martijn Lievaart]

In your .emacs file

(defalias 'perl-mode 'cperl-mode)

Snarfed. Thanks!

M4

 

[Lars Haugseth]

Emacs suffers from much the same problems. F.i. quote like operators are
not properly recognized, making me write:

next if m'^#';

instead of

next if /^#/;

The latter works like a charm here. Make sure you're using a recent
version of cperl-mode, though.

http://www.emacswiki.org/cgi-bin/wiki/CPerlMode

 

[Peter Scott]

I agree with the solution to that *particular* problem, but as is oft
said: Nothing but perl can parse Perl with absolute certainty. While
cperl-mode does not get nearly as confused nearly as often as
perl-mode did, I have succeeded in confusing its parser on occasion.

Me too. One reliable way of doing that is to use m or s as naked hash
keys. Still, happens seldom enough that it's worth it to me to work
around, usually with a comment that contains the delimiters it's looking
for.