[29371] in Perl-Users-Digest
Perl-Users Digest, Issue: 615 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Jul 3 16:10:12 2007
Date: Tue, 3 Jul 2007 13:09:09 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Tue, 3 Jul 2007 Volume: 11 Number: 615
Today's topics:
Data Access Handler <gosterweiss@goodtaxsystem.info>
dollar sign literals <Jason.Williams.0617@gmail.com>
Re: Help finding CGI files on Unix server <bassintro@gmail.com>
Re: Help finding CGI files on Unix server <jurgenex@hotmail.com>
improvement suggestion for File::Find: pre-parsed exten <tzz@lifelogs.com>
Re: improvement suggestion for File::Find: pre-parsed e <mritty@gmail.com>
Re: improvement suggestion for File::Find: pre-parsed e <tzz@lifelogs.com>
Re: improvement suggestion for File::Find: pre-parsed e <mritty@gmail.com>
Re: improvement suggestion for File::Find: pre-parsed e <bik.mido@tiscalinet.it>
Re: improvement suggestion for File::Find: pre-parsed e <bik.mido@tiscalinet.it>
Re: Overriding a class method with an object method eminencja@gmail.com
Re: Overriding a class method with an object method anno4000@radom.zrz.tu-berlin.de
Re: Portable general timestamp format, not 2038-limited sla29970@gmail.com
retrieving news messages (was: Re: unlurking) <moranar@gmail.com>
set Bad variable type - SNMP::Util set <jcottingim@yahoo.com>
Re: unlurking <invalid@invalid.nyet>
Re: unlurking <invalid@invalid.nyet>
Re: unlurking <invalid@invalid.nyet>
Re: unlurking <glennj@ncf.ca>
Re: unlurking <invalid@invalid.nyet>
Re: using wildcards with -e <savagebeaste@yahoo.com>
Re: using wildcards with -e <bik.mido@tiscalinet.it>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 03 Jul 2007 18:32:41 GMT
From: Griffin Osterweiss <gosterweiss@goodtaxsystem.info>
Subject: Data Access Handler
Message-Id: <dDwii.2708$_61.534@fe168.usenetserver.com>
You know how could I do for forwarding to delete the cable of the log in
order to the point is that then from a hard disk, on the preferences
inside Windows you must overclock telnet to for forwarding to a hard
disk.
------------------------------
Date: Tue, 03 Jul 2007 12:59:36 -0700
From: Jason Williams <Jason.Williams.0617@gmail.com>
Subject: dollar sign literals
Message-Id: <1183492776.502565.295770@57g2000hsv.googlegroups.com>
Hi all, somewhat new to perl and unix scripting, here.
I am trying to run a unix ksh script to exec a perl command on each
file in a dir. Problem is, I need to include a dollar sign literal in
the right side of a substitution, like so:
-------------------------------
#!/bin/ksh
PATH=$PATH:/dbmgtu01/app/oracle/orbitz/1.0.0/bin:.
for FILE in dc0003*
do
echo $FILE
cp $FILE $FILE.bk
perl -pi -e "s/(.*)dc0003\.maintain\.partitions(.*dev.*)/
\1$calling_program_dev\2/g" $FILE
done
------------------------------
Only this does not work, because perl wants to replace the
$calling_program_dev with a ksh variable.
Here's some sample input and output:
input:
$calling_program_dir/dc0003.maintain.partitions_test -i dev_do9d
actual output:
$calling_program_dir/ -i dev_do9d
_desired output_ :
$calling_program_dir/$calling_program_dev -i dev_do9d
Any help appreciated. I've tried all sorts of things, including to
escape the dollar sign, enclose it in single quotes, etc, to no avail.
Many thanks,
Jason
------------------------------
Date: Tue, 03 Jul 2007 16:15:30 -0000
From: bassintro <bassintro@gmail.com>
Subject: Re: Help finding CGI files on Unix server
Message-Id: <1183479330.851724.39250@n60g2000hse.googlegroups.com>
On Jul 3, 5:37 am, anno4...@radom.zrz.tu-berlin.de wrote:
> bassintro <bassin...@gmail.com> wrote in comp.lang.perl.misc:
>
> > On Jul 2, 1:56 pm, "J. Gleixner" <glex_no-s...@qwest-spam-no.invalid>
> > wrote:
> > > bassintro wrote:
> > > > On Jul 2, 1:21 pm, Keith Keller <kkeller-use...@wombat.san-
> > > > francisco.ca.us> wrote:
> > > >> On 2007-07-02, bassintro <bassin...@gmail.com> wrote:
>
> > > >>> I need a way to find all the cgi files on my server and simply list
> > > >>> their name and dir.
> > I was actually looking for an alternative to running...
> > find . -type f -name '*.*htm*' -exec grep cgi {} \;
>
> > it spits out the results of the cgi. I just want it to list the file
> > and state what dir it's in, that's all...
>
> find . -type f -name '*.*htm*' | xargs grep -l cgi
>
> Anno
thank's a lot!
------------------------------
Date: Tue, 03 Jul 2007 17:00:43 GMT
From: "Jürgen Exner" <jurgenex@hotmail.com>
Subject: Re: Help finding CGI files on Unix server
Message-Id: <%gvii.4248$za5.4146@trndny09>
bassintro wrote:
> On Jul 2, 2:20 pm, "Jürgen Exner" <jurge...@hotmail.com> wrote:
>> bassintro wrote:
>>> I need a way to find all the cgi files on my server and simply list
>>> their name and dir.
> What I mean is I am trying to find executable files that are run on
> the server side of a www connection.
Well, strictly speaking that could be any file on the file system where the
'execute' bit is set.
> The extension is partly
> irrelevant to my search. The files could be *.pl *.cgi *.htm *.html
> etc... However what I am trying to go is find any dynamic type file in
> a specific dir like /home/* which has cgi content and output the name
> of the file and directory.
I don't think your approach is feasible because literaly any executable on
the web server could be involved in generating an HTTP response.
jue
------------------------------
Date: Tue, 03 Jul 2007 11:57:25 -0400
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: improvement suggestion for File::Find: pre-parsed extensions
Message-Id: <m2abudeaze.fsf@lifelogs.com>
I think it would be really useful if in addition to $File::Find::name
and $_ there were also $File::Find::namenoext, $_namenoext ($_ without
the extension), and $File::Find::ext (the extension itself). On most
OSs it should be true that
$File::Find::namenoext . '.' . $File::Find::ext eq $File::Find::name
$_namenoext . '.' . $File::Find::ext eq $_
but when the extension is undef, $_namenoext eq $_ (I think undef is
better than '' for an empty extension, and would distinguish nicely
between "filename." and "filename").
I do this all the time by hand inside the wanted() function, and I think
an extra string match and three more variables won't hurt File::Find too
much. It's already IO-bound in the find() function.
The code for this is easy, but this is a core module so before producing
a patch I thought I'd ask: has it been done before, and did I miss
something in File::Find? I didn't find suggestions of this feature in
newsgroup or Google archives, but I'd like to hear if anyone has
suggestions for or against it.
Ted
------------------------------
Date: Tue, 03 Jul 2007 10:26:55 -0700
From: Paul Lalli <mritty@gmail.com>
Subject: Re: improvement suggestion for File::Find: pre-parsed extensions
Message-Id: <1183483615.873005.213880@k29g2000hsd.googlegroups.com>
On Jul 3, 11:57 am, Ted Zlatanov <t...@lifelogs.com> wrote:
> I think it would be really useful if in addition to $File::Find::name
> and $_ there were also $File::Find::namenoext, $_namenoext ($_ without
> the extension), and $File::Find::ext (the extension itself).
File::Basename makes those values trivially easy to obtain. I see no
reason for File::Find to create them for you, as they're not needed in
a majority of applications for which File::Find is used.
Paul Lalli
------------------------------
Date: Tue, 03 Jul 2007 14:00:34 -0400
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: improvement suggestion for File::Find: pre-parsed extensions
Message-Id: <m2zm2dbc59.fsf@lifelogs.com>
On Tue, 03 Jul 2007 10:26:55 -0700 Paul Lalli <mritty@gmail.com> wrote:
PL> On Jul 3, 11:57 am, Ted Zlatanov <t...@lifelogs.com> wrote:
>> I think it would be really useful if in addition to $File::Find::name
>> and $_ there were also $File::Find::namenoext, $_namenoext ($_ without
>> the extension), and $File::Find::ext (the extension itself).
PL> File::Basename makes those values trivially easy to obtain.
No, you still have to a) use the module, and b) call the functions.
That's not trivial compared to "the value is in $ext".
PL> I see no reason for File::Find to create them for you, as they're
PL> not needed in a majority of applications for which File::Find is
PL> used.
That hasn't been my experience, but then again I have written several
installers (and many other programs) using File::Find, so I may be
biased. In any case, as I mentioned, File::Find is IO-bound, so doing
the extra CPU work in the find() function would not harm performance,
and the extra memory usage is negligible. I don't think we should
sacrifice convenience for an unnecessary optimization.
Ted
------------------------------
Date: Tue, 03 Jul 2007 12:17:06 -0700
From: Paul Lalli <mritty@gmail.com>
Subject: Re: improvement suggestion for File::Find: pre-parsed extensions
Message-Id: <1183490226.198703.288280@o61g2000hsh.googlegroups.com>
On Jul 3, 2:00 pm, Ted Zlatanov <t...@lifelogs.com> wrote:
> On Tue, 03 Jul 2007 10:26:55 -0700 Paul Lalli <mri...@gmail.com> wrote:
>
> PL> On Jul 3, 11:57 am, Ted Zlatanov <t...@lifelogs.com> wrote:
>
> >> I think it would be really useful if in addition to $File::Find::name
> >> and $_ there were also $File::Find::namenoext, $_namenoext ($_ without
> >> the extension), and $File::Find::ext (the extension itself).
>
> PL> File::Basename makes those values trivially easy to obtain.
>
> No, you still have to a) use the module, and b) call the functions.
> That's not trivial compared to "the value is in $ext".
We'll have to agree to disagree as to the definition of "trivial".
> and the extra memory usage is negligible. I don't think we should
> sacrifice convenience for an unnecessary optimization.
And I don't think we should unnecessarily bloat a module to duplicate
functionality already available elsewhere.
Paul Lalli
------------------------------
Date: Tue, 03 Jul 2007 21:28:48 +0200
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: improvement suggestion for File::Find: pre-parsed extensions
Message-Id: <u88l8399b37ubsi94dokl94lnp0k43e0b7@4ax.com>
On Tue, 03 Jul 2007 11:57:25 -0400, Ted Zlatanov <tzz@lifelogs.com>
wrote:
>I think it would be really useful if in addition to $File::Find::name
>and $_ there were also $File::Find::namenoext, $_namenoext ($_ without
>the extension), and $File::Find::ext (the extension itself). On most
>OSs it should be true that
How 'bout @file::Find::file? But what do do if no_chdir => 1, anyway?
>The code for this is easy, but this is a core module so before producing
>a patch I thought I'd ask: has it been done before, and did I miss
>something in File::Find? I didn't find suggestions of this feature in
>newsgroup or Google archives, but I'd like to hear if anyone has
>suggestions for or against it.
For me File::Basename is so near to my hand and the kind info you
mention rare enough to be a need of mine that I don't see that as a
compellingly desirable feature. Perhaps a F::F on steroids with either
additional stuff passed to the wanted() sub or an object $_ with
suitable methods *or both* would be welcome. For suitable methods I
mean $_->name, $_->ext, $_->basename, $_->stat (so that you don't have
to do that again, etc.) Of course this would be max fun in Perl 6 with
its unary dot:
find { .basename.say if .ext ~~ 'txt' }, $dir;
Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
.'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
------------------------------
Date: Tue, 03 Jul 2007 21:34:58 +0200
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: improvement suggestion for File::Find: pre-parsed extensions
Message-Id: <ls8l83tf1qvtn456n31t7id7o2dct0ttra@4ax.com>
On Tue, 03 Jul 2007 14:00:34 -0400, Ted Zlatanov <tzz@lifelogs.com>
wrote:
>PL> File::Basename makes those values trivially easy to obtain.
>
>No, you still have to a) use the module, and b) call the functions.
>That's not trivial compared to "the value is in $ext".
Yep, but in several years of F::F's usage I can't remember having had
to use it so much. It may just be that my experience differs from
yours.
>That hasn't been my experience, but then again I have written several
>installers (and many other programs) using File::Find, so I may be
>biased. In any case, as I mentioned, File::Find is IO-bound, so doing
To be fair, yes: I think you're biased.
>the extra CPU work in the find() function would not harm performance,
>and the extra memory usage is negligible. I don't think we should
>sacrifice convenience for an unnecessary optimization.
But we shouldn't sacrifice simplicity and orthogonality for YAGNI.
Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
.'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
------------------------------
Date: Tue, 03 Jul 2007 10:51:43 -0700
From: eminencja@gmail.com
Subject: Re: Overriding a class method with an object method
Message-Id: <1183485103.632539.155530@w5g2000hsg.googlegroups.com>
On Jul 2, 10:11 pm, anno4...@radom.zrz.tu-berlin.de wrote:
>
> So you want a method that behaves one way when called as an object
> method and another way if called as a class method?
No, I want to create object Obj based on class P that overrides
a method defined in the class.
Assume the class has a method blahBlah() that prints "blah blah".
Objects based on this class can use that method, i.e. saying
$obj2->blahBlah
will print
"blah blah."
I would like to create an object that overrides this class method
so that when I say
$Obj->blahBlah
the object will print
"I'm special"
The solution I sent in (see my previous post) does work but
I hope there is an easier way(?).
K.
> You need a check that finds out what the invocant is (class or method)
> without failing in one of the cases. That is the problem with your
> approach -- it dies when called as a class method. Instead, check
> whether the invocant is a reference. If it is, assume an object,
> otherwise the class name. Untested:
>
> sub meth {
> my $whatever = shift;
> if ( ref $whatever ) {
> # got an object
> $whatever->{ meth}->();
> } else {
> # class method call
> print "This is an object method.\n";
> }
> }
>
> Anno
------------------------------
Date: 3 Jul 2007 18:49:33 GMT
From: anno4000@radom.zrz.tu-berlin.de
Subject: Re: Overriding a class method with an object method
Message-Id: <5evk1tF399s8fU1@mid.dfncis.de>
<eminencja@gmail.com> wrote in comp.lang.perl.misc:
> On Jul 2, 10:11 pm, anno4...@radom.zrz.tu-berlin.de wrote:
> >
> > So you want a method that behaves one way when called as an object
> > method and another way if called as a class method?
>
> No, I want to create object Obj based on class P that overrides
> a method defined in the class.
Your terminology is off. Objects don't override methods, methods
(in a client class) override methods (in a base class). Your use
of "class method" and "object method" is also off kilter. This
makes it hard to understand what you really want to do.
What you have *written* is simply a method that looks at a certain
field in the object and shows different behavior depending on what
it finds. (It claims to be a class method in one case, which isn't
the case.) No overriding is involved.
Whether it is essential to your solution that the object contains
(part of) the method code is unfortunately not clear. I'll assume
its a coincidental part of your specific solution. You could have
gotten the same effect by simply saying (untested):
sub meth {
my $obj =shift;
if ( $obj->{ i_am_special } ) {
print "Special behavior\n";
} else {
print "Normal behavior\n";
}
}
...plus a corresponding change in object construction
my $obj = P->new( i_am_special => 1);
Overriding is still not involved, it's just a method.
> Assume the class has a method blahBlah() that prints "blah blah".
> Objects based on this class can use that method, i.e. saying
> $obj2->blahBlah
> will print
> "blah blah."
>
> I would like to create an object that overrides this class method
> so that when I say
> $Obj->blahBlah
> the object will print
> "I'm special"
That doesn't make sense.
> The solution I sent in (see my previous post) does work but
> I hope there is an easier way(?).
That solution doesn't override anything.
Here is a setup that *does* use method overriding to achieve something
similar:
package P;
sub new
{
my $class = shift;
my $self = {@_};
bless $self, $class;
return $self;
}
sub meth { print "This is one behavior.\n" }
package Q;
use base 'P';
sub meth { print "This is another behavior.\n" }
package main;
my $obj = P->new();
my $other = Q->new();
$obj->meth;
$other->meth();
__END__
Anno
------------------------------
Date: Tue, 03 Jul 2007 16:50:06 -0000
From: sla29970@gmail.com
Subject: Re: Portable general timestamp format, not 2038-limited
Message-Id: <1183481406.243354.139830@e16g2000pri.googlegroups.com>
On Jul 3, 1:10 am, Paul Rubin <http://phr...@NOSPAM.invalid> wrote:
> Well, if you're trying to pick just one timestamp standard, I'd say
> you're better off using a worldwide one rather than a national one, no
> matter how the bureaucracies work. TAI is derived from atomic clocks
> all over the world, while the national metrology labs are more subject
> to error and desynchronization, and whatever legal primacy they have
> is good in only one country.
For the purposes of an operational system there is an important
difference between a time scale which is practically available in real
time and a time scale which is not available until next month. There
is no available source for TAI, and in the current scheme of things
there cannot be one for there is no mechanism for distributing it.
There are two reasonably reliable worldwide time sources right now:
Russia's GLONASS and US GPS. GPS time is based on UTC(USNO).
UTC(USNO) is TA(USNO) minus leap seconds. Note that is TA(USNO), not
TAI(USNO), for USNO cannot define anything named TAI.
------------------------------
Date: Tue, 03 Jul 2007 11:52:45 -0700
From: Adriano Varoli Piazza <moranar@gmail.com>
Subject: retrieving news messages (was: Re: unlurking)
Message-Id: <1183488765.487169.240720@m36g2000hse.googlegroups.com>
Michele Dondi wrote:
[...]
> >#use strict;
> >use warnings;
[...]
> Is
> that your real code? Since you're under strict and warnings, what does
> perl really tell you when you run the program?
>
He isn't. He niftly commented use strict;
--
Saludos
Adriano
perl -e 'print "NYAPH\n";'
------------------------------
Date: Tue, 03 Jul 2007 10:02:40 -0700
From: "J.Cottingim" <jcottingim@yahoo.com>
Subject: set Bad variable type - SNMP::Util set
Message-Id: <1183482160.957038.234650@q69g2000hsb.googlegroups.com>
I'm writing a Perl script that will set several MIB variables.
When I run the script I get the following error messages:
STORE(SNMP::MIB=HASH(0x996ce74) enterprises.9.9.96.1.1.1.1.14
HASH(0x9aadf08)) : write access to the MIB not implemented
snmpset 10.10.1.1 index 5 .1.3.6.1.4.1.9.9.96.1.1.1.1.14 6
set Bad variable type (Sub-id not found: (top) -> enterprises)
Here's a very short version of the script:
---------------------------
#!/usr/bin/perl
use SNMP::Util;
$h = "10.10.1.1";
$c = "private";
$oid=".1.3.6.1.4.1.9.9.96.1.1.1.1.14";
$ix = "5";
$value="6"; #destroy
$session = new SNMP::Util(-device => $h,
-community => $c,
-timeout => 2);
$session->set(index => $ix,$oid => $value)
---------------------------
If I change the OID to something like .1.3.6.1.2.1.2.2.7
(ifAdminStatus) along with an appropriate index, the script runs fine.
The problem I think might have something do to with the fact that the
OID's index does not exist until the set operation is performed.
However, there are no snmp packets (of any sort) sent when the script
fails - so I know it's not doing a get operation prior to the set.
(verified with Wireshark)
Any thoughts/ideas would be greatly appreciated.
Thanks
JC
------------------------------
Date: Tue, 3 Jul 2007 15:44:31 -0400
From: "Wade Ward" <invalid@invalid.nyet>
Subject: Re: unlurking
Message-Id: <squdnbK-TuzAOhfbnZ2dnUVZ_hGdnZ2d@comcast.com>
"Michele Dondi" <bik.mido@tiscalinet.it> wrote in message
news:c57k83tbi8cr425jfekcgu1umcu639s64b@4ax.com...
> On Mon, 02 Jul 2007 18:16:09 +0000, Peter Makholm <peter@makholm.net>
> wrote:
>
>>> Nope, *almost* always and *including* on the first line, where it may
>>> have a special significance to the kernel of some osen.
>>
>>No, the #! line have speciel signicance to perl no matter if the line
>>have speciel significance to the kernel or not. 'perldoc perlrun'
>
> Yes, I knew but I oversimplified. Apologies to the OP for eventually
> it actually turned to convey a *false* information.
No worries. My information regarding Perl scripting is too incomplete to be
fragile.
--
WW
------------------------------
Date: Tue, 3 Jul 2007 15:48:20 -0400
From: "Wade Ward" <invalid@invalid.nyet>
Subject: Re: unlurking
Message-Id: <A8SdnSjpC5bfNRfbnZ2dnUVZ_syunZ2d@comcast.com>
"Gunnar Hjalmarsson" <noreply@gunnar.cc> wrote in message
news:5etm3mF3abli4U1@mid.individual.net...
> Wade Ward wrote:
>>
>> #!/usr/bin/env perl
>> #use strict;
> --^
One of the errors I was getting said "since you're using strict...."
Commenting it out was an attempt to remove an error,
> Don't post non-working code here that doesn't pass strictures!
... not an attempted coup.
--
WW
------------------------------
Date: Tue, 3 Jul 2007 15:51:56 -0400
From: "Wade Ward" <invalid@invalid.nyet>
Subject: Re: unlurking
Message-Id: <57GdnWpklcKHNBfbnZ2dnUVZ_silnZ2d@comcast.com>
"Scott Bryce" <sbryce@scottbryce.com> wrote in message
news:FdidnXh2U8FaNxTbnZ2dnUVZ_vShnZ2d@comcast.com...
> Wade Ward wrote:
>
>> #!/usr/bin/env perl
>> #use strict;
>> use warnings;
>> use Net::NNTP;
>>
>> my $nntp = Net::NNTP->new('newsgroups.comcast.net', { Debug => 1} );
>
> I am on Comcast, and that is not what I use as the news server name.
That's what binary vortex uses. If you can't trust your connection to porn,
you don't have much.
> Also, ask Perl to tell you whether this succeeds.
isn't that the purpose of
or die "Cannot contact $nntphost: $!";
?
> my $nntphost = 'news.comcast.net';
> my $nntp = Net::NNTP->new($nntphost) or die "Cannot contact $nntphost:
> $!";
> Have you read the docs for Net::NNTP yet? You have been given the URL
> twice.
Yes.
--
WW
------------------------------
Date: 3 Jul 2007 19:58:19 GMT
From: Glenn Jackman <glennj@ncf.ca>
Subject: Re: unlurking
Message-Id: <slrnf8lait.sud.glennj@smeagol.ncf.ca>
At 2007-07-03 03:48PM, "Wade Ward" wrote:
> "Gunnar Hjalmarsson" <noreply@gunnar.cc> wrote:
> > Wade Ward wrote:
> >> #use strict;
> > --^
> One of the errors I was getting said "since you're using strict...."
> Commenting it out was an attempt to remove an error,
You don't cure an illness by simply removing the symptoms.
Always "use strict" and fix what it reports.
--
Glenn Jackman
"You can only be young once. But you can always be immature." -- Dave Barry
------------------------------
Date: Tue, 3 Jul 2007 16:03:36 -0400
From: "Wade Ward" <invalid@invalid.nyet>
Subject: Re: unlurking
Message-Id: <At-dnZyB1O9LNhfbnZ2dnUVZ_vumnZ2d@comcast.com>
"Michele Dondi" <bik.mido@tiscalinet.it> wrote in message
news:6h8k835os7e6sqgq2bqc4gu0t2oaimasbl@4ax.com...
> On Mon, 2 Jul 2007 02:06:26 -0400, "Wade Ward" <invalid@invalid.nyet>
> wrote:
>
>>#begin excerpt
>
> From what?
This is excerpted from the document that everyone has asked me whether I've
read. Quiz me, I'm ready.
>>My guess is that my notion of a group is different from what Perlites(?)
>
> It depends on (i) what your notion is, which you don't explain and
> (ii) what you suspect Perlities(?) to think it is, which you also
> don't explain.
My background is algebra, of which group theory is a bulwark. They're
different ideas entirely.
>>think it is. I included "newgroups" because I thought it read
>>"newsgroups."
>
> Evidence is that "gruoup" is "newsgroup". NO reason why it should mean
> anything else. What could possibly make you think so?
I actually went back to look for a group with an extra 'u' in it. Anyways,
OP has _Programming Perl_ and _Perl in a nutshell_ in hand. Do these count
as standard references?
--
WW
------------------------------
Date: Tue, 3 Jul 2007 09:00:21 -0700
From: "Clenna Lumina" <savagebeaste@yahoo.com>
Subject: Re: using wildcards with -e
Message-Id: <5eva4nF3ants8U1@mid.individual.net>
Paul Lalli wrote:
> On Jun 28, 3:12 pm, "Clenna Lumina" <savagebea...@yahoo.com> wrote:
>> Paul Lalli wrote:
>>> On Jun 28, 2:49 pm, "Clenna Lumina" <savagebea...@yahoo.com>
>>> wrote:
>>
>>>> Grep works fine. But I want to know why Glob returns the way
>>>> it does in your original code?
>>
>>> Because glob() does something different depending on if its
>>> called in scalar context or list context.
>>
>> Would it not of been more logical to have it return the count
>> of the files it found, though?
[...]
> You'll note the context-based return value of glob() also matches the
> context-based return value of readdir(). All files in list context,
> "next" file in scalar context.
Thought I still have to wonder if it wouldn't of been better for it to
just behave like a normal list? I mean,
for(@arr) { ... }
iterates over the list.
while(@arr) { ... }
OTOH, gives you an infinite loop.
Now that I think about it, that behavior (get next file) is a more
useful, and would result in less memory usage. I guess the only
potential gripe I see is that it behaves in a way you wouldn't expect
the first time you used it.
>>> You either have an old and/or broken version of Perldoc, or
>>> you oddly omitted a section. In my perldoc, there is another
>>> sentence between those two:
>>
>> Hmm, I'm using Perl 5.6.1 on RH Linux and it does seem to lack that
>> section:
>
> I'd call that a documentation bug in 5.6.1. I verified the same thing
> with a 5.6.1 version on solaris. The function works the same as it
> does on 5.8, but the docs lack that rather important note.
Good to know. Thanks.
>>> Arrays evaluated in scalar context return their size. That's
>>> it. You cannot generalize "array" to "any expression returning
>>> a list." Any function returning a list of values in list
>>> context is free to do anything else in scalar context.
>>
>> Hmm, thanks for pointing that out. Yes it is easy to get into
>> that way of thinking, when many functions seem to return the
>> count (ie, map, grep) when used in scalar context.
>
> Oh, I agree. That's why I called it a trap. It gets easier to
> remember once you start writing your own subroutines that do something
> different depending on context, using the wantarray() function.
Yes I've seen many instances where it returns in a way you don't expect.
Although most of the built in functions (sort, grep, map, ...) that
return lists behave as you expect in scalar context too. 'grep' is
commonly used as an 'if' conditional, for example.
>>> If your version of perldoc really is missing that critical
>>> section, I suggest you check out the most recent version:
>>> http://perldoc.perl.org/functions/glob.html
>>
>> Thank you, I have saved this.
>
> You're welcome. Note that I generally recommend you use the version
> of the documentation that matches your version of Perl, but in this
> case, it's unfortunate that the docs themselves contain a bug..
I know the people who maintain them do a good job and it's impossible to
keep all of it up to date. I think it can be considered a lesson that
there can always be more to something then just what's written.
--
CL
------------------------------
Date: Tue, 03 Jul 2007 21:18:01 +0200
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: using wildcards with -e
Message-Id: <s08l835rs4urshfcq00vfesun29ilsu6n6@4ax.com>
On Tue, 3 Jul 2007 09:00:21 -0700, "Clenna Lumina"
<savagebeaste@yahoo.com> wrote:
>Now that I think about it, that behavior (get next file) is a more
>useful, and would result in less memory usage. I guess the only
I'm not really sure: I may be wrong but ISTR that glob() reads all the
entries behind the curtains anyway. Or there was some gotcha like
that. If you can call it gotcha...
>Yes I've seen many instances where it returns in a way you don't expect.
>Although most of the built in functions (sort, grep, map, ...) that
>return lists behave as you expect in scalar context too. 'grep' is
>commonly used as an 'if' conditional, for example.
ITYM within and if condition.
Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
.'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
------------------------------
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.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
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 V11 Issue 615
**************************************
