[32608] in Perl-Users-Digest
Perl-Users Digest, Issue: 3881 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat Feb 16 16:09:24 2013
Date: Sat, 16 Feb 2013 13:09:07 -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 Sat, 16 Feb 2013 Volume: 11 Number: 3881
Today's topics:
Apache 2.2 & Perl CGI::Simple running under separate ui <oneingray@gmail.com>
Re: Apache 2.2 & Perl CGI::Simple running under separat <ben@morrow.me.uk>
Re: Apache 2.2 & Perl CGI::Simple running under separat <vilain@NOspamcop.net>
Re: Apache 2.2 & Perl CGI::Simple running under separat <ben@morrow.me.uk>
Re: Apache 2.2 & Perl CGI::Simple running under separat <vilain@NOspamcop.net>
Re: Apache 2.2 & Perl CGI::Simple running under separat <ben@morrow.me.uk>
Re: Apache 2.2 & Perl CGI::Simple running under separat <nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam>
Re: Apache 2.2 & Perl CGI::Simple running under separat <rweikusat@mssgmbh.com>
assignments of arrays <toralf.foerster@gmx.de>
Re: assignments of arrays <news@lawshouse.org>
Re: assignments of arrays <nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam>
Re: assignments of arrays <nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam>
Re: assignments of arrays <toralf.foerster@gmx.de>
Re: assignments of arrays <news@lawshouse.org>
Re: assignments of arrays <ben@morrow.me.uk>
Re: assignments of arrays <nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 15 Feb 2013 20:45:47 +0000
From: Ivan Shmakov <oneingray@gmail.com>
Subject: Apache 2.2 & Perl CGI::Simple running under separate uid's: SCGI? FCGI? PSGI?
Message-Id: <87zjz5cnlw.fsf@violet.siamics.net>
Is there an easy way to run Perl CGI::Simple-based code
interfacing Apache 2.2, under a separate UID? (Apart of suexec,
that is, which, depending on the circumstances, may or may not
constitute "an easy way.") I'd like to make the code
"persistent" as well, but it's not a hard requirement for now.
I've been thinking of using mod_scgi on the Apache's side and
SCGI on Perl's, but I don't seem much work done on either in the
last five years or so.
AIUI, the SCGI specification allows the server to pass pretty
much the same information to the "CGI" code as does CGI proper,
thus, perhaps, it'd be possible for CGI::Simple (upon which my
existing code is based) to support it with little change. Also,
it may make sense to check if Apache's mod_scgi can be adapted
to allow for a Unix domain socket (AF_UNIX) to be used (instead
of AF_INET6 or AF_INET.)
The FCGI Perl module and mod_fcgi look like a bit more promising
a couple, as they seem to support AF_UNIX sockets "out of box."
Are there any issues likely to arise with them?
Finally, should I consider a PSGI implementation (Plack?) along
with Apache for my purpose? Should I use, say,
Plack::Handler::FCGI, for instance?
TIA.
PS. It's possible that I'll consider switching from Apache to Lighttpd
later, so I wonder if there could be any "CGI-like" interfaces
implemented for both of these HTTP servers?
--
FSF associate member #7257
------------------------------
Date: Fri, 15 Feb 2013 23:15:01 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Apache 2.2 & Perl CGI::Simple running under separate uid's: SCGI? FCGI? PSGI?
Message-Id: <l4s2v9-p86.ln1@anubis.morrow.me.uk>
[f'ups set to clpmisc]
Quoth Ivan Shmakov <oneingray@gmail.com>:
> Is there an easy way to run Perl CGI::Simple-based code
> interfacing Apache 2.2, under a separate UID? (Apart of suexec,
> that is, which, depending on the circumstances, may or may not
> constitute "an easy way.") I'd like to make the code
> "persistent" as well, but it's not a hard requirement for now.
>
> I've been thinking of using mod_scgi on the Apache's side and
> SCGI on Perl's, but I don't seem much work done on either in the
> last five years or so.
Are you considering changing the code which calls CGI::Simple, or are
you trying to avoid that?
> AIUI, the SCGI specification allows the server to pass pretty
> much the same information to the "CGI" code as does CGI proper,
> thus, perhaps, it'd be possible for CGI::Simple (upon which my
> existing code is based) to support it with little change. Also,
> it may make sense to check if Apache's mod_scgi can be adapted
> to allow for a Unix domain socket (AF_UNIX) to be used (instead
> of AF_INET6 or AF_INET.)
I have no experience with SCGI.
> The FCGI Perl module and mod_fcgi look like a bit more promising
> a couple, as they seem to support AF_UNIX sockets "out of box."
> Are there any issues likely to arise with them?
IME FastCGI with FCGI.pm is extremely reliable. I use it either via
Plack or via Catalyst (which uses Plack these days).
> Finally, should I consider a PSGI implementation (Plack?) along
> with Apache for my purpose? Should I use, say,
> Plack::Handler::FCGI, for instance?
That would be my recommendation. With modules like Plack::App::CGIBin
and CGI::PSGI or CGI::Emulate::PSGI you can probably avoid even having
to change your existing code, or at least migrate it to Plack later. If
your app is small you can migrate it to using Plack::Request directly;
if it's any size that isn't recommended, you're encouraged to use
another layer on top of Plack.
> PS. It's possible that I'll consider switching from Apache to Lighttpd
> later, so I wonder if there could be any "CGI-like" interfaces
> implemented for both of these HTTP servers?
Both Lighty and nginx (which you should consider as an alternative to
lighty) have good FastCGI support. They also both have good HTTP proxy
support, which is quite a common way to run persistent web apps these
days; basically you use HTTP as the app-to-server protocol as well as
the server-to-client protocol. The principal advantage of PSGI is that
you can switch to a different server protocol without any fuss.
Ben
------------------------------
Date: Fri, 15 Feb 2013 17:06:02 -0800
From: Michael Vilain <vilain@NOspamcop.net>
Subject: Re: Apache 2.2 & Perl CGI::Simple running under separate uid's: SCGI? FCGI? PSGI?
Message-Id: <vilain-5AE6F2.17060215022013@news.individual.net>
In article <l4s2v9-p86.ln1@anubis.morrow.me.uk>,
Ben Morrow <ben@morrow.me.uk> wrote:
> [f'ups set to clpmisc]
>
> Quoth Ivan Shmakov <oneingray@gmail.com>:
> > Is there an easy way to run Perl CGI::Simple-based code
> > interfacing Apache 2.2, under a separate UID? (Apart of suexec,
> > that is, which, depending on the circumstances, may or may not
> > constitute "an easy way.") I'd like to make the code
> > "persistent" as well, but it's not a hard requirement for now.
> >
> > I've been thinking of using mod_scgi on the Apache's side and
> > SCGI on Perl's, but I don't seem much work done on either in the
> > last five years or so.
>
> Are you considering changing the code which calls CGI::Simple, or are
> you trying to avoid that?
>
> > AIUI, the SCGI specification allows the server to pass pretty
> > much the same information to the "CGI" code as does CGI proper,
> > thus, perhaps, it'd be possible for CGI::Simple (upon which my
> > existing code is based) to support it with little change. Also,
> > it may make sense to check if Apache's mod_scgi can be adapted
> > to allow for a Unix domain socket (AF_UNIX) to be used (instead
> > of AF_INET6 or AF_INET.)
>
> I have no experience with SCGI.
>
> > The FCGI Perl module and mod_fcgi look like a bit more promising
> > a couple, as they seem to support AF_UNIX sockets "out of box."
> > Are there any issues likely to arise with them?
>
> IME FastCGI with FCGI.pm is extremely reliable. I use it either via
> Plack or via Catalyst (which uses Plack these days).
>
> > Finally, should I consider a PSGI implementation (Plack?) along
> > with Apache for my purpose? Should I use, say,
> > Plack::Handler::FCGI, for instance?
>
> That would be my recommendation. With modules like Plack::App::CGIBin
> and CGI::PSGI or CGI::Emulate::PSGI you can probably avoid even having
> to change your existing code, or at least migrate it to Plack later. If
> your app is small you can migrate it to using Plack::Request directly;
> if it's any size that isn't recommended, you're encouraged to use
> another layer on top of Plack.
>
> > PS. It's possible that I'll consider switching from Apache to Lighttpd
> > later, so I wonder if there could be any "CGI-like" interfaces
> > implemented for both of these HTTP servers?
>
> Both Lighty and nginx (which you should consider as an alternative to
> lighty) have good FastCGI support. They also both have good HTTP proxy
> support, which is quite a common way to run persistent web apps these
> days; basically you use HTTP as the app-to-server protocol as well as
> the server-to-client protocol. The principal advantage of PSGI is that
> you can switch to a different server protocol without any fuss.
>
> Ben
If you want to run a CGI program as a different user than the default
UID of the web server, you can use CGIWrap. It's been around forever
and just works. There may be something more modern out there, but the
last time I came across a need to run scripts as my UID on a shared
machine, this was it.
http://cgiwrap.sourceforge.net/
--
DeeDee, don't press that button! DeeDee! NO! Dee...
[I filter all Goggle Groups posts, so any reply may be automatically ignored]
------------------------------
Date: Sat, 16 Feb 2013 02:38:51 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Apache 2.2 & Perl CGI::Simple running under separate uid's: SCGI? FCGI? PSGI?
Message-Id: <r283v9-qp8.ln1@anubis.morrow.me.uk>
Quoth Michael Vilain <vilain@NOspamcop.net>:
> In article <l4s2v9-p86.ln1@anubis.morrow.me.uk>,
> Ben Morrow <ben@morrow.me.uk> wrote:
>
> > Quoth Ivan Shmakov <oneingray@gmail.com>:
> > > Is there an easy way to run Perl CGI::Simple-based code
> > > interfacing Apache 2.2, under a separate UID? (Apart of suexec,
> > > that is, which, depending on the circumstances, may or may not
> > > constitute "an easy way.") I'd like to make the code
> > > "persistent" as well, but it's not a hard requirement for now.
<snip>
>
> If you want to run a CGI program as a different user than the default
> UID of the web server, you can use CGIWrap. It's been around forever
> and just works. There may be something more modern out there, but the
> last time I came across a need to run scripts as my UID on a shared
> machine, this was it.
>
> http://cgiwrap.sourceforge.net/
Ummmmm....:
| CGIwrap needs to be installed set-uid to root. Log in as root, change
| to the server's cgi-bin directory, and issue the commands:
|
| chown root cgiwrap
| chmod 4755 cgiwrap
No. Not a good plan.
Ben
------------------------------
Date: Fri, 15 Feb 2013 19:44:39 -0800
From: Michael Vilain <vilain@NOspamcop.net>
Subject: Re: Apache 2.2 & Perl CGI::Simple running under separate uid's: SCGI? FCGI? PSGI?
Message-Id: <vilain-933E7B.19443815022013@news.individual.net>
In article <r283v9-qp8.ln1@anubis.morrow.me.uk>,
Ben Morrow <ben@morrow.me.uk> wrote:
> Quoth Michael Vilain <vilain@NOspamcop.net>:
> > In article <l4s2v9-p86.ln1@anubis.morrow.me.uk>,
> > Ben Morrow <ben@morrow.me.uk> wrote:
> >
> > > Quoth Ivan Shmakov <oneingray@gmail.com>:
> > > > Is there an easy way to run Perl CGI::Simple-based code
> > > > interfacing Apache 2.2, under a separate UID? (Apart of suexec,
> > > > that is, which, depending on the circumstances, may or may not
> > > > constitute "an easy way.") I'd like to make the code
> > > > "persistent" as well, but it's not a hard requirement for now.
> <snip>
> >
> > If you want to run a CGI program as a different user than the default
> > UID of the web server, you can use CGIWrap. It's been around forever
> > and just works. There may be something more modern out there, but the
> > last time I came across a need to run scripts as my UID on a shared
> > machine, this was it.
> >
> > http://cgiwrap.sourceforge.net/
>
> Ummmmm....:
>
> | CGIwrap needs to be installed set-uid to root. Log in as root, change
> | to the server's cgi-bin directory, and issue the commands:
> |
> | chown root cgiwrap
> | chmod 4755 cgiwrap
>
> No. Not a good plan.
>
> Ben
With Unix' permissions strategy, some process is going to have to be
root to change your process to another UID. That's the way it works.
When Apache starts, it changes it's UID to the web user set in apache
.conf file.
You can run stuff as a thread under Apache's control but I don't know if
there's a mod that will do what you want (along with a way to administer
it).
As a CGI process, UNIX won't let processes with the web UID spawn other
user's UIDs. CGIwrap will do what you ask.
Or you run in a non-shared environment where you don't need to change to
another UID.
Why do you need to run as another UID?
--
DeeDee, don't press that button! DeeDee! NO! Dee...
[I filter all Goggle Groups posts, so any reply may be automatically ignored]
------------------------------
Date: Sat, 16 Feb 2013 05:14:30 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Apache 2.2 & Perl CGI::Simple running under separate uid's: SCGI? FCGI? PSGI?
Message-Id: <m6h3v9-ckc.ln1@anubis.morrow.me.uk>
Quoth Michael Vilain <vilain@NOspamcop.net>:
> In article <r283v9-qp8.ln1@anubis.morrow.me.uk>,
> Ben Morrow <ben@morrow.me.uk> wrote:
> > Quoth Michael Vilain <vilain@NOspamcop.net>:
> > > In article <l4s2v9-p86.ln1@anubis.morrow.me.uk>,
> > >
> > > If you want to run a CGI program as a different user than the default
> > > UID of the web server, you can use CGIWrap. It's been around forever
> > > and just works. There may be something more modern out there, but the
> > > last time I came across a need to run scripts as my UID on a shared
> > > machine, this was it.
> > >
> > > http://cgiwrap.sourceforge.net/
> >
> > Ummmmm....:
> >
> > | CGIwrap needs to be installed set-uid to root. Log in as root, change
> > | to the server's cgi-bin directory, and issue the commands:
> > |
> > | chown root cgiwrap
> > | chmod 4755 cgiwrap
> >
> > No. Not a good plan.
>
> With Unix' permissions strategy, some process is going to have to be
> root to change your process to another UID. That's the way it works.
> When Apache starts, it changes it's UID to the web user set in apache
> .conf file.
'Starting as root, from a controlled environment, and permanently
switching down to an unprivileged uid before doing anything dangerous'
and 'running setid root from a potentially attacker-controlled
environment' are very different security situations. Making a CGI
program setid root is very stupid; doing so with a program *designed* to
be able to run arbitrary commands under arbitrary uids is just insane.
What happens if there's an exploitable security hole in cgiwrap? (This
is a possibility you *must* consider. Any non-trivial piece of software
potentially contains exploitable security holes, and any piece of
software which changes uid is non-trivial.) You've just given an
attacker root over the network. What if *any* other process on the
machine is compromised? You've just given them a way to elevate that to
a root compromise.
This is why suidperl was eventually retired: it became too hard to keep
it secure in the face of all the different ways it might be invoked.
Making things setuid is nearly always a mistake; there is nearly always
a better solution.
> You can run stuff as a thread under Apache's control but I don't know if
> there's a mod that will do what you want (along with a way to administer
> it).
>
> As a CGI process, UNIX won't let processes with the web UID spawn other
> user's UIDs. CGIwrap will do what you ask.
You shouldn't be trying to spawn processes from the web server in the
first place (again, an attacker has much more influence over this
environment than over that provided by /etc/rc). Run them separately,
under their own uids, and have the web server talk to them with FastCGI
or HTTP.
> Or you run in a non-shared environment where you don't need to change to
> another UID.
>
> Why do you need to run as another UID?
You should run any process which talks directly to the network under a
unique uid, and as far as possible move all actual work out to other
processes under other uids. You should assume any process which talks
directly to the network is liable to be completely compromised, and
restrict its access to the rest of the system accordingly.
Ben
------------------------------
Date: Sat, 16 Feb 2013 13:29:23 +0200
From: "George Mpouras" <nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam>
Subject: Re: Apache 2.2 & Perl CGI::Simple running under separate uid's: SCGI? FCGI? PSGI?
Message-Id: <kfnqii$u64$1@news.ntua.gr>
out of topic but have you look the dander ?
http://perldancer.org
------------------------------
Date: Sat, 16 Feb 2013 20:16:41 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Apache 2.2 & Perl CGI::Simple running under separate uid's: SCGI? FCGI? PSGI?
Message-Id: <87bobkdnfa.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Michael Vilain <vilain@NOspamcop.net>:
>> Ben Morrow <ben@morrow.me.uk> wrote:
>> > Quoth Michael Vilain <vilain@NOspamcop.net>:
[...]
>> > > http://cgiwrap.sourceforge.net/
>> >
>> > Ummmmm....:
>> >
>> > | CGIwrap needs to be installed set-uid to root. Log in as root, change
>> > | to the server's cgi-bin directory, and issue the commands:
>> > |
>> > | chown root cgiwrap
>> > | chmod 4755 cgiwrap
>> >
>> > No. Not a good plan.
>>
>> With Unix' permissions strategy, some process is going to have to be
>> root to change your process to another UID.
[...]
> 'Starting as root, from a controlled environment, and permanently
> switching down to an unprivileged uid before doing anything dangerous'
> and 'running setid root from a potentially attacker-controlled
> environment' are very different security situations. Making a CGI
> program setid root is very stupid; doing so with a program *designed* to
> be able to run arbitrary commands under arbitrary uids is just
> insane.
As Michael already wrote: There is no other option when something
executed via CGI is supposed to perform some task the user the web
server runs as cannot perform. Since there is no reason why the
wrapper should do anything with any information in its runtime
environment because its job is just to change to a specific user id
and execute another file, it's exploitable surface ought to be
non-existent.
> What happens if there's an exploitable security hole in cgiwrap? (This
> is a possibility you *must* consider. Any non-trivial piece of software
> potentially contains exploitable security holes, and any piece of
> software which changes uid is non-trivial.)
'Changing the UID' is a single system call. This is trivial.
> You've just given an attacker root over the network. What if *any*
> other process on the machine is compromised? You've just given them
> a way to elevate that to a root compromise.
That's all nice and dandy but since the "dangerous situation" can't be
avoided for technical reasons, there is no other choice but "try to
get it right" (I have no idea how the cgiwrap code looks like but
unless you can point at an actual problem with it, this is an entirely
theoretic discussion hanging in the air).
[...]
>> You can run stuff as a thread under Apache's control but I don't know if
>> there's a mod that will do what you want (along with a way to administer
>> it).
>>
>> As a CGI process, UNIX won't let processes with the web UID spawn other
>> user's UIDs. CGIwrap will do what you ask.
>
> You shouldn't be trying to spawn processes from the web server in the
> first place (again, an attacker has much more influence over this
> environment than over that provided by /etc/rc). Run them separately,
> under their own uids, and have the web server talk to them with FastCGI
> or HTTP.
And why precisely shouldn't 'the web server' fork helper processes,
possibly, helper processes executing special purpose auxiliary
programs?
NB: I'm aware that there's at least one 'good reason' why it shouldn't
do this for 'certain Perl code': The cost of compiling a large amount
of non-trivial auxiliary modules, eg, Moose, can easily become
dominant (and intolerable) for a short-lived process, especially, a
frequently started short-lived process. But this just means the
'5,000,000 lines of CPAN in order to print "Hello, World!"'-approach
for Perl development is unsuitable for CGI programs.
[...]
>> Why do you need to run as another UID?
>
> You should run any process which talks directly to the network under a
> unique uid, and as far as possible move all actual work out to other
> processes under other uids. You should assume any process which talks
> directly to the network is liable to be completely compromised, and
> restrict its access to the rest of the system accordingly.
I don't think I should perform all kinds of 'configuration voodoo' in the
hope that it will keep me safe from nebulous "unknown dangers",
especially if this configuration voodoo involves running a lot of
complicated code which may well have its own 'exploitable
errors'. Bugs which are discovered need to be fixed and the only way
to be 'safe' from 'yet unknown future dangers' is 'immediate suicide'.
------------------------------
Date: Fri, 15 Feb 2013 19:01:05 +0100
From: =?UTF-8?B?VG9yYWxmIEbDtnJzdGVy?= <toralf.foerster@gmx.de>
Subject: assignments of arrays
Message-Id: <kflt3j$sqj$1@dont-email.me>
In the following program I'd expect that line 29 fills @Values with zeros, but for i==2 this is counterproofed.
Why ?
$ nl -ba zero.pl
1 #!/usr/bin/perl
2
3 # Toralf Förster
4 # Hamburg
5 # Germany
6
7 use strict;
8 use diagnostics;
9 $diagnostics::PRETTY = 1;
10
11 use warnings FATAL => 'uninitialized';
12 use Carp ();
13 $SIG{__DIE__} = \&Carp::confess;
14
15
16 my $Cols = 30;
17 my $Rows = 16;
18
19 my @Zero = ();
20 foreach my $r (0..$Rows+1) {
21 foreach my $c (0..$Cols+1) {
22 $Zero[$r][$c] = 0;
23 }
24 }
25
26 my $N = 10;
27 foreach my $i (1..$N) {
28
29 my @Values = @Zero;
30
31 foreach my $r (0..$Rows+1) {
32 foreach my $c (0..$Cols+1) {
33 if ($Values[$r][$c] != 0) {
34 die "i=$i\tr=$r\tc=$c\t$Values[$r][$c]\n";
35 }
36 }
37 }
38
39 foreach my $r (0..$Rows+1) {
40 foreach my $c (0..$Cols+1) {
41 $Values[$r][$c] = 1;
42 }
43 }
44 }
45
46
47 exit (0);
48
tfoerste@n22 ~/workspace/misc $ ./zero.pl
i=2 r=0 c=0 1
at ./zero.pl line 34
--
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
------------------------------
Date: Fri, 15 Feb 2013 18:42:48 +0000
From: Henry Law <news@lawshouse.org>
Subject: Re: assignments of arrays
Message-Id: <cpednXby9og1HIPMnZ2dnUVZ8vWdnZ2d@giganews.com>
On 15/02/13 18:01, Toralf Förster wrote:
> In the following program I'd expect that line 29 fills @Values with zeros, but for i==2 this is counterproofed.
Why do you expect that? @Zero is a two-dimensional array (a list of
lists); when you do the assignment in your line 29 then @Values becomes
an identical array.
> 19 my @Zero = ();
> 20 foreach my $r (0..$Rows+1) {
> 21 foreach my $c (0..$Cols+1) {
> 22 $Zero[$r][$c] = 0;
> 23 }
> 24 }
> 25
> 26 my $N = 10;
> 27 foreach my $i (1..$N) {
> 28
> 29 my @Values = @Zero;
Try running this and you'll see what's happening:
-----------------
use strict;
use warnings;
use Data::Dumper;
my ($Rows,$Cols) = (1,2);
my @Zero = ();
foreach my $r (0..$Rows+1){
foreach my $c (0..$Cols+1){
$Zero[$r][$c] = 0;
}
}
print Dumper \@Zero;
my @thing = @Zero;
print Dumper \@thing;
-----------------
May I make some suggestions on how to get the best from this group? (1)
Please provide code that can be copied and pasted; those line numbers
get in the way (at least they do in Thunderbird).
(2) Well done for not saying that your code "doesn't work" ... but an
additional thing would have been to say "... that line 29 fills @Values
with zeros but instead it produces ...". I think if you'd investigated
what did happen then you'd have seen your own problem.
--
Henry Law Manchester, England
------------------------------
Date: Fri, 15 Feb 2013 21:07:40 +0200
From: "George Mpouras" <nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam>
Subject: Re: assignments of arrays
Message-Id: <kfm11u$2bab$1@news.ntua.gr>
Be carefull Toralf Förster.
At your statement my @Values = @Zero;
you are "playing" with array references.
So when you fill the @Values with 1 what you are doing is at the same time
to fill the @Zero with 1
what you must do , to have what you mean is the following:
George Bouras
Athens, Greece
...
my $N = 10;
foreach my $i (1..$N)
{
my @Values = ();
for (my $i=0;$i<=$#Zero;$i++)
{
for (my $j=0;$j<=$#{$Zero[$i]};$j++)
{
$Values[$i][$j] = $Zero[$i][$j]
}
}
foreach my $r (0..$Rows+1)
{
foreach my $c (0..$Cols+1)
{
print "i=$i\tr=$r\tc=$c\t$Values[$r][$c]\n";
if ($Values[$r][$c] != 0) { die
"i=$i\tr=$r\tc=$c\t$Values[$r][$c]\n"; }
}
}
foreach my $r (0..$Rows+1) {
foreach my $c (0..$Cols+1) {
$Values[$r][$c] = 1 } }
}
exit 0;
------------------------------
Date: Fri, 15 Feb 2013 21:09:48 +0200
From: "George Mpouras" <nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam>
Subject: Re: assignments of arrays
Message-Id: <kfm15t$2bj3$1@news.ntua.gr>
Henry, try to avoid the hardcoded values of $Rows and $Cols by using the
array offsets !
Ο "Henry Law" έγραψε στο μήνυμα
news:cpednXby9og1HIPMnZ2dnUVZ8vWdnZ2d@giganews.com...
On 15/02/13 18:01, Toralf Förster wrote:
> In the following program I'd expect that line 29 fills @Values with zeros,
> but for i==2 this is counterproofed.
> 19 my @Zero = ();
> 20 foreach my $r (0..$Rows+1) {
> 21 foreach my $c (0..$Cols+1) {
> 22 $Zero[$r][$c] = 0;
> 23 }
> 24 }
------------------------------
Date: Fri, 15 Feb 2013 20:29:36 +0100
From: =?UTF-8?B?VG9yYWxmIEbDtnJzdGVy?= <toralf.foerster@gmx.de>
Subject: Re: assignments of arrays
Message-Id: <kfm29i$tbp$1@dont-email.me>
On 02/15/2013 08:07 PM, George Mpouras wrote:
> you are "playing" with array references.
> So when you fill the @Values with 1 what you are doing is at the same
> time to fill the @Zero with 1
ick
@all
thx for the explanation
--
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
------------------------------
Date: Fri, 15 Feb 2013 22:47:04 +0000
From: Henry Law <news@lawshouse.org>
Subject: Re: assignments of arrays
Message-Id: <H8GdnZ_2jKd0J4PMnZ2dnUVZ8l-dnZ2d@giganews.com>
On 15/02/13 19:09, George Mpouras wrote:
> Henry, try to avoid the hardcoded values of $Rows and $Cols by using
> the array offsets !
Of course. It was just for convenience in showing the OP what's happening.
--
Henry Law Manchester, England
------------------------------
Date: Fri, 15 Feb 2013 22:57:16 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: assignments of arrays
Message-Id: <c3r2v9-c06.ln1@anubis.morrow.me.uk>
Quoth "George Mpouras" <nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam>:
> Be carefull Toralf Förster.
> At your statement my @Values = @Zero;
> you are "playing" with array references.
> So when you fill the @Values with 1 what you are doing is at the same time
> to fill the @Zero with 1
> what you must do , to have what you mean is the following:
>
> my $N = 10;
> foreach my $i (1..$N)
> {
> my @Values = ();
>
> for (my $i=0;$i<=$#Zero;$i++)
> {
> for (my $j=0;$j<=$#{$Zero[$i]};$j++)
> {
> $Values[$i][$j] = $Zero[$i][$j]
> }
>
> }
An easier way to do this is to use the Clone module:
use Clone "clone";
my @Values = map clone($_), @Zero;
# or
my @Values = @{ clone \@Zero };
Ben
------------------------------
Date: Sat, 16 Feb 2013 13:34:00 +0200
From: "George Mpouras" <nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam>
Subject: Re: assignments of arrays
Message-Id: <kfnqr7$vae$1@news.ntua.gr>
thanks nice
------------------------------
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 3881
***************************************
