You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Andre <wo...@br.inter.net> on 2006/08/12 03:42:00 UTC
up2date mess continued: serious leakage!
Hello
Now the variables leak despite what I do.
Can you guys confirm if this script isn't supposed to leak? It's totally mad, confusing all usernames.
Thanks
André
PS: it's a simple test.cgi wich I am calling with
test.cgi?username=jane
test.cgi?username=jack
test.cgi?username=stacey
... and it keeps confusing all names.
I'm using 'local our's, so I think it shouldn't be leaking, and this is a problem at my mod_perl installation. So what could be causing this there? What do I do?
#!/usr/bin/perl -wT
use strict;
use CGI;
local our $q = new CGI;
local our $username = $q->param('username');
print "Content-type: text/html\n\n";
defined $username and print "<p>Hello there, your username is $username <br>";
! defined $username and print "<p>[no username provided]<br>";
Re: Sort issue
Posted by Mike OK <mi...@acorg.com>.
After a few off list hints and hours of searching and reading I have solved
the issue. Here is the link to the page I found helpful. Very belated
thanks (almost 6 years) goes to Stas Bekman. Mike
http://www.gossamer-threads.com/lists/modperl/modperl/35645?search_string=so
rt%20subroutine;#35645
----- Original Message -----
From: "Mike OK" <mi...@acorg.com>
To: <mo...@perl.apache.org>
Sent: August 13, 2006 11:32 AM
Subject: Sort issue
> Hi
>
> I would like to do some custom sorting with some hash data that I
have
> stored. It will be used in a mod_perl application so I would like to
ensure
> that the variables are safe and local. My worry is that I plan to call a
> subroutine with sort but I have no idea how to pass the variables or if I
> even have to. Here is what I am planning. Any advice or links would
help.
> Thanks a lot. Mike
>
> @sortedkeys = sort by_field keys(%names);
>
> sub by_fields {
> my ($first_compare,$first_extra) = $names{$a};
> my ($second_compare,$second_extra) = $names{$b};
> ### I am spliting the value to sort on a secondary field other than the
> key
> ($first_compare <=> $second_compare || $first_extra <=> $second_extra);
> }
>
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.405 / Virus Database: 268.10.7/411 - Release Date: 2006-08-07
>
>
Sort issue
Posted by Mike OK <mi...@acorg.com>.
Hi
I would like to do some custom sorting with some hash data that I have
stored. It will be used in a mod_perl application so I would like to ensure
that the variables are safe and local. My worry is that I plan to call a
subroutine with sort but I have no idea how to pass the variables or if I
even have to. Here is what I am planning. Any advice or links would help.
Thanks a lot. Mike
@sortedkeys = sort by_field keys(%names);
sub by_fields {
my ($first_compare,$first_extra) = $names{$a};
my ($second_compare,$second_extra) = $names{$b};
### I am spliting the value to sort on a secondary field other than the
key
($first_compare <=> $second_compare || $first_extra <=> $second_extra);
}
Re: up2date mess SOLVED!
Posted by Andre <wo...@br.inter.net>.
Folks
I had all back working only after I uninstalled mod_perl and reinstalled it again.
I didn´t know how to uninstall, but I found a very usefull uninstall menu at the 'others' tab at Webmin (the free control panel software that comes with RHEL).
To reinstall it was pretty easy, following the regular mod_perl installation.
And I've definatelly deactivated this damn up2date, for this was just like a trojan horse for me!
Thanks for the replies everybody!
André
----- Original Message -----
From: Andre
To: modperl@perl.apache.org
Sent: Friday, August 11, 2006 10:42 PM
Subject: up2date mess continued: serious leakage!
Hello
Now the variables leak despite what I do.
Can you guys confirm if this script isn't supposed to leak? It's totally mad, confusing all usernames.
Thanks
André
PS: it's a simple test.cgi wich I am calling with
test.cgi?username=jane
test.cgi?username=jack
test.cgi?username=stacey
... and it keeps confusing all names.
I'm using 'local our's, so I think it shouldn't be leaking, and this is a problem at my mod_perl installation. So what could be causing this there? What do I do?
#!/usr/bin/perl -wT
use strict;
use CGI;
local our $q = new CGI;
local our $username = $q->param('username');
print "Content-type: text/html\n\n";
defined $username and print "<p>Hello there, your username is $username <br>";
! defined $username and print "<p>[no username provided]<br>";
Re: up2date mess continued: serious leakage!
Posted by Mike OK <mi...@acorg.com>.
Hi
Why not try declaring the variables with "my" instead. A quote from O'Reilly's Perl in a Nutshell
Dynamic variables are visible to other subroutines called from within their scope. Dynamic variables are defined with local, and they are not private variables, but rather they are global variables with temporary values. When a subroutine is executed, the global value is hidden away, and the local value is used. Once the scope is exited, the original global value is used. Most of the time you will want to use my to localize parameters in a subroutine.
Mike
----- Original Message -----
From: Andre
To: modperl@perl.apache.org
Sent: August 11, 2006 9:42 PM
Subject: up2date mess continued: serious leakage!
Hello
Now the variables leak despite what I do.
Can you guys confirm if this script isn't supposed to leak? It's totally mad, confusing all usernames.
Thanks
André
PS: it's a simple test.cgi wich I am calling with
test.cgi?username=jane
test.cgi?username=jack
test.cgi?username=stacey
... and it keeps confusing all names.
I'm using 'local our's, so I think it shouldn't be leaking, and this is a problem at my mod_perl installation. So what could be causing this there? What do I do?
#!/usr/bin/perl -wT
use strict;
use CGI;
local our $q = new CGI;
local our $username = $q->param('username');
print "Content-type: text/html\n\n";
defined $username and print "<p>Hello there, your username is $username <br>";
! defined $username and print "<p>[no username provided]<br>";
------------------------------------------------------------------------------
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.405 / Virus Database: 268.10.7/411 - Release Date: 2006-08-07