[19461] in Perl-Users-Digest
Perl-Users Digest, Issue: 1656 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Aug 30 11:05:37 2001
Date: Thu, 30 Aug 2001 08:05:14 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Message-Id: <999183914-v10-i1656@ruby.oce.orst.edu>
Content-Type: text
Perl-Users Digest Thu, 30 Aug 2001 Volume: 10 Number: 1656
Today's topics:
Re: a mystery to me: EOF (Villy Kruse)
Re: a perl module dedicated to lists ? (Tad McClellan)
Re: A Question about reference lifetimes (Stan Brown)
Re: Calling sub funcs with scalar variables? (Anno Siegel)
Re: Calling sub funcs with scalar variables? (Tad McClellan)
combining varibles <alexdgreen@hotmail.com>
Re: combining varibles <godzilla@stomp.stomp.tokyo>
Re: combining varibles <tony_curtis32@yahoo.com>
Re: combining varibles <alexdgreen@hotmail.com>
Re: combining varibles <nowhere@dot.com>
Re: combining varibles <alexdgreen@hotmail.com>
Re: Converting Perl to C (Tad McClellan)
Re: each() bug (?) <joe+usenet@sunstarsys.com>
Re: each() bug (?) <ilya@martynov.org>
Re: each() bug (?) <joe+usenet@sunstarsys.com>
Re: each() bug (?) (Rafael Garcia-Suarez)
Re: each() bug (?) <joe+usenet@sunstarsys.com>
Re: each() bug (?) <skj@iobox.fi>
Errorlevel checking (Paul Butt)
Re: Errorlevel checking <godzilla@stomp.stomp.tokyo>
Re: File handle persistance across fork() ? (Villy Kruse)
Re: File::Find not recursing on Win32 Perl 5.001 (Phil Hibbs)
Re: GetOpt::Long error (Joseph)
Re: Godzilla Stomps Code Red <godzilla@stomp.stomp.tokyo>
Re: Godzilla Stomps Code Red <newspost@coppit.org>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 30 Aug 2001 13:34:41 GMT
From: vek@pharmnl.ohout.pharmapartners.nl (Villy Kruse)
Subject: Re: a mystery to me: EOF
Message-Id: <slrn9osg7g.vh8.vek@pharmnl.ohout.pharmapartners.nl>
On 30 Aug 2001 05:39:58 -0700,
Joachim Ziegler <ziegler@algorilla.de> wrote:
>hi perlers,
>
>reading the documentation of Perl's eof(), i'm wondering what EOF
>really is.
>
That is the end of your file. When you have read x bytes from a file
of size x you've reached end of file. The end of file condition on
a pipe or socket is seen when the sending end closes the pipe or socket
and for tape devices end of file is caused by special tape marks on the
tape.
>pressing CTRL-D on my keyboard is said to generate an
>"end-of-file-character". so is this a legal ASCII-character?
>
ctrl-D in unix is magic to the tty driver na makes it emulate an
end of file condition. That is required for exmaple for the cat
command which will read intil it reaches the end of file condition.
At the same time ctrl-D is eaten by the tty driver and never seen
by any program. The ctrl-D character is only special in the tty
driver if it is in canonical mode; if you set the tty driver in
raw mode, ctrl-D is transmitted through to the user program the
same way as any other character.
>(btw, how do i generate this character by a keyboard-stroke under
>Windows?)
MS-DOS uses ctrl-Z for the same purpose. For historical reasons and
compatibility with CP/M this works also in disk files.
>
>i can't find it in my ASCII-table, because it does not show the
>non-printable characters. can someone please point me to a complete table?
>
>i'm conjecturing the following:
>
>the EOF-character is *not* the last character of any file, right?
>
There is no such thing as an EOF character.
>the EOF returned by C's getc() is *not* the same as the above
>character generated by a keyboard-stroke, but a symbolic constant
>(usually negative) returned by this function to indicate, that there
>are no more characters left in a file/stream... right?
>
>but internally, where does getc() know from that the stream is empty?
>it's system-dependent, right?
>
>the last line read by a <FILEHANDLE>-construct in Perl does *never*
>contain any special EOF-character at the end, right?
Right, there is no such thing as an EOF character. The kernel will
signal the EOF condition by returning a length of zero when trying
to read from the file or device, and the perl or C runtime will then
do whatever is necessary when this happens, forexample by returning
undef from <FILEHANDLE>, or returning the value EOF from getc() in
C.
Villy
------------------------------
Date: Thu, 30 Aug 2001 09:20:10 -0400
From: tadmc@augustmail.com (Tad McClellan)
Subject: Re: a perl module dedicated to lists ?
Message-Id: <slrn9osfca.79c.tadmc@tadmc26.august.net>
Logan Shaw <logan@cs.utexas.edu> wrote:
>Also, your expression "@liste == ()" may not do what you think it
>does. It converts both lists to scalar values.
^^^^
Eh? There is only one list there. The LHS is an array, not a list.
>When a list is
>converted to a scalar, the scalar value is the length of the list.
No, when an array is converted to a scalar, the scalar value is the
length of the array. That handles the LHS.
>So
>your expression is comparing the length of @liste
So far, so good.
>to the length of an
>empty list.
Not directly though. The RHS has an undef value (not a length),
it generates an "uninitialized value" warning.
So it is comparing (numerically) the length of the array to undef,
undef is converted to zero for the comparison.
>In fact, "@liste == ()" is equivalent to "not @liste" or
^^^^^^^^^^
>"@liste == 0".
Except one generates a warning and the others do not :-)
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: 30 Aug 2001 09:05:28 -0400
From: stanb@panix.com (Stan Brown)
Subject: Re: A Question about reference lifetimes
Message-Id: <9mldmo$5nq$1@panix3.panix.com>
In <3B8DD5F6.651B2C41@earthlink.net> Benjamin Goldberg <goldbb2@earthlink.net> writes:
>Stan Brown wrote:
>>
>> I'm going to need to spawn a child task with FileHandle->open, and
>> have it do a lengthy DBI query (thus allowing perlTK to continue
>> updating the screen).
>>
>> Beacause of the ammount of data potentialy returned by this select, I
>> need to use one of the DBI calls that returns a refernce to the
>> returned data.
>>
>> The child task will exit at the end of the select, but I need to be
>> able to access the data untill the parent exits.
>>
>> Will this be OK? I'm concrend about cleanup on the exit of the child
>> destroying the refeenced data.
>>
>> If this is a problem, is there some way to work around this?
>The only problem I see here is that you apparently think that you can
>have the child store the results of the fetch in a variable, and have
>the parent read that variable. Unfortunatly for you, processes are
>generally not threads, and this doesn't work. You need to find a way to
>send the data from the child to the parent. The parent ends up with a
>copy of it, and so it doesn't matter what happens to the child's data
>after the parent gets it.
>I've written a module specifically for creating a child process, having
>that child do a DBI query, and send the data back to the parent. If you
>like, I could send it to you.
>I should point out though, it doesn't work quite yet, and I haven't been
>able to figure out why not.
>When it does work though, you should be able to do:
>my $daemon = DBI::Daemon->new;
>$daemon->connect("dbi:dbtype:dbname", $user, $pass);
>$daemon->prepare("select field,field from table");
>$daemon->execute();
>my $fd = $daemon->getfd();
>$tk_main_window->filevent( $fd, "readable", sub {
> my $onerow = $daemon->fetch();
> if( !$onerow ) {
> print "Done with fetching\n";
> $tk_main_window->filevent( $fd, "readable", "" );
> return;
> }
> print "Got row [@$onerow]\n";
>} );
Yes, I kow this, Unfortunately, as you siad. It doesn't work yet ::-(
I have to get somethign working to allow real work to proceed, so I'm
trying to come up with an atlernative to this.
Sugestions?
------------------------------
Date: 30 Aug 2001 13:50:46 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: Calling sub funcs with scalar variables?
Message-Id: <9mlgbm$ifo$1@mamenchi.zrz.TU-Berlin.DE>
According to Yves Orton <demerphq@hotmail.com>:
> tadmc@augustmail.com (Tad McClellan) wrote in message
> news:<slrn9or6di.5ak.tadmc@tadmc26.august.net>...
> > GunneR <ds@ss.com> wrote:
> > >I want the following to execute a sub function:
> > >
> > >&"$func"; ## Of course this doesnt work... its just to give you an
> > >idea.
> > >
> > >Ive tried &($func); &{$func} and the like but no go. Im sure theres a
> > ^^^^^^^^
> >
> > That one works fine for me (after turning strict off).
> >
> > What you are asking for is called "Symbolic references". They are bad:
> >
> > http://www.plover.com/~mjd/perl/varvarname.html
> > http://www.plover.com/~mjd/perl/varvarname2.html
> > http://www.plover.com/~mjd/perl/varvarname3.html
>
> Well. Im not going to argue they arent a good idea, and shouldn't be
> used in general but really 'They are bad' is a little to absolute and
> simple for me.
Symrefs are considered bad for a good reason: They violate the separation
between program and data. This separation is so fundamental that it took
a von Neumann to conceive that they could be stored on the same media.
Even in languages (like Lisp) that stress that a program is just a
special kind of data, the use of arbitrary bits of data as program is
rare and needs justification.
Perl allows us to use data as program, in limited ways via symrefs and
with no limitation at all via string eval, but this ability must be
used with discretion. It usually can be avoided, and if it can't, it
should happen in a clearly demarcated danger zone.
>
> > so I am not going to help you use them. I will instead offer
> > an alternative where you won't need them, a dispatch table:
> >
> > my %subs = (
> > mysub1 => \&mysub1,
> > mysub2 => \&mysub2,
> > );
> >
> > my $func = 'mysub2';
> >
> > $subs{$func}->(); # call mysub2()
>
> Im not sure why this is better than using a symbolic reference. Is it
> becuase you are restricted as to which subs you can call? I suppose I
> would buy this.
Yes, it restricts the functions that can be called to a set the
programmer has determined. A symref lets users call anything in sight,
including the "erase_all_data_and_quit" function they weren't meant
to call.
> Anyway, the reason I am posting is cause it seems to me that using OO
> would be a better way to do this.
>
> my $method='new';
> my $obj=Foo::Bar->$method();
>
> Generally when I have situations where I need to do this kind of thing
> I use OO.
Yes, that's another way to restrict the set of callable functions. The
class Foo::Bar must only have methods that are safe for the user to call,
that must be borne in mind in its design.
I just wouldn't advise a newbie to use OO for what "should be simple",
as they are wont to say. Even the standard advice to use a hash is
often met with reluctance. I like telling them to do
$age = $value if $name eq 'age';
$sex = $value if $name eq 'sex';
$location = $value if $name eq 'location';
or equivalent. That lets them keep the precious variable names while
being perfectly safe. When it gets tedious, a hash solution is probably
welcome :)
Anno
------------------------------
Date: Thu, 30 Aug 2001 08:12:29 -0400
From: tadmc@augustmail.com (Tad McClellan)
Subject: Re: Calling sub funcs with scalar variables?
Message-Id: <slrn9osbdd.79c.tadmc@tadmc26.august.net>
Yves Orton <demerphq@hotmail.com> wrote:
>tadmc@augustmail.com (Tad McClellan) wrote in message news:<slrn9or6di.5ak.tadmc@tadmc26.august.net>...
>> GunneR <ds@ss.com> wrote:
>> >I want the following to execute a sub function:
>> >
>> >&"$func"; ## Of course this doesnt work... its just to give you an
>> >idea.
>> >
>> >Ive tried &($func); &{$func} and the like but no go. Im sure theres a
>> What you are asking for is called "Symbolic references". They are bad:
>Well. Im not going to argue they arent a good idea, and shouldn't be
>used in general but really 'They are bad' is a little to absolute and
>simple for me.
^^^^^^
But I wasn't following up to you :-)
I adjusted for the perceived knowledge level of my audience.
For people that kind of dance around the idea of symrefs, "they are bad"
is all they need to know. When they know enough to recognize that it
is not universally applicable, then they know enough to contemplate
actually using symrefs.
You are not ready to use symrefs unless you already know why
they are bad.
>> so I am not going to help you use them. I will instead offer
>> an alternative where you won't need them, a dispatch table:
>>
>> my %subs = (
>> mysub1 => \&mysub1,
>> mysub2 => \&mysub2,
>> );
>>
>> my $func = 'mysub2';
>>
>> $subs{$func}->(); # call mysub2()
>
>Im not sure why this is better than using a symbolic reference. Is it
>becuase you are restricted as to which subs you can call?
Yes.
>I suppose I
>would buy this.
Perl maintains function (and scalars, arrays, etc...) names in
a hash (the Symbol Table). When this hash is accessed is controlled
by perl (in response to using a symref, for example).
You can maintain the same information in your very own hash, and
then you don't need to know how Perl uses/accesses the symbol table.
Plain hash accesses are harder to trick than symbol table accesses.
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Thu, 30 Aug 2001 16:08:36 +0200
From: "Alex Green" <alexdgreen@hotmail.com>
Subject: combining varibles
Message-Id: <9mlhd5$2qnm0$1@ID-106172.news.dfncis.de>
I've spent to much timein tcsh and i have forgotten how to take to varibles
and input them into a single varible in perl.
If anyone could help, it would be great
Thanks
------------------------------
Date: Thu, 30 Aug 2001 07:18:39 -0700
From: "Godzilla!" <godzilla@stomp.stomp.tokyo>
Subject: Re: combining varibles
Message-Id: <3B8E4B3F.83BDE7A7@stomp.stomp.tokyo>
Alex Green wrote:
> I've spent to much timein tcsh and i have forgotten how to take to varibles
> and input them into a single varible in perl.
Have you considered this little known method
of reading Perl documentation?
Godzilla!
--
06:53:20 08/30/2001 - SCRIPT CRASH:
- DNS: localhost - ISP: 127.0.0.1
- System: Mozilla/GODZILLA! GO GO GODZILLA!
- Redirect URL: /~test/test1.pl
- Referral: http://localhost/~test/
------------------------------
Date: 30 Aug 2001 09:34:18 -0500
From: Tony Curtis <tony_curtis32@yahoo.com>
Subject: Re: combining varibles
Message-Id: <87g0a9fwgl.fsf@limey.hpcc.uh.edu>
>> On Thu, 30 Aug 2001 16:08:36 +0200,
>> "Alex Green" <alexdgreen@hotmail.com> said:
> I've spent to much timein tcsh and i have forgotten how
> to take to varibles and input them into a single varible
> in perl.
Far too vague. Try again with some examples.
hth
t
--
Yes way! Mmmmkay?
------------------------------
Date: Thu, 30 Aug 2001 16:41:44 +0200
From: "Alex Green" <alexdgreen@hotmail.com>
Subject: Re: combining varibles
Message-Id: <9mljba$2r1m3$1@ID-106172.news.dfncis.de>
Hi,
Right well basically I have a perl/cgi script retreiving values from an html
form, with a first name and a last name field and what I need is these to
vars, lets say $fn and $ln to become combined to become $owner.
Not really sure whether combine is the right word, but basically I need to
be able to print them as an entire text string. Does that make sense?
Thanks
"Tony Curtis" <tony_curtis32@yahoo.com> wrote in message
news:87g0a9fwgl.fsf@limey.hpcc.uh.edu...
> >> On Thu, 30 Aug 2001 16:08:36 +0200,
> >> "Alex Green" <alexdgreen@hotmail.com> said:
>
> > I've spent to much timein tcsh and i have forgotten how
> > to take to varibles and input them into a single varible
> > in perl.
>
> Far too vague. Try again with some examples.
>
> hth
> t
> --
> Yes way! Mmmmkay?
------------------------------
Date: Fri, 31 Aug 2001 00:45:42 +1000
From: "Gregory Toomey" <nowhere@dot.com>
Subject: Re: combining varibles
Message-Id: <Ngsj7.7492$Nd2.107173@newsfeeds.bigpond.com>
"Alex Green" <alexdgreen@hotmail.com> wrote in message
news:9mlhd5$2qnm0$1@ID-106172.news.dfncis.de...
> I've spent to much timein tcsh and i have forgotten how to take to
varibles
> and input them into a single varible in perl.
>
> If anyone could help, it would be great
> Thanks
Do you mean concatenation?
$x = $y . $z;
gtoomey
------------------------------
Date: Thu, 30 Aug 2001 17:02:33 +0200
From: "Alex Green" <alexdgreen@hotmail.com>
Subject: Re: combining varibles
Message-Id: <9mlkib$2v3ut$1@ID-106172.news.dfncis.de>
Urrr, not sure, I have tried this but wasnt to sure about what the result
would be, at the moment I am trying to find where I am getting 'Unmatched
".' from, I can't see anything really obvious, any suggestions?
Thanks.
"Gregory Toomey" <nowhere@dot.com> wrote in message
news:Ngsj7.7492$Nd2.107173@newsfeeds.bigpond.com...
> "Alex Green" <alexdgreen@hotmail.com> wrote in message
> news:9mlhd5$2qnm0$1@ID-106172.news.dfncis.de...
> > I've spent to much timein tcsh and i have forgotten how to take to
> varibles
> > and input them into a single varible in perl.
> >
> > If anyone could help, it would be great
> > Thanks
>
> Do you mean concatenation?
>
> $x = $y . $z;
>
> gtoomey
>
>
------------------------------
Date: Thu, 30 Aug 2001 09:24:41 -0400
From: tadmc@augustmail.com (Tad McClellan)
Subject: Re: Converting Perl to C
Message-Id: <slrn9osfkp.79c.tadmc@tadmc26.august.net>
Oleg Bogumirsky <oleg_b@newmail.ru> wrote:
>Could anybody help me to get C source for my perl program
^^^^^^^
If you had followed standard netiquette, you would have found
help in less time than it took you to type up your Usenet article.
You are not working at maximum efficiency (and taking others with you).
>Perl source to C/C++ source, so I could compile this C source with c
^^^^^^^
>compiler.
So you want to "compile" something? Wonder if any of the Perl FAQs
mention that term?
perldoc -q compile
"How can I compile my Perl program into byte code or C?"
You are expected to check the Perl FAQs *before* posting to the
Perl newsgroup.
>Thanks
Uh huh.
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: 30 Aug 2001 09:05:48 -0400
From: Joe Schaefer <joe+usenet@sunstarsys.com>
Subject: Re: each() bug (?)
Message-Id: <m3ofoxn1eb.fsf@mumonkan.sunstarsys.com>
Ilya Martynov <ilya@martynov.org> writes:
> Any ideas why following code (under Perl 5.6.1) causes infinite loop?
>
> while(my($value, $uiname) = each %{{ true => 'Yes', false => 'No' }}) {
> print "$uiname\n";
> }
Each time through the loop, perl is recreating the anonymous hash.
The sequence of ops on each pass looks like (using $a and $b instead
of $value and $uiname):
(-e:1) pushmark
(-e:1) pushmark
(-e:1) const(PV("true"\0)) < looks like
(-e:1) const(PV("Yes"\0)) < perl is rebuilding
(-e:1) const(PV("false"\0)) < the anonhash each
(-e:1) const(PV("No"\0)) < time through
(-e:1) anonhash < the loop
(-e:1) srefgen
(-e:1) rv2hv
(-e:1) each
(-e:1) pushmark
(-e:1) gvsv(main::a)
(-e:1) gvsv(main::b)
(-e:1) aassign
(-e:1) and
(-e:1) pushmark
(-e:1) gvsv(main::a)
(-e:1) gvsv(main::b)
(-e:1) print
(-e:1) unstack
Certainly a bug, but I don't know if it's perl's problem or yours.
--
Joe Schaefer "I never think of the future. It comes soon enough."
--Albert Einstein
------------------------------
Date: 30 Aug 2001 17:16:33 +0400
From: Ilya Martynov <ilya@martynov.org>
Subject: Re: each() bug (?)
Message-Id: <874rqpg026.fsf@abra.ru>
>>>>> On 30 Aug 2001 09:05:48 -0400, Joe Schaefer <joe+usenet@sunstarsys.com> said:
JS> Ilya Martynov <ilya@martynov.org> writes:
>> Any ideas why following code (under Perl 5.6.1) causes infinite loop?
>>
>> while(my($value, $uiname) = each %{{ true => 'Yes', false => 'No' }}) {
>> print "$uiname\n";
>> }
JS> [..skip..]
JS> Certainly a bug, but I don't know if it's perl's problem or yours.
Probably mine. At least it is consitent with behaviour of this code
(which also causes infinite loop)
while(shift @{[qw(1 2)]}) {
.....
}
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
| Ilya Martynov (http://martynov.org/) |
| GnuPG 1024D/323BDEE6 D7F7 561E 4C1D 8A15 8E80 E4AE BE1A 53EB 323B DEE6 |
| AGAVA Software Company (http://www.agava.com/) |
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
------------------------------
Date: 30 Aug 2001 09:22:00 -0400
From: Joe Schaefer <joe+usenet@sunstarsys.com>
Subject: Re: each() bug (?)
Message-Id: <m3k7zln0nb.fsf@mumonkan.sunstarsys.com>
Joe Schaefer <joe+usenet@sunstarsys.com> writes:
> Ilya Martynov <ilya@martynov.org> writes:
>
> > Any ideas why following code (under Perl 5.6.1) causes infinite loop?
> >
> > while(my($value, $uiname) = each %{{ true => 'Yes', false => 'No' }}) {
> > print "$uiname\n";
> > }
>
> Each time through the loop, perl is recreating the anonymous hash.
> The sequence of ops on each pass looks like (using $a and $b instead
> of $value and $uiname):
[...]
> Certainly a bug, but I don't know if it's perl's problem or yours.
I think perl is doing the right thing here, since the refcount
for the anonhash is zero after the assignment is completed. That
means it shouldn't persist between calls to each, so perl must
make a new one in its place.
--
Joe Schaefer "Anyone who considers arithmetical methods of producing random
digits is, of course, in a state of sin."
-- John von Neumann
------------------------------
Date: 30 Aug 2001 13:41:33 GMT
From: rgarciasuarez@free.fr (Rafael Garcia-Suarez)
Subject: Re: each() bug (?)
Message-Id: <slrn9osgv4.mou.rgarciasuarez@rafael.kazibao.net>
Joe Schaefer wrote in comp.lang.perl.misc:
} Joe Schaefer <joe+usenet@sunstarsys.com> writes:
} >
} > Each time through the loop, perl is recreating the anonymous hash.
} > The sequence of ops on each pass looks like (using $a and $b instead
} > of $value and $uiname):
}
} [...]
}
} > Certainly a bug, but I don't know if it's perl's problem or yours.
}
} I think perl is doing the right thing here, since the refcount
} for the anonhash is zero after the assignment is completed. That
} means it shouldn't persist between calls to each, so perl must
} make a new one in its place.
Unless the optimizer becomes so performant that it finds a way to figure
out that the hash is constant, and that it can be constructed before the
actual loop.
--
Rafael Garcia-Suarez
------------------------------
Date: 30 Aug 2001 10:30:31 -0400
From: Joe Schaefer <joe+usenet@sunstarsys.com>
Subject: Re: each() bug (?)
Message-Id: <m3elptmxh4.fsf@mumonkan.sunstarsys.com>
rgarciasuarez@free.fr (Rafael Garcia-Suarez) writes:
> Joe Schaefer wrote in comp.lang.perl.misc:
> } Joe Schaefer <joe+usenet@sunstarsys.com> writes:
> } >
> } > Each time through the loop, perl is recreating the anonymous hash.
> } > The sequence of ops on each pass looks like (using $a and $b instead
> } > of $value and $uiname):
> }
> } [...]
> }
> } > Certainly a bug, but I don't know if it's perl's problem or yours.
> }
> } I think perl is doing the right thing here, since the refcount
> } for the anonhash is zero after the assignment is completed. That
> } means it shouldn't persist between calls to each, so perl must
> } make a new one in its place.
>
> Unless the optimizer becomes so performant that it finds a way to figure
> out that the hash is constant, and that it can be constructed before the
> actual loop.
I disagree- the problem from my POV is that the hash's internal state
(as modified by each()) will of necessity change over successive
calls. While that's desirable here, it's easy to envision situations
where precompiling "constant" anonymous arrays would be bad:
sub anonhash {{foo=>1, bar=>2}}
print each anonhash(); # should produce
print each anonhash(); # same output
print ++$. while each %{anonhash()}; # should loop forever ?
I guess what would be needed then is some cloning mechanism similar to
what is done with anonymous subs, but it might be hard to divine
an appropriate set of DWIMery rules.
Personally I believe that the current perl is fine in this situation.
Although some additional DWIMery might be nice here, I don't have a
clue as to how to do it.
--
Joe Schaefer
perl -wle '$,=" ";{ my @x;sub x {if(@_){push @x,@_; return sub{push @x,@_;@x}}
sub{push @x,@_;@x}}
} print x ("Just")->("another"), x -> ("perl","hacker,")'
------------------------------
Date: Thu, 30 Aug 2001 17:34:22 +0300
From: Sami Jarvinen <skj@iobox.fi>
Subject: Re: each() bug (?)
Message-Id: <MPG.15f87b28d59099ce9896b7@news.yhteys.mtv3.fi>
Ilya Martynov <ilya@martynov.org> wrote
> Any ideas why following code (under Perl 5.6.1) causes infinite loop?
>
> while(my($value, $uiname) = each %{{ true => 'Yes', false => 'No' }}) {
> print "$uiname\n";
> }
You're creating a new hash at each iteration.
I'm no expert tho, better consult the masters as well =)
------------------------------
Date: 30 Aug 2001 07:04:10 -0700
From: paul_s_b@hotmail.com (Paul Butt)
Subject: Errorlevel checking
Message-Id: <d8594076.0108300604.132134ad@posting.google.com>
Hi,
I'm writing a small script to do different things depending on the
particular error level returned by our anti-virus software.
Can anybody point out the easiest/quicket way to do this ?
Thanks
------------------------------
Date: Thu, 30 Aug 2001 07:12:37 -0700
From: "Godzilla!" <godzilla@stomp.stomp.tokyo>
Subject: Re: Errorlevel checking
Message-Id: <3B8E49D5.DC052F8A@stomp.stomp.tokyo>
Paul Butt wrote:
> I'm writing a small script to do different things depending on the
> particular error level returned by our anti-virus software.
> Can anybody point out the easiest/quicket way to do this ?
Do you have a valid reason for not posting this code
you have developed so far?
This would be both logical and courteous, Mr. Butt.
Godzilla!
--
07:10:11 08/30/2001 - RESTRICTED FILE REDIRECT:
- DNS: - IPA: 207.196.87.4
- System:
- Redirect URL: /default.ida
------------------------------
Date: 30 Aug 2001 14:01:01 GMT
From: vek@pharmnl.ohout.pharmapartners.nl (Villy Kruse)
Subject: Re: File handle persistance across fork() ?
Message-Id: <slrn9oshot.vh8.vek@pharmnl.ohout.pharmapartners.nl>
On Thu, 30 Aug 2001 05:36:58 -0400,
Benjamin Goldberg <goldbb2@earthlink.net> wrote:
>
>Shouldn't the child get a *copy* of it's parent's file table, so that
>even though the opened file descriptor is inherited, it becomes an entry
>in a *different table* ?
>
No it doesn't.
In unix kernel you have a hierarchy of tables to get to the file:
From the file fd you look up a pointer in the fd-table indexed by
the fd value. That pointer points to a struct file entry, which
contains among other things the current file pointer, some flags,
and a pointer to a struct inode pointer. The struct inode pointer
then represents the physical file by its table of block numbers and
pointers to file system tables. In newer unix systems the inode
table is split into a file system independent part which then points
to a file system type dependent part.
When opening a file a new file table entry is created which points
to an inode table entry. If the file is already opened by some
other process the existing inode entry is used and the reference
counter is incremented. Then a fd-table entry is created and the
index is returned to the caller. When forking a process only the
fd-table is copied to the new process, the file structure entry is
now shared between the two processes and a reference counter in the
file structure is incremented. The same happens if you dup() a fd.
That way, the child process does not get a copy of the file structure
entry, just a copy of a pointer to the file structure entry.
>
>Doesn't that also imply that if I open a file twice [getting two
>filehandles to it], use fcntl to lock one, then both are effectively
>locked? Yuck.
What is worse is that when you close one of the fd's, even the one
you didn't use for locking the file, the lock is released.
> This might not sound bad, but if I've got a bunch of
>threads, and I want to communicate via pipes [which will magically
>buffer data for me], and have the parent thread dump all the jobs it
>wants the kiddies to do into one end, then have the child threads each
>lock, read one job, then unlock, I've got a problem. [Yes, one could do
>it with semaphores, but locking is easier, *especially* if the code may
>eventually get changed to use processes instead of threads].
>
Can't say for sure if fcntl locks are tied to the process id or
the thread id. On linux this is not an issue because process
and thread id is the same thing as far as the kernel is concerned.
For a regular fork the locked file will be locked to the parent only,
and not for the children, also when the child process inherits the
fd from the parent process.
Villy
------------------------------
Date: 30 Aug 2001 07:55:41 -0700
From: phil@snark.freeserve.co.uk (Phil Hibbs)
Subject: Re: File::Find not recursing on Win32 Perl 5.001
Message-Id: <979ae699.0108300655.9e0092f@posting.google.com>
> What version of perl is it? I tried it on 5.6.1 on 2000 Pro.
It's 5.001 as per the subject line. And no, I can't upgrade it, much
though I'd like to.
Phil Hibbs.
------------------------------
Date: 30 Aug 2001 06:58:55 -0700
From: joseph.van_quakebeke@innovantage.com (Joseph)
Subject: Re: GetOpt::Long error
Message-Id: <1c66c494.0108300558.3c1042fc@posting.google.com>
Thank you all for your help. I just re-checked page 898 of the Camel
and I totally mis-read the example. Trying to go to rush when I should
have slowed down.
Thank you all for your help.
Joseph
------------------------------
Date: Thu, 30 Aug 2001 06:06:48 -0700
From: "Godzilla!" <godzilla@stomp.stomp.tokyo>
Subject: Re: Godzilla Stomps Code Red
Message-Id: <3B8E3A68.53E67551@stomp.stomp.tokyo>
Michel Dalle aka Thomas Batzler The CLPM Troll aka Ad Nauseam wrote:
> Godzilla! wrote:
(snipped his troll article)
It is true my abilities to research and read, my ingenious
Perl programming skills, my talents at writing efficient
and imaginative Perl scripts, are a serious threat to these
fragile masculine egos of weak-kneed men populating this
newsgroup and, adequately devastate this diseased ego of
The CLPM Troll.
I cause you to piddle your polyester pants, yes Frank?
Godzilla!
--
23:27:34 08/29/2001 - RESTRICTED FILE REDIRECT:
- DNS: lsiedm-fw.lsiedm.com - IPA: 207.167.12.182
- System:
- Redirect URL: /default.ida
------------------------------
Date: Thu, 30 Aug 2001 09:41:38 -0400
From: David Coppit <newspost@coppit.org>
Subject: Re: Godzilla Stomps Code Red
Message-Id: <3B8E4292.6090204@coppit.org>
Michel Dalle wrote:
> In article <3B8D3E08.55B5B701@stomp.stomp.tokyo>, "Godzilla!" <godzilla@stomp.stomp.tokyo> wrote:
>
>>There is a very serious note of caution which you should
>>abide, do not discount this. Use of either script below
>>my signature could very well put you in a World Of Hurt.
>>
> [snip]
>
> I'm sure I've seen an almost identical script on the Web,
> with the same twisted logic...
>
> The biggest difference was that it didn't contain the user
> agent "Godzilla Stomped Your Code Red Infected Server",
> and that it had the following copyright notice at the top :
>
> # default.ida in perl
> # Copyright 2001 Sam Phillips <sam@dasbistro.com>
> # ideas borrowed from Erin Quinlan <erin@dasbistro.com>
> # ideas provided by various Internet folk, and all those darn
> # Crackmonkeys (http://www.crackmonkey.org) and Pigdoggers
> # (http://www.pigdog.org)
Ouch. Godzilla is a plaigarist. There goes whatever reputation she had
left... [And her response was the usual red herring/ad hominem. Methinks
its must be plaigarism if she won't defend herself...]
David
------------------------------
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:
The Perl-Users Digest is a retransmission of the USENET newsgroup
comp.lang.perl.misc. For subscription or unsubscription requests, send
the single line:
subscribe perl-users
or:
unsubscribe perl-users
to almanac@ruby.oce.orst.edu.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
To request back copies (available for a week or so), send your request
to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
where x is the volume number and y is the issue number.
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 V10 Issue 1656
***************************************
