[31597] in Perl-Users-Digest
Perl-Users Digest, Issue: 2856 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun Mar 7 09:09:25 2010
Date: Sun, 7 Mar 2010 06:09:09 -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 Sun, 7 Mar 2010 Volume: 11 Number: 2856
Today's topics:
Re: [OT] HTML standard (was Apache2::Request doesn't wo sln@netherlands.com
Re: [OT] HTML standard (was Apache2::Request doesn't wo <tadmc@seesig.invalid>
Re: Apache2::Request doesn't work as expected <kwan.jingx@gmail.com>
Re: Apache2::Request doesn't work as expected sln@netherlands.com
Re: HTML standard (was Apache2::Request doesn't work as <kwan.jingx@gmail.com>
Re: HTML standard (was Apache2::Request doesn't work as sln@netherlands.com
Re: Is there a "poor man's" perldoc? <m@rtij.nl.invlalid>
Re: Is there a "poor man's" perldoc? sln@netherlands.com
Re: Is there a "poor man's" perldoc? <mvdwege@mail.com>
Re: Is there a "poor man's" perldoc? <hjp-usenet2@hjp.at>
Nickel code ? sln@netherlands.com
Re: Nickel code ? <smallpond@juno.com>
Why does assigning @_ cause sub's parameter to be copie <jerry@ieee.org>
Re: Why does assigning @_ cause sub's parameter to be c <jurgenex@hotmail.com>
Re: Why does assigning @_ cause sub's parameter to be c <uri@StemSystems.com>
Re: Why does assigning @_ cause sub's parameter to be c <devnull4711@web.de>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sat, 06 Mar 2010 19:23:25 -0800
From: sln@netherlands.com
Subject: Re: [OT] HTML standard (was Apache2::Request doesn't work as expected)
Message-Id: <qk66p55s7e0pcfkb83v6b9vrj70bdhajsc@4ax.com>
On Sat, 06 Mar 2010 19:46:05 -0600, Tad McClellan <tadmc@seesig.invalid> wrote:
>smallpond <smallpond@juno.com> wrote:
>
>
>> Single quotes are not used in html.
>
>
>Single quotes are most certainly allowed in HTML.
>
>
> http://www.w3.org/TR/html4/intro/sgmltut.html#h-3.2.2
^^
So xml is a fix on html and '' is grandfathered in.
>
> By default, SGML requires that all attribute values be delimited
> using either double quotation marks (ASCII decimal 34) or single
> quotation marks (ASCII decimal 39).
And now, the king god SGML speaks it, deems it, it!
It is now in stone, and let no man take us'eth er a under.
So beith, as it was and will be, <pause>, or forever hold your peace.. <pause>,
Amen!
So sayeth we all !! Aye...
-sln
------------------------------
Date: Sat, 06 Mar 2010 19:46:05 -0600
From: Tad McClellan <tadmc@seesig.invalid>
Subject: Re: [OT] HTML standard (was Apache2::Request doesn't work as expected)
Message-Id: <slrnhp613n.t5v.tadmc@tadbox.sbcglobal.net>
smallpond <smallpond@juno.com> wrote:
> Single quotes are not used in html.
Single quotes are most certainly allowed in HTML.
http://www.w3.org/TR/html4/intro/sgmltut.html#h-3.2.2
By default, SGML requires that all attribute values be delimited
using either double quotation marks (ASCII decimal 34) or single
quotation marks (ASCII decimal 39).
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.liamg\100cm.j.dat/"
The above message is a Usenet post.
I don't recall having given anyone permission to use it on a Web site.
------------------------------
Date: Sat, 6 Mar 2010 15:19:19 -0800 (PST)
From: kwan <kwan.jingx@gmail.com>
Subject: Re: Apache2::Request doesn't work as expected
Message-Id: <cb54260e-3c34-489a-8ff6-906ea11719fc@q21g2000yqm.googlegroups.com>
On Mar 6, 11:59=A0am, smallpond <smallp...@juno.com> wrote:
> On Mar 5, 6:31=A0pm, kwan <kwan.ji...@gmail.com> wrote:
>
>
>
> > Hello,
>
> > I wrote a mod_perl to check some of the value that users select. The
> > script will generate a form according to the selection from the user.
> > There are three forms that are dynamically generated according to the
> > selection,
> > =A0 =A0 =A0 =A0 =A0in the "display form", there are links to the "add f=
orm" and
> > "modify form".
> > =A0 =A0 =A0 =A0 =A0in the "add form", there are links to the "display f=
orm" and
> > modify form".
> > =A0 =A0 =A0 =A0 =A0in the "modify form", there are links to the display=
form"
> > and "add from".
>
> > In each link, it is like this:
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0http://hostname:80/mainform?sele=
ction=3Ddisplay
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0http://hostname:80/mainform?sele=
ction=3Dmodify
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0http://hostname:80/mainform?sele=
ction=3Dadd
>
> > within the form, I also have the submit form for user to submit the
> > content to the server.
> > the submit form is: <input type=3D"submit" name=3D"selection"
> > value=3D'Add Content'>
>
> > Before, when I use "use CGI" package I can use "param", and the form
> > will be generate and query according to the user submit.
> > Code:
> > =A0 =A0 =A0 =A0 =A0 my $selection =3D lc (param('selection'));
> > =A0 =A0 =A0 =A0 =A0 if ($selection eq "add content") { =A0 =A0}# work w=
ith CGI, but
> > not with Apache2::Request::param
> > =A0 =A0 =A0 =A0 =A0 elsif ($selection eq "modify") {} =A0# work both
> > =A0 =A0 =A0 =A0 =A0 elsif ($selection eq "add") {} =A0 =A0 =A0 # work b=
oth
> > =A0 =A0 =A0 =A0 =A0 elsif ($selection eq "display"){} =A0 # work both
> > =A0 =A0 =A0 =A0 =A0 elsif ($selection eq "modify content"){} # work wit=
h CGI,
> > but not with Apache2::Request:param
>
> > when using CGI, I can get the "param" work according to the user
> > selection. However, when I replace =A0to the following code by using
> > Apache2::Request, when user select modify form, and submit the form.
> > the $r->param('selection') is failed to identify the "modify content"
> > value.
>
> > my $rq =3D new Apache2::Request($r);
> > my $selection =3D lc ($rq->param('selection'));
>
> > I've followed the perldoc Apache2::Request, it isn't much infor about
> > the
> > behavior of the Apache2::Request, as it is mimic the CGI.
>
> Single quotes are not used in html. =A0It should be:
> <input type=3D"submit" name=3D"selection" value=3D"Add Content">
>
> Spaces are excluded by HTTP. =A0It should be encoded as
> "Add%20Content" in the URL. =A0You can print the params to see
> what you are getting.
It doesn't related with that.
------------------------------
Date: Sat, 06 Mar 2010 19:04:19 -0800
From: sln@netherlands.com
Subject: Re: Apache2::Request doesn't work as expected
Message-Id: <qo56p5178pvkm3ob8s5aic1lmacf9gbfkf@4ax.com>
On Sat, 6 Mar 2010 09:59:11 -0800 (PST), smallpond <smallpond@juno.com> wrote:
>Single quotes are not used in html. It should be:
I could care less.
>Spaces are excluded by HTTP. It should be encoded as
I don't know web stuff, just html. Does http exclude spaces?
-sln
------------------------------
Date: Sat, 6 Mar 2010 19:31:17 -0800 (PST)
From: kwan <kwan.jingx@gmail.com>
Subject: Re: HTML standard (was Apache2::Request doesn't work as expected)
Message-Id: <ea454a9d-daee-4548-9f4c-328b80fd3451@33g2000yqj.googlegroups.com>
On Mar 6, 9:23=A0pm, s...@netherlands.com wrote:
> On Sat, 06 Mar 2010 19:46:05 -0600, Tad McClellan <ta...@seesig.invalid> =
wrote:
> >smallpond <smallp...@juno.com> wrote:
>
> >> Single quotes are not used in html.
>
> >Single quotes are most certainly allowed in HTML.
>
> > =A0 =A0http://www.w3.org/TR/html4/intro/sgmltut.html#h-3.2.2
>
> =A0 =A0 =A0^^
> So xml is a fix on html and '' is grandfathered in.
>
>
>
> > =A0 =A0 =A0 =A0By default, SGML requires that all attribute values be d=
elimited
> > =A0 =A0 =A0 =A0using either double quotation marks (ASCII decimal 34) o=
r single
> > =A0 =A0 =A0 =A0quotation marks (ASCII decimal 39).
>
> And now, the king god SGML speaks it, deems it, =A0 it!
> It is now in stone, and let no man take us'eth =A0er a under.
> So beith, as it was and will be, =A0<pause>, or forever hold your peace..=
<pause>,
> Amen!
>
> So sayeth we all !! Aye...
>
> -sln
Probably, it is how Apache2::Request handle the parameters. I am not
sure it is a bug, but hopefully I can find the solution.
I don't really want to mix with Apache2::Request with CGI script.
CGI::param is working fine with the problems that I have described,
but when Apache2::Request::param just doesn't understand the request
at all.
------------------------------
Date: Sat, 06 Mar 2010 19:58:14 -0800
From: sln@netherlands.com
Subject: Re: HTML standard (was Apache2::Request doesn't work as expected)
Message-Id: <hv86p51e3ro4ndv4mjpb6rv4n645vgucaf@4ax.com>
On Sat, 6 Mar 2010 19:31:17 -0800 (PST), kwan <kwan.jingx@gmail.com> wrote:
>On Mar 6, 9:23 pm, s...@netherlands.com wrote:
>> On Sat, 06 Mar 2010 19:46:05 -0600, Tad McClellan <ta...@seesig.invalid> wrote:
>> >smallpond <smallp...@juno.com> wrote:
>>
>> >> Single quotes are not used in html.
>>
>> >Single quotes are most certainly allowed in HTML.
>>
>> > http://www.w3.org/TR/html4/intro/sgmltut.html#h-3.2.2
>>
>> ^^
>> So xml is a fix on html and '' is grandfathered in.
>>
>>
>>
>> > By default, SGML requires that all attribute values be delimited
>> > using either double quotation marks (ASCII decimal 34) or single
>> > quotation marks (ASCII decimal 39).
>>
>> And now, the king god SGML speaks it, deems it, it!
>> It is now in stone, and let no man take us'eth er a under.
>> So beith, as it was and will be, <pause>, or forever hold your peace.. <pause>,
>> Amen!
>>
>> So sayeth we all !! Aye...
>>
>> -sln
>
>Probably, it is how Apache2::Request handle the parameters. I am not
>sure it is a bug, but hopefully I can find the solution.
>I don't really want to mix with Apache2::Request with CGI script.
>CGI::param is working fine with the problems that I have described,
>but when Apache2::Request::param just doesn't understand the request
>at all.
I won't say I could handle or fix your problem. I would say I have been
paid a lot of money to fix problems a lot of experts can't.
-sln
------------------------------
Date: Sat, 6 Mar 2010 22:18:09 +0100
From: Martijn Lievaart <m@rtij.nl.invlalid>
Subject: Re: Is there a "poor man's" perldoc?
Message-Id: <hdta67-cj6.ln1@news.rtij.nl>
On Sat, 06 Mar 2010 10:39:25 -0800, Xho Jingleheimerschmidt wrote:
> I run into this problem frequently. I'm trying to debug something on
> production server, and discover that not only does it not have perldoc
> or man, it also doesn't have top, ps, strace, ltrace, etc. The
> resulting conversation goes something like this:
Oh yes, production servers without man. So I am supposed to "know" all
parameters of those seldom used commands on $SOME_ANCIENT_UNIX and will
never make a mistake, while the hacker that just entered the machine is
seriously hampered by the omission of man pages. Yeah sure.
I call that a production risk. Unfortunately, many risk "professionals"
don't agree with me.
M4
------------------------------
Date: Sat, 06 Mar 2010 14:08:52 -0800
From: sln@netherlands.com
Subject: Re: Is there a "poor man's" perldoc?
Message-Id: <46k5p5hvebi9uj2c2lfe3nj6qhkh1g66lb@4ax.com>
On Sat, 06 Mar 2010 10:39:25 -0800, Xho Jingleheimerschmidt <xhoster@gmail.com> wrote:
>me: "The problem does not manifest on dev servers, only production, so
>it has to be debugged on production."
>
>IT: "That's impossible, the production servers are identical to the dev
>servers."
>
>me: "Obviously not. If they were indentical, then all the debug tools I
>just requested would already be there. They aren't."
>
You lost me with these 3. The debug tools on dev are the only difference
between the two and it doesen't manifest on dev ??
There must be some serious background proceses hooking going on, on dev.
So, you want to put debug tools on production, making it identical to dev?
Thats not a step in the right direction.
-sln
------------------------------
Date: Sun, 07 Mar 2010 12:24:31 +0100
From: Mart van de Wege <mvdwege@mail.com>
Subject: Re: Is there a "poor man's" perldoc?
Message-Id: <86bpf05q8g.fsf@gareth.avalon.lan>
Martijn Lievaart <m@rtij.nl.invlalid> writes:
> On Sat, 06 Mar 2010 10:39:25 -0800, Xho Jingleheimerschmidt wrote:
>
>> I run into this problem frequently. I'm trying to debug something on
>> production server, and discover that not only does it not have perldoc
>> or man, it also doesn't have top, ps, strace, ltrace, etc. The
>> resulting conversation goes something like this:
>
> Oh yes, production servers without man. So I am supposed to "know" all
> parameters of those seldom used commands on $SOME_ANCIENT_UNIX and will
> never make a mistake, while the hacker that just entered the machine is
> seriously hampered by the omission of man pages. Yeah sure.
>
> I call that a production risk. Unfortunately, many risk "professionals"
> don't agree with me.
>
Yes, well, my daily job *is* security.
And I run into a lot of 'consultants' who do security by the book, which
means that rules like 'no extraneous software on production servers' get
implemented in the most hare-brained way possible, and any protest that
you *need* certain tools is met with 'That's a security risk'.
You know, sometimes security is best served by giving an admin the tools
to reduce their response time to an incident. That gives them the time
to ascertain whether the incident is merely an innocent crash or an
actual exploit attempt.
And for that, I often need dev tools and documentation.
Mart
--
"We will need a longer wall when the revolution comes."
--- AJS, quoting an uncertain source.
------------------------------
Date: Sun, 7 Mar 2010 12:47:41 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Is there a "poor man's" perldoc?
Message-Id: <slrnhp74j1.ojo.hjp-usenet2@hrunkner.hjp.at>
On 2010-03-06 22:08, sln@netherlands.com <sln@netherlands.com> wrote:
> On Sat, 06 Mar 2010 10:39:25 -0800, Xho Jingleheimerschmidt <xhoster@gmail.com> wrote:
>
>>me: "The problem does not manifest on dev servers, only production, so
>>it has to be debugged on production."
>>
>>IT: "That's impossible, the production servers are identical to the dev
>>servers."
>>
>>me: "Obviously not. If they were indentical, then all the debug tools I
>>just requested would already be there. They aren't."
>>
>
> You lost me with these 3. The debug tools on dev are the only difference
> between the two and it doesen't manifest on dev ??
No. He didn't say that they are the *only* difference. He said that this
is an *obvious* difference, so saying that prod and dev are identical is
bullshit. The IT department just thinks the differences are irrelevant.
There may be other differences which the IT department thinks are
irrelevant.
One difference between prod and dev which should be obvious to everybody
is:
Users.
The prod system has real users, the dev system doesn't. At best it has a
handful of carefully chosen test users which behave completely
differently than real users.
So you need all the monitoring and debugging aids on prod, because
that's where the problem occurs.
Please note that "monitoring and debugging" is not the same as "making
changes". You need to be free to see what's going on on the production
server, but any change you make must go through proper change
management.
> There must be some serious background proceses hooking going on, on dev.
Huh? I don't understand this sentence.
> So, you want to put debug tools on production, making it identical to dev?
I want the tools I need to find the problem on the server where the
problem occurs. They are useless where the problem doesn't occur. It's
like the old joke about the man who's looking for his keys under a
street lamp:
Passerby: What are you looking for?
Man: My house keys.
Passerby: Did you lose them here?
Man: Probably not. I think I lost them over there.
(points into a dark alley)
Passerby: Then why are you looking here?
Man: Because here I can see.
hp
------------------------------
Date: Sat, 06 Mar 2010 20:22:21 -0800
From: sln@netherlands.com
Subject: Nickel code ?
Message-Id: <0t96p5pe8d1l3iq529hgrejrg6o40tladb@4ax.com>
I am thinking new enterprise so I would like
to start bank accounts for the people raising the
ah , questions on this news group.
I would like to know wheat you think of "Nickel code"
and how the professors get that nickel.
Its not the overall logic that gets the nickel,
its the descreete code that wins the coin.
The an/encounters presenting problems will be subject
to: "Are you willing to pay a nickel to solver your
problem?"
I wan't to graph, the real answers vs the nicle's owed.
-sln (insert lock disabled)
------------------------------
Date: Sun, 7 Mar 2010 06:02:41 -0800 (PST)
From: smallpond <smallpond@juno.com>
Subject: Re: Nickel code ?
Message-Id: <2ffd9581-3c9e-439a-8691-4873788d56dd@g28g2000yqh.googlegroups.com>
On Mar 6, 11:22=A0pm, s...@netherlands.com wrote:
> I am thinking =A0new enterprise so I would like
> to start bank accounts for the people raising the
> ah , questions on this news group.
>
> I would like to know wheat you think of "Nickel code"
> and how the professors get that nickel.
>
> Its not the overall logic that gets the nickel,
> its the descreete code =A0that wins the coin.
>
> The an/encounters presenting problems will be subject
> to: "Are you willing to pay a nickel to solver your
> problem?"
>
> I wan't to graph, the real answers vs the nicle's owed.
>
I think the original submitter puts up a nickel.
Each answer has to put in a nickel also.
Correct answers split the pot.
With this scheme I would just about break even while Ben Morrow,
Tad McLellan, etc. would be a millionaires. Seems fair.
------------------------------
Date: Sat, 6 Mar 2010 22:35:47 -0800 (PST)
From: Jerry Krinock <jerry@ieee.org>
Subject: Why does assigning @_ cause sub's parameter to be copied?
Message-Id: <5a56a323-ea50-4124-967c-349c21dbe908@a10g2000pri.googlegroups.com>
After several hours of head-scratching, I finally found out why I
changes I made to an array passed by reference to a subroutine are not
seen outside the subroutine, thanks to Steve Litt's Perls of Wisdom
[1]:
"Any change the subroutine performs to @_ or any of its members like
$_[0], $_[1], etc, are changes to the original argument. HOWEVER,
assigning @_ or its elements to other variables makes a separate copy.
Changes to the separate copy are unknown outside of the subroutine."
Maybe if someone could explain the reason why Perl would do this, make
a copy upon *assignment*, it would be easier for me to remember. Is
this a "feature" of the language, or some unfortunate implementation
reality? The reason why I discovered this is that since I'm not a
full-time Perl guy, I try and write readable code, defining lots of
variables. However, as you can see from my code below, my nice and
pedantic subroutine pushBad() doesn't work because it makes a local
assignment, but the hard-to-read pushGood() works.
Thanks for any insights!
Jerry Krinock
1. http://www.troubleshooters.com/codecorn/littperl/perlsub.htm.
Steve apparently knows it well; he repeated that text in six places on
this page :))
#!/usr/bin/perl
use strict ;
my @array = ("start") ;
pushBad(\@array) ;
print("Passed back from pushBad: @array\n") ;
pushGood(\@array) ;
print("Passed back from pushGood: @array\n") ;
sub pushBad {
my $arrayRef = shift ;
my @array = @$arrayRef ;
push (@array, "bad") ;
print("After pushing, in pushBad: @array\n") ;
}
sub pushGood {
push(@{$_[0]}, "good") ;
print("After pushing, in pushGood: @{$_[0]}\n") ;
}
CONSOLE OUTPUT:
After pushing, in pushBad: start bad
Passed back from pushBad: start
After pushing, in pushGood: start good
Passed back from pushGood: start good
------------------------------
Date: Sat, 06 Mar 2010 23:25:06 -0800
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Why does assigning @_ cause sub's parameter to be copied?
Message-Id: <aik6p5lqi2h0um28h2dhe9t2oo5t48mlag@4ax.com>
Jerry Krinock <jerry@ieee.org> wrote:
>"Any change the subroutine performs to @_ or any of its members like
>$_[0], $_[1], etc, are changes to the original argument. HOWEVER,
>assigning @_ or its elements to other variables makes a separate copy.
>Changes to the separate copy are unknown outside of the subroutine."
>
>Maybe if someone could explain the reason why Perl would do this, make
>a copy upon *assignment*, it would be easier for me to remember.
Imagine the following code:
@foo = qw 'Original content of foo';
@bar = @foo;
@bar = qw 'New content';
Now, which content do you expect @foo to have?
>sub pushBad {
> my $arrayRef = shift ;
> my @array = @$arrayRef ;
> push (@array, "bad") ;
> print("After pushing, in pushBad: @array\n") ;
>}
And your sample code here is exactly the same as my snippet above except
that instead of an array @foo you got an array @$arrayRef, i.e. one
level of reference. But otherwise they do the same thing: assigning an
array to another array and there is no reason why changing the elements
in the second array should be mirrored in the original array.
jue
------------------------------
Date: Sun, 07 Mar 2010 02:56:44 -0500
From: "Uri Guttman" <uri@StemSystems.com>
Subject: Re: Why does assigning @_ cause sub's parameter to be copied?
Message-Id: <87iq98won7.fsf@quad.sysarch.com>
>>>>> "JK" == Jerry Krinock <jerry@ieee.org> writes:
JK> 1. http://www.troubleshooters.com/codecorn/littperl/perlsub.htm.
JK> Steve apparently knows it well; he repeated that text in six places on
JK> this page :))
he knows what well? that page is ancient perl style. why are you
learning from it instead of a good book or the perl docs? almost every
perl tutorial on the web is poorly written, inaccurate, buggy and
worse. i have reviewed dozens and they all seem to be similarly bad. the
fact that this page shows &foo style calls is indicative of its low
quality.
I have been unable to hack into a subroutine via its scalar
return. If you know of a way it can be done, please let me know,
as this would be a horrid violation of encapsulation.
what kind of a moronic statement is that? regardless of whether it can
be done or not, it is just dumb to write that.
Returning a List
sub getFnameLname
{
return("Bill", "Clinton");
}
that only returns a list in list context. no use describing sub returns
without covering context as well. typical bad web tute stuff.
Returning a Hash
sub getOfficers
{
return("president"=>"Bill Clinton",
"vice president"=>"Al Gore",
"intern"=>"Monica Lewinsky"
);
that isn't actually returning a hash which can't be done. it is
returning a list (assuming list context as mentioned above) and it may
be assigned to a hash whereby that list will be converted to a hash.
Arguments to a subroutine are accessible inside the subroutine
as list @_. Any change the subroutine performs to @_ or any of
its members like $_[0], $_[1], etc, are changes to the original
argument. HOWEVER, assigning @_ or its elements to other
variables makes a separate copy. Changes to the separate copy
are unknown outside of the subroutine.
what a maroon! the usual idiom is always assigning @_ to
lexicals. instead he starts off with call by reference stuff which is
rarely used. passing real refs is the correct and safe way to do
that. ugh.
JK> #!/usr/bin/perl
JK> use strict ;
JK> my @array = ("start") ;
JK> pushBad(\@array) ;
JK> print("Passed back from pushBad: @array\n") ;
JK> pushGood(\@array) ;
JK> print("Passed back from pushGood: @array\n") ;
JK> sub pushBad {
JK> my $arrayRef = shift ;
that is still the original array ref
JK> my @array = @$arrayRef ;
HERE you copied the array to a lexical. all changes to @array will
remain there.
JK> push (@array, "bad") ;
why would you expect this to change the original array? what possible
way would you think that would happen? you COPIED the array, not a reference.
JK> print("After pushing, in pushBad: @array\n") ;
JK> }
JK> sub pushGood {
JK> push(@{$_[0]}, "good") ;
JK> print("After pushing, in pushGood: @{$_[0]}\n") ;
JK> }
and that is the bad way to pass by reference.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: Sun, 07 Mar 2010 12:21:19 +0100
From: Frank Seitz <devnull4711@web.de>
Subject: Re: Why does assigning @_ cause sub's parameter to be copied?
Message-Id: <7vhghfFblbU1@mid.individual.net>
Jerry Krinock wrote:
> After several hours of head-scratching, I finally found out why I
> changes I made to an array passed by reference to a subroutine are not
> seen outside the subroutine, thanks to Steve Litt's Perls of Wisdom
> [1]:
>
> "Any change the subroutine performs to @_ or any of its members like
> $_[0], $_[1], etc, are changes to the original argument. HOWEVER,
> assigning @_ or its elements to other variables makes a separate copy.
> Changes to the separate copy are unknown outside of the subroutine."
>
> Maybe if someone could explain the reason why Perl would do this, make
> a copy upon *assignment*, it would be easier for me to remember. Is
> this a "feature" of the language, or some unfortunate implementation
> reality? The reason why I discovered this is that since I'm not a
> full-time Perl guy, I try and write readable code, defining lots of
> variables. However, as you can see from my code below, my nice and
> pedantic subroutine pushBad() doesn't work because it makes a local
> assignment, but the hard-to-read pushGood() works.
>
> Thanks for any insights!
>
> Jerry Krinock
>
> 1. http://www.troubleshooters.com/codecorn/littperl/perlsub.htm.
> Steve apparently knows it well; he repeated that text in six places on
> this page :))
>
> #!/usr/bin/perl
> use strict ;
>
> my @array = ("start") ;
> pushBad(\@array) ;
> print("Passed back from pushBad: @array\n") ;
> pushGood(\@array) ;
> print("Passed back from pushGood: @array\n") ;
>
> sub pushBad {
> my $arrayRef = shift ;
> my @array = @$arrayRef ;
> push (@array, "bad") ;
> print("After pushing, in pushBad: @array\n") ;
> }
>
> sub pushGood {
> push(@{$_[0]}, "good") ;
> print("After pushing, in pushGood: @{$_[0]}\n") ;
> }
Readable call by reference code in Perl:
sub pushGood {
my $arrayRef = shift;
push(@$arrayRef, "good");
print("After pushing, in pushGood: @$arrayRef\n") ;
}
Frank
--
Dipl.-Inform. Frank Seitz
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel
Blog: http://www.fseitz.de/blog
XING-Profil: http://www.xing.com/profile/Frank_Seitz2
------------------------------
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 2856
***************************************
