[32398] in Perl-Users-Digest
Perl-Users Digest, Issue: 3665 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat Apr 14 09:09:28 2012
Date: Sat, 14 Apr 2012 06: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 Sat, 14 Apr 2012 Volume: 11 Number: 3665
Today's topics:
Emacs Lisp vs Perl: Validate Local File Links <xahlee@gmail.com>
Re: Emacs Lisp vs Perl: Validate Local File Links <despen@verizon.net>
eval and Try::Tiny (Tim McDaniel)
Re: eval and Try::Tiny <rweikusat@mssgmbh.com>
Re: eval and Try::Tiny (Tim McDaniel)
Re: eval and Try::Tiny <rweikusat@mssgmbh.com>
Re: eval and Try::Tiny <ben@morrow.me.uk>
Re: eval and Try::Tiny <rvtol+usenet@xs4all.nl>
Re: Help with a hash <rweikusat@mssgmbh.com>
Re: Help with perl special variable riccardo.marini@gmail.com
Howto print postmatch variable with perl one-liner? <cibalo@gmx.co.uk>
Re: Howto print postmatch variable with perl one-liner? <ben@morrow.me.uk>
Re: Missing utf8_heavy.pl <jimoeDESPAM@sohnen-moe.com>
Re: Missing utf8_heavy.pl <rweikusat@mssgmbh.com>
Re: Missing utf8_heavy.pl <ben@morrow.me.uk>
Re: New module name (Eclipse::PHPMe) <brunodepaulak@gmail.com>
Why does this code works without cat ? <narutocanada@gmail.com>
Re: Why does this code works without cat ? <jurgenex@hotmail.com>
Re: Why does this code works without cat ? <ben@morrow.me.uk>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 13 Apr 2012 10:35:32 -0700 (PDT)
From: Xah Lee <xahlee@gmail.com>
Subject: Emacs Lisp vs Perl: Validate Local File Links
Message-Id: <af59724c-c91b-4201-b40d-3717a75c07a5@8g2000pbm.googlegroups.com>
=E3=80=88Emacs Lisp vs Perl: Validate Local File Links=E3=80=89
http://xahlee.org/emacs/elisp_vs_perl_validate_links.html
a comparison of 2 scripts.
lots code, so i won't paste plain text version here.
i have some comments at the bottom. Excerpt:
------------------
=C2=ABOne thing interesting is to compare the approaches in perl and emacs
lisp.=C2=BB
=C2=ABFor our case, regex is not powerful enough to deal with the problem
by itself, due to the nested nature of html. This is why, in my perl
code, i split the file by < into segments first, then, use regex to
deal with now the non-nested segment. This will break if you have <a
title=3D"x < href=3Dz" href=3D"math.html">math</a>. This cannot be worked
around unless you really start to write a real parser.=C2=BB
=C2=ABThe elisp here is more powerful, not because of any lisp features,
but because emacs's buffer datatype. You can think of it as a
glorified string datatype, that you can move a cursor back and forth,
or use regex to search forward or backward, or save cursor positions
(index) and grab parts of text for further analysis.=C2=BB
------------------
If you are a perl coder, and disagree, let me know your opinion.
(showing working code is very welcome) My comment about perl there
applies to python too. (python code welcome too.)
Xah
------------------------------
Date: Fri, 13 Apr 2012 14:54:44 -0400
From: Dan Espen <despen@verizon.net>
Subject: Re: Emacs Lisp vs Perl: Validate Local File Links
Message-Id: <icsjg7xy17.fsf@home.home>
Xah Lee <xahlee@gmail.com> writes:
> 〈Emacs Lisp vs Perl: Validate Local File Links〉
> http://xahlee.org/emacs/elisp_vs_perl_validate_links.html
>
> a comparison of 2 scripts.
>
> lots code, so i won't paste plain text version here.
>
> i have some comments at the bottom. Excerpt:
>
> ------------------
>
> «One thing interesting is to compare the approaches in perl and emacs
> lisp.»
>
> «For our case, regex is not powerful enough to deal with the problem
> by itself, due to the nested nature of html. This is why, in my perl
> code, i split the file by < into segments first, then, use regex to
> deal with now the non-nested segment. This will break if you have <a
> title="x < href=z" href="math.html">math</a>. This cannot be worked
> around unless you really start to write a real parser.»
>
> «The elisp here is more powerful, not because of any lisp features,
> but because emacs's buffer datatype. You can think of it as a
> glorified string datatype, that you can move a cursor back and forth,
> or use regex to search forward or backward, or save cursor positions
> (index) and grab parts of text for further analysis.»
>
> ------------------
>
> If you are a perl coder, and disagree, let me know your opinion.
> (showing working code is very welcome) My comment about perl there
> applies to python too. (python code welcome too.)
Interesting.
Perl, Python, and Lisp have real HTML parsers available.
I've used the ones for Perl and Python.
--
Dan Espen
------------------------------
Date: Fri, 13 Apr 2012 16:57:52 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: eval and Try::Tiny
Message-Id: <jm9lug$hhq$1@reader1.panix.com>
Miscellaneous neepery on the subject of eval and Try::Tiny.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#! /usr/bin/perl
use strict;
use warnings;
use Try::Tiny;
use Data::Dumper;
my $eval = eval {die 'In eval'};
print Data::Dumper->Dump([$eval, $@], [qw[eval error]]), "\n=====\n";
my $error = '';
my $try = try { die 'In try with naive catch' } catch { $error = $_; };
print Data::Dumper->Dump([$try, $error], [qw[try error]]), "\n=====\n";
$try = try { die 'In try with larger catch' } catch { $error = $_; return };
print Data::Dumper->Dump([$try, $error], [qw[try error]]), "\n";
exit 0;
Output:
$ perl local/test/052.pl
$eval = undef;
$error = 'In eval at local/test/052.pl line 7.
';
=====
$try = 'In try with naive catch at local/test/052.pl line 11.
';
$error = 'In try with naive catch at local/test/052.pl line 11.
';
=====
$try = undef;
$error = 'In try with larger catch at local/test/052.pl line 14.
';
Indeed, checking the code as of 5.8.8, and the most recent source
under http://search.cpan.org/~doy/Try-Tiny-0.11/lib/Try/Tiny.pm, catch
is invoked with
for ($error) {
return $catch->($error);
}
(I think it's stupid as all hell, but whatever.) So I think I can
replace
some_lhs = eval { body };
# uses of $@
with
my $error;
some_lhs = try { body } catch { $error = $_; return };
# uses of $error
Is that right?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I've run across cases of
eval string_value
that I want to replace. Since the code for Try::Tiny localizes $@,
I think I can get away with
try { eval string_value; die $@ if $@ } catch { $error = $_; return }
Anyone see a problem with that?
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Fri, 13 Apr 2012 18:28:40 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: eval and Try::Tiny
Message-Id: <87ty0nv8vr.fsf@sapphire.mobileactivedefense.com>
tmcd@panix.com (Tim McDaniel) writes:
> Miscellaneous neepery on the subject of eval and Try::Tiny.
[...]
> my $error = '';
> my $try = try { die 'In try with naive catch' } catch { $error = $_; };
> print Data::Dumper->Dump([$try, $error], [qw[try error]]), "\n=====\n";
[...]
> $try = 'In try with naive catch at local/test/052.pl line 11.
> ';
> $error = 'In try with naive catch at local/test/052.pl line 11.
> ';
[...]
> Indeed, checking the code as of 5.8.8, and the most recent source
> under http://search.cpan.org/~doy/Try-Tiny-0.11/lib/Try/Tiny.pm, catch
> is invoked with
>
> for ($error) {
> return $catch->($error);
> }
>
> (I think it's stupid as all hell, but whatever.)
The idea behind that is obviously that the catching subroutine might
be able to handle the error (Perl still supports real exception
objects) and should thus have the option to inform the caller that no
error occurred.
> So I think I can
> replace
>
> some_lhs = eval { body };
> # uses of $@
>
> with
>
> my $error;
> some_lhs = try { body } catch { $error = $_; return };
> # uses of $error
>
> Is that right?
You can also insert a system('perl -c "sleep(86400);"') in
any place there and the result will be that the working code
still works, just in a less efficient way. Actually, using the
sleep-invocation is a much more efficient way to burn time than
downloading $random_crap from CPAN whose only purpose is to "work
around" what some guy didn't understand about Perl exception handling
in particular and the concept of using exceptions for error handling in
general. You don't even have to take my word for that, it's also all
spelled out in the Perl 5.14.0 release notes available here:
http://perldoc.perl.org/perl5140delta.html#Exception-Handling
------------------------------
Date: Fri, 13 Apr 2012 18:43:25 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: eval and Try::Tiny
Message-Id: <jm9s4d$jek$1@reader1.panix.com>
In article <87ty0nv8vr.fsf@sapphire.mobileactivedefense.com>,
Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
>tmcd@panix.com (Tim McDaniel) writes:
>> [Try::Tiny: catch returns a value]
>> (I think it's stupid as all hell, but whatever.)
>
>The idea behind that is obviously that the catching subroutine might
>be able to handle the error (Perl still supports real exception
>objects) and should thus have the option to inform the caller that no
>error occurred.
Good point. It just makes it a touch annoying for *my particular*
case, a drop-in replacement for eval, but I quite take your point
about other cases.
>all spelled out in the Perl 5.14.0 release notes available here:
My workplace is on an older version of Perl, I can't upgrade it, and I
don't know when they'll upgrade.
>Actually, using the sleep-invocation is a much more efficient way to
>burn time than downloading $random_crap from CPAN
Try::Tiny is a long-standing package and not uncommon package, hardly
"random crap".
>whose only purpose is to "work around" what some guy didn't
>understand about Perl exception handling in particular and the
>concept of using exceptions for error handling in general.
What do I do to use raw Perl to get reliable exceptions in older Perls?
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Fri, 13 Apr 2012 21:01:42 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: eval and Try::Tiny
Message-Id: <87mx6ftn89.fsf@sapphire.mobileactivedefense.com>
tmcd@panix.com (Tim McDaniel) writes:
> Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
[...]
>>all spelled out in the Perl 5.14.0 release notes available here:
>
> My workplace is on an older version of Perl, I can't upgrade it, and I
> don't know when they'll upgrade.
In this case, this text provides some nice documentation regarding
what the actual gotchas with eval and $@ are. There are two possible
problem cases: Provided that object destructors are executed during
exception unwinding occurring while existing from the eval,
- $@ will be cleared when code running from a destructor calls
eval
- $@ will be overwritten when code running from such a
destructor throws an exception itself
Both issues can be avoided by adding a local $@ at the start of all
destructors which might either die or use eval.
>>Actually, using the sleep-invocation is a much more efficient way to
>>burn time than downloading $random_crap from CPAN
>
> Try::Tiny is a long-standing package and not uncommon package, hardly
> "random crap".
The copyright notice says 2009 which means it is a good fourteen years
younger than the facility it is supposed to fix. And neither "it is
old" (which it isn't) nor "many people like it" are indicators for any
particular technical quality.
------------------------------
Date: Fri, 13 Apr 2012 22:16:48 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: eval and Try::Tiny
Message-Id: <0nhm59-rv4.ln1@anubis.morrow.me.uk>
Quoth tmcd@panix.com:
>
> Indeed, checking the code as of 5.8.8, and the most recent source
> under http://search.cpan.org/~doy/Try-Tiny-0.11/lib/Try/Tiny.pm, catch
> is invoked with
>
> for ($error) {
> return $catch->($error);
> }
>
> (I think it's stupid as all hell, but whatever.)
Rainer has already explained why this is useful. I'm not quite sure what
you would *expect* a try/catch block to return, if not the last
statement executed in the last block run. The code outside isn't
supposed to know an error occurred at all: either the catch block
handled it, and returned something sensible, or it threw again and the
outside code never ran.
> So I think I can
> replace
>
> some_lhs = eval { body };
> # uses of $@
>
> with
>
> my $error;
> some_lhs = try { body } catch { $error = $_; return };
> # uses of $error
>
> Is that right?
Why are you not just writing
try {
some_lhs = body;
}
catch {
# uses of $_
};
? If you want to run code regardless of errors, but still have access to
the error if there was one, use 'finally'.
If you can provide more concrete examples of the constructions you are
trying to rewrite, including in particular all the logic that deals with
$@, it will be easier to see how they can be structured into catch and
finally blocks.
(It is annoying that try/catch/finally have separate lexical scopes.
Perl 6 has the right idea: there exception catching looks like
try {
some_lhs = body;
CATCH { # called on error }
LEAVE { # always called }
}
with both CATCH and LEAVE within the lexical scope established by try.
Once upon a time I started implementing this for Perl 5, but alas never
got to the point of it being usable.)
> I've run across cases of
>
> eval string_value
>
> that I want to replace. Since the code for Try::Tiny localizes $@,
> I think I can get away with
>
> try { eval string_value; die $@ if $@ } catch { $error = $_; return }
>
> Anyone see a problem with that?
The same as with eval{}: any destructor which touches $@ will clobber
your error, so you might end up not dying when you were supposed to. If
you want to do this right, you need to copy the logic from Try::Tiny,
replacing block-eval with string-eval; otherwise you might as well just
leave the code as it is. I don't think wrapping Try::Tiny around it buys
you anything in this case.
(What you want is 'eval without try', which you can get using
Parse::Perl. The implementation of that module is more than a little
scary...)
Ben
------------------------------
Date: Sat, 14 Apr 2012 09:57:06 +0200
From: "Dr.Ruud" <rvtol+usenet@xs4all.nl>
Subject: Re: eval and Try::Tiny
Message-Id: <4f892dce$0$6975$e4fe514c@news2.news.xs4all.nl>
On 2012-04-13 18:57, Tim McDaniel wrote:
> eval string_value; die $@ if $@
That should be written as:
eval "$string; 1" or die $@ || 'zombie error';
--
Ruud
------------------------------
Date: Thu, 12 Apr 2012 21:28:13 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Help with a hash
Message-Id: <87pqbczode.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
>>
>> my @levels;
>>
>> while ($ARGV[0] =~ /(.)/g) {
>> $levels[$1] = 1;
>> $1 =~ /[0-6]/ or die("invalid run-level $1");
>> }
>>
>> printf("%d\t%s\n", $_, $levels[$_] ? 'on' : 'off') for (0 .. 6);
>> ------------
>>
>> NB: This doesn't check if ARGV[0] is empty or not available at all.
>>
>> NB^2: Settting $levels[$1] and the check for invalid values have to be
>> done in this order to avoid clobbering $1.
>
> So use an ordinary variable instead:
>
> while (my ($l) = $ARGV[0] =~ /./g) {
> $l =~ /[0-6]/ or die ...;
> $levels[$l] = 1;
> }
This looks like an additional complication that buys exactly nothing.
------------------------------
Date: Fri, 13 Apr 2012 00:46:23 -0700 (PDT)
From: riccardo.marini@gmail.com
Subject: Re: Help with perl special variable
Message-Id: <22292377.1112.1334303183375.JavaMail.geo-discussion-forums@vbuo5>
Il giorno gioved=EC 12 aprile 2012 18:01:13 UTC+2, Tim McDaniel ha scritto:
> In article <24881700.650.1334222359841.JavaMail.geo-discussion-forums@vbu=
e17>,
> <riccardo.marini@gmail.com> wrote:
> >I m now using following code:=20
> >..
> > if ( my @capture =3D /$regex[$i]/ ) {
> > my $result =3D $destination[$i];
> > print "CAPTURE: @capture\n";
> > print "BEFORE s//: $result\n";
> > $result =3D~ s/\$([0-9]+)/$capture[$1-1]/eg;
> > print "AFTER s//: $result\n";
> > }
> >..
> >
> >And works fine.
> >I only added "$1-1' cause "$1" will be out of index in @capture.
> >This should be safer, and should work against any or multiple $[0-9]
> >in my configuration line.
>=20
> I think it would be a little better if you sure that a reference is
> valid before referring to it.
>=20
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>=20
> #! /usr/bin/perl
> use strict;
> use warnings;
>=20
> my $regexp =3D '^(.)(.)'; # boobies!
> $_ =3D 'ABC';
> if (my @capture =3D /$regexp/) {
> my $result =3D 'left $1 right $2 invalid $3';
> print "CAPTURE: '", join("' '", @capture), "'\n";
> print "BEFORE s//: '$result'\n";
> my $bad =3D 0;
> foreach my $ref ($result =3D~ /\$([0-9]+)/g) {
> if (! exists $capture[$ref-1]) {
> warn "result '$result' refers to \$$ref, which is not capture=
d in the regexp.\n";
> $bad =3D 1;
> }
> }
> if ($bad) {
> die "Dying due to bad element reference.\n";
> }
> $result =3D~ s/\$([0-9]+)/$capture[$1-1]/eg;
> print "AFTER s//: '$result'\n";
> }
> exit 0;
>=20
>=20
> --=20
> Tim McDaniel, tmcd@panix.com
Nice. I ll protect it using "exists".
I love your regex :)
tks
------------------------------
Date: Fri, 13 Apr 2012 22:39:40 -0700 (PDT)
From: cibalo <cibalo@gmx.co.uk>
Subject: Howto print postmatch variable with perl one-liner?
Message-Id: <189e10c8-d833-4ba7-9ae9-ee4d55c427c0@oo9g2000pbc.googlegroups.com>
Hello,
I can print the postmatch variable with a perl script as follows:
#!/usr/bin/perl -w
$str = "abcdefghi"; $str =~ /def/; print "$`:$&:$'\n";
For perl one-liner, I can print without the $' as follows:
$ perl -e '$str = "abcdefghi"; $str =~ /def/; print "$`:$&:\n";'
abc:def:
But, I cannot print with $' as follows:
$ perl -e '$str = "abcdefghi"; $str =~ /def/; print "$`:$&:$'\n";'
Can you please let me know what I'm missing?
Thank you very much in advance!!!
Best Regards,
cibalo
------------------------------
Date: Sat, 14 Apr 2012 11:59:26 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Howto print postmatch variable with perl one-liner?
Message-Id: <et1o59-vhc.ln1@anubis.morrow.me.uk>
Quoth cibalo <cibalo@gmx.co.uk>:
> Hello,
>
> I can print the postmatch variable with a perl script as follows:
> #!/usr/bin/perl -w
> $str = "abcdefghi"; $str =~ /def/; print "$`:$&:$'\n";
>
> For perl one-liner, I can print without the $' as follows:
> $ perl -e '$str = "abcdefghi"; $str =~ /def/; print "$`:$&:\n";'
> abc:def:
> But, I cannot print with $' as follows:
> $ perl -e '$str = "abcdefghi"; $str =~ /def/; print "$`:$&:$'\n";'
You're falling foul of shell quoting. The shell interprets the ' in $'
as closing the single-quotes begun after -e, so then you get a big mess.
By far the easiest way around this is to use the /p flag introduced in
5.10. While this was implemented for efficiency reasons, all you really
care about is that it uses different variable names:
perl -e'"abcdefghi" =~ /def/p;
print "${^PREMATCH}:${^MATCH}:${^POSTMATCH}\n";'
After that you're left with various forms of quoting. The cleanest is to
avoid $' altogether:
perl -e'"abcdefghi" =~ /(.*?)def(.*)/; print "$1:$2:$3\n"'
(obviously with /s if you need it).
If that's too awkward you need to quote the ', either in shell or in
Perl. Quoting it in shell is a bit messy: shell doesn't honour \'
inside single quotes, so you have to do it like this:
perl -e'"abcdefghi" =~ /def/; print "$`:$&:$'\''\n";'
Quoting it in Perl looks simpler but is actually more complicated: if
you write
perl -e'"abcdefghi" =~ /def/; print "$`:$&:${chr 39}\n";'
it will work, but if you take away both $` and $& it will mysteriously
stop working. That's because perl doesn't bother to save values for
those three variables unless it saw them at compile-time (because it's
extremely expensive), and ${chr 39} is a symref which the compiler can't
see at compile time.
Ben
------------------------------
Date: Fri, 13 Apr 2012 13:03:40 -0700
From: James Moe <jimoeDESPAM@sohnen-moe.com>
Subject: Re: Missing utf8_heavy.pl
Message-Id: <pN6dnad9iewDGxXSnZ2dnUVZ5r2dnZ2d@giganews.com>
On 04/08/2012 11:49 AM, James Moe wrote:
> perl v5.14.2
> "Mainloop: Can't locate utf8_heavy.pl in @INC"
> How do I resolve this problem?
>
As a workaround I copied utf8*, unicore/* and Unicode/* to a path in
the ASSP directory to emulate the path perl would search in @INC to
locate the modules.
What I do not understand, or how to correct, is how perl can find most
of its modules after the app switches to chroot, but not utf8*. Is there
some sort of pre-load function?
--
James Moe
jmm-list at sohnen-moe dot com
------------------------------
Date: Fri, 13 Apr 2012 21:06:25 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Missing utf8_heavy.pl
Message-Id: <87iph3tn0e.fsf@sapphire.mobileactivedefense.com>
James Moe <jimoeDESPAM@sohnen-moe.com> writes:
> On 04/08/2012 11:49 AM, James Moe wrote:
>> perl v5.14.2
>> "Mainloop: Can't locate utf8_heavy.pl in @INC"
>> How do I resolve this problem?
>>
> As a workaround I copied utf8*, unicore/* and Unicode/* to a path in
> the ASSP directory to emulate the path perl would search in @INC to
> locate the modules.
> What I do not understand, or how to correct, is how perl can find most
> of its modules after the app switches to chroot, but not utf8*. Is there
> some sort of pre-load function?
If 'the app switches to chroot', this presumably happens after perl
compiled it (so the compiler found the modules) and when the code
later tries to include another file, eg, by using do or require, the
chroot blocks access.
NB: This is of course just a speculation.
------------------------------
Date: Fri, 13 Apr 2012 22:22:57 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Missing utf8_heavy.pl
Message-Id: <h2im59-rv4.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
> James Moe <jimoeDESPAM@sohnen-moe.com> writes:
> > On 04/08/2012 11:49 AM, James Moe wrote:
> >> perl v5.14.2
> >> "Mainloop: Can't locate utf8_heavy.pl in @INC"
> >> How do I resolve this problem?
> >>
> > As a workaround I copied utf8*, unicore/* and Unicode/* to a path in
> > the ASSP directory to emulate the path perl would search in @INC to
> > locate the modules.
> > What I do not understand, or how to correct, is how perl can find most
> > of its modules after the app switches to chroot, but not utf8*. Is there
> > some sort of pre-load function?
>
> If 'the app switches to chroot', this presumably happens after perl
> compiled it (so the compiler found the modules) and when the code
> later tries to include another file, eg, by using do or require, the
> chroot blocks access.
Sounds likely. If this is the case, a better workaround would be to
compile a list of the files your code loads after entering chroot,
and explicitly preload them (with require) beforehand. Unless you've got
code that messes around clearing %INC, perl will not then need to reload
them when they're requested later.
Ben
------------------------------
Date: Fri, 13 Apr 2012 17:23:51 -0700 (PDT)
From: kinow <brunodepaulak@gmail.com>
Subject: Re: New module name (Eclipse::PHPMe)
Message-Id: <20d5b6f6-4746-49c6-94be-738607c1fc0e@f17g2000yqj.googlegroups.com>
Hi Ben!
Thanks for the explanation, you were very clear :-)
I'll the PHP::PHPMe as the module name for now, but when submitting to
Pause I will take a look at modules@perl.org to check if the name is
fine too.
Thank you very very much.
All the best,
Bruno
On Apr 10, 5:23=A0pm, Ben Morrow <ben@morrow.me.uk> wrote:
> Quoth kinow <brunodepaulak@yahoo.com.br>:
>
>
>
> > App seems to be the right place for this application. However, I think
> > App::PHPMe would not be the right name for it. Maybe
> > App::Eclipse::PHPMe, or App::EclipsePHPMe? What do you think?
>
> What is the executable that gets installed called? If it's called phpme,
> I'd call the distribution App::PHPMe, since you've effectively already
> 'claimed' that name; if it's called something like eclipse_phpme or is
> installed somewhere where it only gets called fromEclipse, I'd call it
> App::Eclipse::PHPMe.
>
> > By the way, do I need to talk with someone else about using the App
> > namespace prefix?
>
> No. In general names on CPAN are first-come, first-served. There are a
> few official restrictions, mostly now quite old (for instance, names
> under DBI:: are restricted), and there is an unofficial convention that
> putting your module under the namespace of an existing module with many
> supplied sub-modules (like, say, Catalyst, or Plack) should only be done
> after coordinating with the author(s) of that module, but generic
> top-level namespaces like App:: are free-for-all.
>
> If you want advice about module naming from the people who run CPAN and
> PAUSE, you can write to the modules@perl.org mailing list.
>
> Ben
------------------------------
Date: Fri, 13 Apr 2012 17:53:38 -0700 (PDT)
From: naruto canada <narutocanada@gmail.com>
Subject: Why does this code works without cat ?
Message-Id: <a4dc17f5-7826-48fc-835c-885739644c06@w6g2000pbp.googlegroups.com>
hi
I've encountered this code some times ago:
#!/usr/bin/env perl
$i=1;
while (<>) {
if (($len = length($_)) > $lmax) {
$lmax = $len;
@longest =($i.":$_");
}
elsif ($len == $lmax) {
push(@longest, $i.":$_");
}
$i=$i+1;
}
print @longest;
This code print longest lines from stdin. Strangely, it works without
cat. If my understanding is correct, "<>" (stdin) should require "cat"
to work. Can someone explain it?
Right now, for example, it works both ways like:
cat 1.txt | longest.line.pl
longest.line.pl 1.txt
------------------------------
Date: Fri, 13 Apr 2012 19:48:05 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Why does this code works without cat ?
Message-Id: <r7pho7p8qp4t246878kj7h2pbjonc73d8g@4ax.com>
naruto canada <narutocanada@gmail.com> wrote:
>cat 1.txt | longest.line.pl
And again someone applying for the useless use of cat award.
If you want to use a file as standard input for a program then at least
do it without cat:
longest.line.pl < 1.txt
jue
------------------------------
Date: Sat, 14 Apr 2012 11:39:38 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Why does this code works without cat ?
Message-Id: <ao0o59-53c.ln1@anubis.morrow.me.uk>
Quoth naruto canada <narutocanada@gmail.com>:
>
> This code print longest lines from stdin. Strangely, it works without
> cat.
It must be hiding somewhere. Cats are very sneaky.
> If my understanding is correct, "<>" (stdin) should require "cat"
> to work. Can someone explain it?
> Right now, for example, it works both ways like:
> cat 1.txt | longest.line.pl
> longest.line.pl 1.txt
You need to read the section called 'I/O Operators' in perldoc perlop,
in particular the paragraph starting 'The null filehandle <> is
special: ...'.
Ben
------------------------------
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 3665
***************************************
