[31546] in Perl-Users-Digest
Perl-Users Digest, Issue: 2805 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Feb 5 14:14:26 2010
Date: Fri, 5 Feb 2010 11:14:16 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Fri, 5 Feb 2010 Volume: 11 Number: 2805
Today's topics:
Re: Python's Reference And Internal Model Of Computing <dthole@gmail.com>
Re: Python's Reference And Internal Model Of Computing <jurgenex@hotmail.com>
Re: Python's Reference And Internal Model Of Computing <tadmc@seesig.invalid>
Re: Python's Reference And Internal Model Of Computing <jurgenex@hotmail.com>
Re: Python's Reference And Internal Model Of Computing <dthole@gmail.com>
Re: Python's Reference And Internal Model Of Computing <jurgenex@hotmail.com>
Re: Python's Reference And Internal Model Of Computing <tadmc@seesig.invalid>
Running NMap Scan from Perl <kdawg44@gmail.com>
Re: SpeedyCGI, clearing certain variables <jwcarlton@gmail.com>
Re: SpeedyCGI, clearing certain variables <jwcarlton@gmail.com>
Re: Want your opinion on @ARGV file globbing <Peter@PSDT.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 05 Feb 2010 09:53:33 -0600
From: David Thole <dthole@gmail.com>
Subject: Re: Python's Reference And Internal Model Of Computing Languages
Message-Id: <m2sk9fllvm.fsf@dhcpw80ff9506.dynamic.uiowa.edu>
I read this....and am a tiny bit confused about the actual problem.
It's not exactly complex to realize that something like:
a = b = array
that a and b both point to the array.
Logically speaking, I'm not sure how one could assume that the same
assignment would yield a and b point to the same duplicate array. If
that was the case, why not do:
a = array..
b = array..
I know with what you were complaining about a few days ago, .clear makes
perfect sense. If a and b point to the same array, clear should clear
both arrays. Again, if you didn't want that to happen, create a
duplicate array.
Personally I feel that this complexity doesn't hamper programming
process, and yes while its good for efficiency it also just makes sense.
Also, I wouldn't look at PHP on the right way to do something
programming wise. I have ~5 years experience in this language, and I
dislike it a whole lot. There's a lot of things it should do right that
it doesn't out of convenience.
-David
www.thedarktrumpet.com
------------------------------
Date: Fri, 05 Feb 2010 08:48:29 -0800
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Python's Reference And Internal Model Of Computing Languages
Message-Id: <b1iom59726rj1qdd197u2dd2rd71bjdid1@4ax.com>
David Thole <dthole@gmail.com> wrote in comp.lang.perl.misc:
>I read this....and am a tiny bit confused about the actual problem.
>
>It's not exactly complex to realize that something like:
>a = b = array
>that a and b both point to the array.
???
What are you talking about? First of all you should post actual code,
not pseudo-code because pseudo-code leads to misunderstandings. Did you
mean
@a = @b = @array
Second what do you mean by "pointing"? That is a very ambiguous term. if
you do the assignment as written above then @a and @b will be _copies_
of @array. If you want two additional references to the same array
insted then you have to create that reference first and assign that
reference to $a and $b instead of copying the array, see "perldoc
perlref" for details. And remember, references are scalars, no matter if
they reference other scalars or arrays.
>Logically speaking, I'm not sure how one could assume that the same
>assignment would yield a and b point to the same duplicate array. If
Now what? The same array or a duplicate array? Two very different and
mutually exclusive things.
>that was the case, why not do:
>a = array..
>b = array..
Which, after correcting the obvious syntax errors is the same as the
code above.
>I know with what you were complaining about a few days ago, .clear makes
>perfect sense. If a and b point to the same array, clear should clear
They don't point, they are copies. And what do you mean by "clear"?
>both arrays. Again, if you didn't want that to happen, create a
>duplicate array.
But that is what that code above does. If you want references then
create references.
jue
------------------------------
Date: Fri, 05 Feb 2010 11:25:34 -0600
From: Tad McClellan <tadmc@seesig.invalid>
Subject: Re: Python's Reference And Internal Model Of Computing Languages
Message-Id: <slrnhmokto.s9v.tadmc@tadbox.sbcglobal.net>
["Followup-To:" header set to comp.lang.perl.misc.]
Jürgen Exner <jurgenex@hotmail.com> wrote:
> David Thole <dthole@gmail.com> wrote in comp.lang.perl.misc:
>>I read this....and am a tiny bit confused about the actual problem.
>>
>>It's not exactly complex to realize that something like:
>>a = b = array
>>that a and b both point to the array.
>
> ???
> What are you talking about? First of all you should post actual code,
First of all, we should not be feeding the troll!
actual code in one of Perl, Python or Lisp?
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.liamg\100cm.j.dat/"
------------------------------
Date: Fri, 05 Feb 2010 09:34:54 -0800
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Python's Reference And Internal Model Of Computing Languages
Message-Id: <5klom5tsua9c0kni89u6ttot5irohqdfus@4ax.com>
Tad McClellan <tadmc@seesig.invalid> wrote:
>["Followup-To:" header set to comp.lang.perl.misc.]
>
>Jürgen Exner <jurgenex@hotmail.com> wrote:
>> David Thole <dthole@gmail.com> wrote in comp.lang.perl.misc:
>>>I read this....and am a tiny bit confused about the actual problem.
>>>
>>>It's not exactly complex to realize that something like:
>>>a = b = array
>>>that a and b both point to the array.
>>
>> ???
>> What are you talking about? First of all you should post actual code,
>
>First of all, we should not be feeding the troll!
Oh, is David Thole another incarnation of Xha Lee? I haven't seen his
name before...
jue
------------------------------
Date: Fri, 05 Feb 2010 12:19:27 -0600
From: David Thole <dthole@gmail.com>
Subject: Re: Python's Reference And Internal Model Of Computing Languages
Message-Id: <m2ljf7lf4g.fsf@dhcpw80ff9506.dynamic.uiowa.edu>
Tad,
I can promise you I'm not trolling - I was responding to Xah Lee's
original newsgroup post. I'll leave it as that.
Jurgen:
I avoided posting actual code because Xah Lee's post was cross-newgroup,
which if I write something in Lisp, it definitely wouldn't be applicable
to Perl or Python. It was a decision to keep it simple is all, language
inspecific.
For the second point, yes "pointing" is an ambiguous term in this case.
As far as your justification, please don't bother. I was responding to
an original post in which justifying the logic, such like in Ruby:
a = b = {"a" => 5, "b" => 10}
a
=> {"a" => 5, "b" => 10}
b
=> {"a" => 5, "b" => 10}
a["a"] => 15
=> 15
a["a"] => 15
=>15
a
=> {"a" => 15, "b" => 10}
b
=> {"a" => 15, "b" => 10}
That this makes sense. That the location of the hash in memory is
pointed to by the same two variables, a and b respectively. The
original argument from Xah Lee appeared, at least to me, that a would
contain a separate copy of the has that b contains - in which when I set
a["a"] = 15, that b["a"] would still be 5.
I can't speak much to perl. His argument was that something along the
lines of: a.clear() [Note: switching now to python syntax sudden,
sorry..] sets both a = {} and b = {}, which he felt was wrong, and that
a should be {} while b should still be {"a" => 5, "b" => 10}.
As I tested in my very lacking understanding of Perl, it appears to do
the same thing that Python, Ruby and Lisp do. Which is good in my
opinion, I think you're fighting against the wrong individual....
So...as I am clarifying once again, I'm not a troll and I'm not saying
anything is wrong. My feeling is that the fact that a and b reference
the same memory space for this hash is *ok* not an issue such as the
original post made it feel.
I apologize for cross posting back to lisp, it's so I can see responses
later if they come in.
-David
http://www.thedarktrumpet.com
------------------------------
Date: Fri, 05 Feb 2010 10:48:16 -0800
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Python's Reference And Internal Model Of Computing Languages
Message-Id: <skpom551dhurpam4kgi7fjjgsvmcun89cd@4ax.com>
David Thole <dthole@gmail.com> wrote:
>I can promise you I'm not trolling - I was responding to Xah Lee's
>original newsgroup post. I'll leave it as that.
Ahh, that explains a lot. Any sensible person has killfiled Xah Lee ages
ago, therefore his post never showed up. And you didn't cite or
reference any preceeding posting, therefore I assumed yours was an
original and not a response to some insane troll.
jue
------------------------------
Date: Fri, 05 Feb 2010 13:03:12 -0600
From: Tad McClellan <tadmc@seesig.invalid>
Subject: Re: Python's Reference And Internal Model Of Computing Languages
Message-Id: <slrnhmoqkq.sqf.tadmc@tadbox.sbcglobal.net>
["Followup-To:" header set to comp.lang.perl.misc.]
David Thole <dthole@gmail.com> wrote:
> Tad,
>
> I can promise you I'm not trolling -
I did not say, or even imply, that you were trolling.
> I was responding to Xah Lee's
> original newsgroup post.
I did say that you were feeding the troll.
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.liamg\100cm.j.dat/"
------------------------------
Date: Fri, 5 Feb 2010 06:21:50 -0800 (PST)
From: KDawg44 <kdawg44@gmail.com>
Subject: Running NMap Scan from Perl
Message-Id: <99bf5f12-bddc-4d55-983c-370dce34915f@21g2000yqj.googlegroups.com>
Hello,
From a resource perspective, would it be better to loop through and
scan each subnet or build my list of subnets and scan once? Does it
matter?
For instance, would I be better looping through:
nmap -sS SUBNET_1
nmap -sS SUBNET_2
nmap -sS SUBNET_3
.....
or
nmap -sS SUBNET_1 SUBNET_2 SUBNET_3 .....
Also, due to a whitelist built into my script (skipped over IP's), the
scan looks more like:
nmap -sS SUBNET_1.1-40 SUBNET_1.42-100 SUBNET_1.102-254
Will any of this make a difference?
Thanks for your suggestions.
Kevin
------------------------------
Date: Thu, 4 Feb 2010 23:07:44 -0800 (PST)
From: Jason Carlton <jwcarlton@gmail.com>
Subject: Re: SpeedyCGI, clearing certain variables
Message-Id: <40cfb1aa-36c2-48a3-a3e1-4c5cc19eed42@a5g2000yqi.googlegroups.com>
On Feb 4, 11:55=A0pm, Jason Carlton <jwcarl...@gmail.com> wrote:
> I have a rather lengthy CGI script that I wrote about 5 years ago, but
> it's still functional. At the very beginning, though, it connects to a
> database, then loads several variables. It would be nice if these
> could stay persistent.
>
> Rather than rewriting the whole thing, I'm thinking that it might be
> simpler to use SpeedyCGI to just keep a connection open to these
> static variables.
>
> Is there a way for me to empty certain variables on each run?
> Specifically, I'd like to undefine params and cookies. I thought that
> this would work, but it didn't:
>
> # Parse params into @contents
> undef @params;
> undef @contents;
> @params =3D param;
> @contents{@params} =3D map param($_) =3D> @params;
>
> # Fetch cookies, $id =3D $cookies{'ID'}->value;
> undef %cookies;
> %cookies =3D fetch CGI::Cookie;
> foreach $key (keys %cookies) { $cookies{$key} =3D $cookies{$key}-
>
> >value; }
>
> TIA,
>
> Jason
I believe that I stumbled across my own answer.
CPAN states that you can change the shebang line to:
#!/usr/bin/speedy
This seems to work fine, but when I changed it to:
#!/usr/bin/perl
use CGI::SpeedyCGI;
my $sp =3D CGI::SpeedyCGI->new;
The variables seemed to work the way I expected. I only had to declare
the ones I wanted to make persistent, and the others died on their
own. Ie:
my ($dbh); # clear it on first run
our ($dbh); # keep it persistent for second+ runs
If you have any other insight, I'm all ears. But so far, this seems to
be working.
------------------------------
Date: Thu, 4 Feb 2010 23:33:57 -0800 (PST)
From: Jason Carlton <jwcarlton@gmail.com>
Subject: Re: SpeedyCGI, clearing certain variables
Message-Id: <4ad26398-eaea-450d-b0ca-cebfc143b9c7@h2g2000yqj.googlegroups.com>
On Feb 5, 2:07=A0am, Jason Carlton <jwcarl...@gmail.com> wrote:
> On Feb 4, 11:55=A0pm, Jason Carlton <jwcarl...@gmail.com> wrote:
>
>
>
>
>
> > I have a rather lengthy CGI script that I wrote about 5 years ago, but
> > it's still functional. At the very beginning, though, it connects to a
> > database, then loads several variables. It would be nice if these
> > could stay persistent.
>
> > Rather than rewriting the whole thing, I'm thinking that it might be
> > simpler to use SpeedyCGI to just keep a connection open to these
> > static variables.
>
> > Is there a way for me to empty certain variables on each run?
> > Specifically, I'd like to undefine params and cookies. I thought that
> > this would work, but it didn't:
>
> > # Parse params into @contents
> > undef @params;
> > undef @contents;
> > @params =3D param;
> > @contents{@params} =3D map param($_) =3D> @params;
>
> > # Fetch cookies, $id =3D $cookies{'ID'}->value;
> > undef %cookies;
> > %cookies =3D fetch CGI::Cookie;
> > foreach $key (keys %cookies) { $cookies{$key} =3D $cookies{$key}-
>
> > >value; }
>
> > TIA,
>
> > Jason
>
> I believe that I stumbled across my own answer.
>
> CPAN states that you can change the shebang line to:
>
> #!/usr/bin/speedy
>
> This seems to work fine, but when I changed it to:
>
> #!/usr/bin/perl
>
> use CGI::SpeedyCGI;
> my $sp =3D CGI::SpeedyCGI->new;
>
> The variables seemed to work the way I expected. I only had to declare
> the ones I wanted to make persistent, and the others died on their
> own. Ie:
>
> my ($dbh); # clear it on first run
> our ($dbh); # keep it persistent for second+ runs
>
> If you have any other insight, I'm all ears. But so far, this seems to
> be working.
Well, I wish I could delete that! Turns out, I had set maxruns to 1
during the testing, so even though it looked like it was working
correctly, it wasn't. My bad.
I'm still looking for advice on how to keep some variables persistent,
but clear others. Here's what I have, and so far it's keeping them all
persistent:
#!/usr/bin/speedy
use CGI::Carp qw(fatalsToBrowser);
use CGI qw(:standard);
use CGI::Cookie;
use strict;
use DBI;
# Hoping to keep persistent
my ($dbh, $home, $basepath, @permissions, $mailprog);
our ($dbh, $home, $basepath, @permissions, $mailprog);
unless (defined($dbh)) { $dbh =3D getSQL(); }
unless (defined($home)) { $home =3D ...; }
unless (defined($basepath)) { $basepath =3D ...; }
unless (defined(@permissions)) { @permissions =3D (...); }
unless (defined($mailprog)) { $mailprog =3D ...; }
# Hoping to change with each run
my (@params, @contents, %cookies);
@params =3D param;
@contents{@params} =3D map param($_) =3D> @params;
%cookies =3D fetch CGI::Cookie;
foreach $key (keys %cookies) { $cookies{$key} =3D $cookies{$key}-
>value; }
# and so on
------------------------------
Date: Fri, 05 Feb 2010 15:56:41 GMT
From: Peter Scott <Peter@PSDT.com>
Subject: Re: Want your opinion on @ARGV file globbing
Message-Id: <ZcXan.22016$aU4.8429@newsfe13.iad>
On Tue, 02 Feb 2010 08:56:40 -0800, jl_post@hotmail.com wrote:
> Happy with this, I sent my script to the person who needed it. He
> responded by saying that "the argument list [was] too long." It turns
> out that the wildcard expression he was using expanded out to nearly
> 16,000 files, which caused the Unix shell he was using to refuse to run
> the resulting (long) command line.
[snip]
> What are your opinions on this? Is there a convention you use that
> addresses this issue? In there an alternate way you prefer to handle
> it?
I would add an option (say, -g) to the program meaning, arguments should
be globbed internally. -g enabled by default on MS Win. Then people in
your user's unusual situation who don't want to or can't use find/xargs
have a solution.
--
Peter Scott
http://www.perlmedic.com/
http://www.perldebugged.com/
http://www.informit.com/store/product.aspx?isbn=0137001274
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 2805
***************************************
