[31581] in Perl-Users-Digest
Perl-Users Digest, Issue: 2840 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun Feb 28 11:09:22 2010
Date: Sun, 28 Feb 2010 08:09:05 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Sun, 28 Feb 2010 Volume: 11 Number: 2840
Today's topics:
Re: eval exit/exec (was: macros: return or exit) <nospam-abuse@ilyaz.org>
Re: eval exit/exec (was: macros: return or exit) <ben@morrow.me.uk>
Re: eval exit/exec (was: macros: return or exit) <marc.girod@gmail.com>
Re: eval exit/exec (was: macros: return or exit) <marc.girod@gmail.com>
Re: eval exit/exec (was: macros: return or exit) <marc.girod@gmail.com>
Re: eval exit/exec (was: macros: return or exit) <marc.girod@gmail.com>
Re: eval exit/exec (was: macros: return or exit) <ben@morrow.me.uk>
Re: eval exit/exec <marc.girod@gmail.com>
Re: eval exit/exec <ben@morrow.me.uk>
Re: Requesting regular expression help sln@netherlands.com
Re: Requesting regular expression help <tadmc@seesig.invalid>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sat, 27 Feb 2010 23:22:23 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: eval exit/exec (was: macros: return or exit)
Message-Id: <slrnhoja9f.qc1.nospam-abuse@powdermilk.math.berkeley.edu>
On 2010-02-27, Marc Girod <marc.girod@gmail.com> wrote:
> BEGIN {
> if ($ENV{CLEARTOOL_PLX_LOOP}) {
> package ClearCase::Argv;
> *main::exit = sub { die @_, "\n" };
> *main::exec = sub { die system(@_), "\n" };
> }
> }
> Compilation failed in require at /usr/lib/perl5/5.10/Carp.pm line 33.
> Attempt to reload Carp/Heavy.pm aborted.
(At least with older versions of Perl) this means that a warning/error
is generated when "sitting deep in some tricky compilataion phase".
(So your module is not loaded in some "normal way".)
Just induce a harmless warning before loading your module, and/or load
your module early.
Hope this helps,
Ilya
------------------------------
Date: Sun, 28 Feb 2010 00:04:07 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: eval exit/exec (was: macros: return or exit)
Message-Id: <ngoo57-hit1.ln1@osiris.mauzo.dyndns.org>
Quoth Marc Girod <marc.girod@gmail.com>:
> On Feb 27, 9:07 pm, Ben Morrow <b...@morrow.me.uk> wrote:
>
> > These are not errors, they are warnings.
>
> OK.
>
> > They appear to be fairly self-explanatory...
>
> Apart for the fact that in the end, the
> behaviour of exit is still the original one...
> So that I don't understand what was overridden.
> Not what I intended...
You have defined the sub main::exit in two places. You have only
mentioned the variable $DB::single in one place. (Neither of these has
anything to do with exit not getting overridden.)
> > That is a separate issue from the warnings, and since I haven't seen
> > the code I have no idea as to the cause.
>
> *The* code?
> If I check it in my Google site, will you read
> it (given that you won't be able to run it as
> previously explained)?
No. However, if you cut out *everything* *possible* that doesn't make
the problem go away, including any third-party modules or external
binaries, and post the result, I might look at it. (If it's too long to
post there's almost certainly more you can cut out.) OTOH, you might
work it out yourself, or at least get down to a piece of code with only
*one* bug, which would be a start. This *will* be a lot of work, but
there's really no way around that.
> But let's say that within cleartool.plx,
> there is a 'one_cmd' function, and the
> new code there looks like this:
>
> my $rc = eval { $cmd->(@ARGV) };
Given the code below, you appear to be using $cmd as a symref. Don't do
that, use a hash of subrefs instead. If you are using 'strict' this will
always throw a 'Can't use string as a subroutine ref' error, which may
be the root of your problem. (Your problem in *this* bit of code, at any
rate. It has nothing to do with your problem overriding 'exit', which is
why you should take it out until you've solved that problem.)
You are also passing parameters to one_cmd in the global @ARGV variable.
Don't do that, pass an arrayref of arguments instead.
> if ($@) {
> chomp $@;
> $rc = $@;
> } else {
> warn "Normal return: $rc";
> }
> # ... and exit unless it returned zero.
> return $rc;
>
> And there is a loop a bit later such as:
>
> my $rc;
> require Text::ParseWords;
> while (my $line = <>) {
> chomp $line;
> last if $line eq 'quit';
> local @ARGV = Text::ParseWords::shellwords($line);
> $rc = one_cmd;
> }
> exit $rc;
>
> The problem so far being that in the case of 'des',
> $cmd->(@ARGV) never returns or dies: it just exits.
How do you know? I think the eval {} fails, with $@ = "Can't use...",
one_cmd returns, and the code above exits.
> I am sorry: I kind of believe you won't want to dig
> into this in that way either.
> This is a top-down way, and I believe it is not
> the right way to communicate. It is the way to
> avoid communications.
> I believe we should be able to drive this bottom-up
> which requires communications: that we understand
> what prevents each other from understanding.
I can't see what you are or are not understanding unless I see your
code. This doesn't mean I need to see the whole program, just some piece
of code you've written that you think ought to work, but doesn't.
> I don't say it is easy. I just believe it is the
> only scalable way, because it depends on 'local'
> complexity.
That is correct; but reducing the complexity of the problem is *your*
job, not mine.
Ben
------------------------------
Date: Sun, 28 Feb 2010 02:20:41 -0800 (PST)
From: Marc Girod <marc.girod@gmail.com>
Subject: Re: eval exit/exec (was: macros: return or exit)
Message-Id: <46be03bb-df68-44a4-bcd1-a678068ebbb7@d2g2000yqa.googlegroups.com>
On Feb 27, 11:22=A0pm, Ilya Zakharevich <nospam-ab...@ilyaz.org> wrote:
> Hope this helps,
Thanks... Yes, it helps, at least not to bother too much,
especially now that it disappeared.
Marc
------------------------------
Date: Sun, 28 Feb 2010 02:32:29 -0800 (PST)
From: Marc Girod <marc.girod@gmail.com>
Subject: Re: eval exit/exec (was: macros: return or exit)
Message-Id: <868a86e5-e50e-4aca-a386-5307aa44857c@t23g2000yqt.googlegroups.com>
On Feb 28, 12:04=A0am, Ben Morrow <b...@morrow.me.uk> wrote:
> That is correct; but reducing the complexity of the problem is *your*
> job, not mine.
Well, we managed more or less.
I got something to work now: thanks a lot!
I still have to clean it somewhat.
A few notes:
- @ARGV: I don't think I can change that. It is too
deep in the code I want to reuse, without changing
it; and not without reasons and advantages, in
terms of preserving the context of use of the
tool being emulated. This allows to switch back
and forth, e.g. for debugging purposes.
- How did I know: because I debugged it.
- $cmd: I am again walking from somewhere... I don't
clearly see the gain in suggesting to the original
author a change there...
- main::exit redefinition: I got it now, thanks to you
So, big thanks again.
I have an other question (and others coming for sure)
but it is for an other thread!
Marc
------------------------------
Date: Sun, 28 Feb 2010 04:39:43 -0800 (PST)
From: Marc Girod <marc.girod@gmail.com>
Subject: Re: eval exit/exec (was: macros: return or exit)
Message-Id: <f9813b48-3751-4a59-99fd-02746ed282cd@g26g2000yqn.googlegroups.com>
On Feb 28, 10:32=A0am, Marc Girod <marc.gi...@gmail.com> wrote:
> I have an other question (and others coming for sure)
> but it is for an other thread!
I found the answer to that one, but found another
which is more of a continuation of this thread...
I looked now at the last module I had forgotten
until now: Argv.
This one does define an 'exec' method, in which it
uses the 'exec' builtin.
If I override 'exec' prior to requiring the module,
I do get a warning for the redefinition, i.e. the
definition of the method.
Am I right to believe it is safe for me to ignore
it? The method will get defined, and use my own
overriding instead of the builtin?
It is a bit of a tricky fallback case when this one
would actually be invoked, if ever in the context
of the wrapper (this Argv module is not restricted
to be used for ClearCase...)
Marc
------------------------------
Date: Sun, 28 Feb 2010 05:05:39 -0800 (PST)
From: Marc Girod <marc.girod@gmail.com>
Subject: Re: eval exit/exec (was: macros: return or exit)
Message-Id: <8d963f21-8c49-4c03-8feb-7c33daf802b1@15g2000yqa.googlegroups.com>
On Feb 28, 12:39=A0pm, Marc Girod <marc.gi...@gmail.com> wrote:
> Am I right to believe it is safe for me to ignore
> it? The method will get defined, and use my own
> overriding instead of the builtin?
I believe I answered my own question:
ClearCase-Wrapper> cat ~/tmp/perl/redef
#!/usr/bin/perl -w
# no warnings qw(redefine);
my $exec =3D sub { print "my exec\n"; };
package Dummy;
*Foo::exec =3D $exec;
package Foo;
sub exec { print "Foo::exec: "; exec @_; }
Foo::exec '/bin/date';
print "foo\n";
ClearCase-Wrapper> ~/tmp/perl/redef
Subroutine Foo::exec redefined at /home/emagiro/tmp/perl/redef line 7.
my exec
foo
and I believe the asnwer is 'yes'.
Marc
------------------------------
Date: Sun, 28 Feb 2010 15:20:56 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: eval exit/exec (was: macros: return or exit)
Message-Id: <o7eq57-c052.ln1@osiris.mauzo.dyndns.org>
Quoth Marc Girod <marc.girod@gmail.com>:
> On Feb 28, 12:39 pm, Marc Girod <marc.gi...@gmail.com> wrote:
>
> > Am I right to believe it is safe for me to ignore
> > it? The method will get defined, and use my own
> > overriding instead of the builtin?
>
> I believe I answered my own question:
>
> ClearCase-Wrapper> cat ~/tmp/perl/redef
> #!/usr/bin/perl -w
>
> # no warnings qw(redefine);
>
> my $exec = sub { print "my exec\n"; };
> package Dummy;
> *Foo::exec = $exec;
> package Foo;
> sub exec { print "Foo::exec: "; exec @_; }
> Foo::exec '/bin/date';
> print "foo\n";
> ClearCase-Wrapper> ~/tmp/perl/redef
> Subroutine Foo::exec redefined at /home/emagiro/tmp/perl/redef line 7.
> my exec
> foo
>
> and I believe the asnwer is 'yes'.
No, you haven't, and no, it isn't :(.
The test is wrong because the 'sub exec' happens before the '*Foo::exec
= $exec'. Since this is all one file, the sub is compiled at compile
time and the assignment happens at run time, so your override gets
called. (Note that the original sub didn't get called, though, so this
still isn't quite what you need.)
However, if you put the assignment in a BEGIN block (as in your real
setup) you will find that the 'sub exec' completely wipes out your
override. The only way around this is to monkey-patch Argv after you
load it, and replace &Argv::exec with a copy of that sub that calls your
wrapper instead of the builtin. That is, you need
BEGIN {
require Argv;
no warnings "redefine";
*Argv::exec = sub {
# here copy the body of 'sub exec' from Argv.pm, but replace
# the two calls to 'exec(@cmd)' with '$exec->(@cmd)'.
};
}
before anything else tries to use Argv.
Ben
------------------------------
Date: Sat, 27 Feb 2010 15:30:08 -0800 (PST)
From: Marc Girod <marc.girod@gmail.com>
Subject: Re: eval exit/exec
Message-Id: <3b1b1c0c-e185-455e-b68f-66f65446d92e@g10g2000yqh.googlegroups.com>
On Feb 27, 10:58=A0pm, Ben Morrow <b...@morrow.me.uk> wrote:
> Perl starts in package 'main', so any code that comes before a 'package'
> statement is compiled in package main. I think you perlhaps need to
> review perlmod.
Quite possible indeed. I'll do it.
> Hmmm. Not quite. A statement like
>
> =A0 =A0 exec "one", "two";
>
> is usually compiled as a builtin. However, if there is a sub in the
> current package called 'exec', *and* that sub was exported into the
> current package by a different package, then it is compiled as a call to
> that sub instead.
OK... The clause *and* is still not quite clear to me,
but I'll try to work on it.
> No, not at all. 'main' is just the name of the default package. See
> above.
OK.
> OK, but since you are writing this as a module you must be at least
> implicitly assuming it might be used elsewhere. The usual method is to
> use 'caller' in your package's 'import' method, which will tell you
> which package the 'use' statement happed from:
The module is there... I believe in order to autoload
the split code... i.e. for performance reasons.
I don't see an other reason for now.
I cannot really see that it would be 'used'.
This is why it does exec and exit...
> =A0 =A0 package ClearCase::Argv;
>
> =A0 =A0 sub import {
> =A0 =A0 =A0 =A0 my $pkg =3D caller;
> =A0 =A0 =A0 =A0 {
> =A0 =A0 =A0 =A0 =A0 =A0 no strict 'refs';
> =A0 =A0 =A0 =A0 =A0 =A0 *{"$pkg\::exec"} =3D sub { ... };
> =A0 =A0 =A0 =A0 }
> =A0 =A0 =A0 =A0 # whatever else you need to do
> =A0 =A0 =A0 =A0 # if you want Exporter to work you can
> =A0 =A0 =A0 =A0 goto &Exporter::import;
> =A0 =A0 }
>
> Since it appears you are working 'backwards', and trying to change the
> behaviour of modules that aren't loaded yet, you need to explicitly
> export into ClearCase::Wrapper &c.
> OK. 'Member' is not usually used in that sense in Perl.
OK. I can just see that all my references only
confuse me.
> A function call (or sub call) looks like
>
> =A0 =A0 foo(1, 2, 3);
>
> or
>
> =A0 =A0 Some::Package::foo(1, 2, 3);
>
> The first form will look for a builtin with that name, or a 'sub foo' in
> the current package. The second form will always look for a 'sub foo' in
> Some::Package. A method call looks like
>
> =A0 =A0 Some::Package->foo(1, 2);
> =A0 =A0 $obj->foo(1, 2);
>
> and will look for a 'sub foo' in Some::Package or anything it inherits
> from, and call it with an implicit first argument. Method calls never
> compile as builtins, so you can have a method called 'exec' with no
> problems.
But it is 'defined' in the same way...
sub exec {...}
whether is is intended as a function or a method?
Something I have to grasp there...
> Is this 'exec' called as a method or a function? If it's called as a
> method, or if it's always called fully-qualified, you can simply ignore
> the fact it's called 'exec'.
Well, I now looked that indeed, it is always called
as a method. Which explains, as you said, that there
is no problem.
> If you wish to override CC::W's use of 'exec', this must happen *before*
> CC::W is loaded. This probably means you need to switch to using a
> module MGI::ClearCase, which does the overrides and *then* loads
> ClearCase::Wrapper, and avoid loading CC::W in cleartool.plx.
OK...
> I would say you want something like this:
>
> =A0 =A0 package MGI::ClearCase;
>
> =A0 =A0 use warnings;
> =A0 =A0 use strict;
>
> =A0 =A0 my $exec =3D sub {...};
> =A0 =A0 my $exit =3D sub {...};
>
> =A0 =A0 *ClearCase::Wrapper::exec =A0 =A0 =A0 =3D $exec;
> =A0 =A0 *ClearCase::Wrapper::exit =A0 =A0 =A0 =3D $exit;
> =A0 =A0 # leave CC::A::exec, since it's already being redefined
> =A0 =A0 *ClearCase::Argv::exit =A0 =A0 =A0 =A0 =A0=3D $exit;
> =A0 =A0 *ClearCase::Wrapper::DSB::exec =A0=3D $exec;
> =A0 =A0 *ClearCase::Wrapper::DSB::exit =A0=3D $exit;
>
> =A0 =A0 # 'require' not 'use', so it isn't loaded until after the overrid=
es
> =A0 =A0 require ClearCase::Wrapper;
>
> =A0 =A0 # more stuff
>
> =A0 =A0 1;
Because of the require, you don't need a BEGIN block?
With a BEGIN block, I can 'use' the module?
> You shouldn't get any 'redefined' warnings from this; if you do, it
> indicates a problem.
> No, they aren't functions (that is, Perl subs) at all, they're builtins.
OK. builtins are not functions!
Terminology again...
> They are recognised specially by the compiler, and compiled into special
> ops, *unless* they have been overridden at that point.
OK.
Now, I committed (produced) this:
Foo> cat foo
#!/usr/bin/perl -w
use strict;
BEGIN {
package Bar;
*Foo::exit =3D sub { die 'Died ', @_, "\n" }
}
use Foo;
my $foo =3D new Foo;
$foo->foo;
print "foo end\n";
exit 0;
Foo> perl -I. foo; echo $?
Foo:foo
Died 85
255
It looks already close...
Thanks a lot for your patience!
Marc
------------------------------
Date: Sun, 28 Feb 2010 00:18:50 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: eval exit/exec
Message-Id: <acpo57-hit1.ln1@osiris.mauzo.dyndns.org>
Quoth Marc Girod <marc.girod@gmail.com>:
> On Feb 27, 10:58 pm, Ben Morrow <b...@morrow.me.uk> wrote:
>
> > Hmmm. Not quite. A statement like
> >
> > exec "one", "two";
> >
> > is usually compiled as a builtin. However, if there is a sub in the
> > current package called 'exec', *and* that sub was exported into the
> > current package by a different package, then it is compiled as a call to
> > that sub instead.
>
> OK... The clause *and* is still not quite clear to me,
> but I'll try to work on it.
It is confusing. Really the only way to understand it is to play with
the different possibilities until you see what works and what doesn't.
> > A function call (or sub call) looks like
> >
> > foo(1, 2, 3);
> >
> > or
> >
> > Some::Package::foo(1, 2, 3);
> >
> > The first form will look for a builtin with that name, or a 'sub foo' in
> > the current package. The second form will always look for a 'sub foo' in
> > Some::Package. A method call looks like
> >
> > Some::Package->foo(1, 2);
> > $obj->foo(1, 2);
> >
> > and will look for a 'sub foo' in Some::Package or anything it inherits
> > from, and call it with an implicit first argument. Method calls never
> > compile as builtins, so you can have a method called 'exec' with no
> > problems.
>
> But it is 'defined' in the same way...
>
> sub exec {...}
>
> whether is is intended as a function or a method?
> Something I have to grasp there...
Yes. This is also a little confusing, and occasionally somewhat annoying
:).
> > I would say you want something like this:
> >
> > package MGI::ClearCase;
> >
> > use warnings;
> > use strict;
> >
> > my $exec = sub {...};
> > my $exit = sub {...};
> >
> > *ClearCase::Wrapper::exec = $exec;
> > *ClearCase::Wrapper::exit = $exit;
> > # leave CC::A::exec, since it's already being redefined
> > *ClearCase::Argv::exit = $exit;
> > *ClearCase::Wrapper::DSB::exec = $exec;
> > *ClearCase::Wrapper::DSB::exit = $exit;
> >
> > # 'require' not 'use', so it isn't loaded until after the overrides
> > require ClearCase::Wrapper;
> >
> > # more stuff
> >
> > 1;
>
> Because of the require, you don't need a BEGIN block?
> With a BEGIN block, I can 'use' the module?
Yes to both.
> > No, they aren't functions (that is, Perl subs) at all, they're builtins.
>
> OK. builtins are not functions!
> Terminology again...
Despite being documented in perlfunc... :). Actually, 'function' is used
somewhat ambiguously in Perl. It's often used to mean 'a Perl sub or a
builtin', while here I was using it to mean 'something called as a
function rather than a method'. What's important is to realise that the
builtins are fundamentally different from the things you define with
'sub', and they are (intentionally) a lot harder to redefine.
Ben
------------------------------
Date: Sun, 28 Feb 2010 06:37:14 -0800
From: sln@netherlands.com
Subject: Re: Requesting regular expression help
Message-Id: <j9sko550k9heo125lmsjtbvg8425id7a86@4ax.com>
On Sat, 27 Feb 2010 12:33:34 +0100, "Peter J. Holzer" <hjp-usenet2@hjp.at> wrote:
>On 2010-02-27 08:10, sln@netherlands.com <sln@netherlands.com> wrote:
>> On Sat, 27 Feb 2010 01:02:58 -0600, Tad McClellan <tadmc@seesig.invalid> wrote:
>>>sln@netherlands.com <sln@netherlands.com> wrote:
>>>> Kind of odd, only if the scalar is marked undefined
>>>> or is the code for '0' is it false.
>>>
>>>
>>>The "Truth and Falsehood" section in
>>>
>>> perldoc perlsyn
>>>
>>>states rather clearly what is considered false:
>>>
>>> The number 0, the strings C<'0'> and C<''>, the empty list C<()>, and
>> ^^^^^^
>> What a pity the single character '0' is valid data in while(<DATA>) :-)
>
>Doesn't matter.
>
> while (<FH>)
>is actually a shorthand for
> while (defined($_ = <FH>))
>so even if the last line of a file is "0" without a trailing newline,
>the loop will still be executed.
>
Yes, I see. I wish they didn't muck this up like this.
Its not used in any other conditional construct and
expanding the expression obliterates the shortcut.
while (($bar = <DATA>) && $flag )
produces traditional behavior (no shortcut), with a nice
little unwanted message:
Value of <HANDLE> construct can be "0"; test with defined() at ..
On, the other side, no message (no shortcut):
while ( $flag && ($bar = <DATA>))
The point being that one of these will get into its block,
the other won't.
if ($bar=<DATA>) { } # thanks message: Value of <HANDLE> construct can be ...
while ($bar=<DATA>) { } # no message here ..
where DATA contains the single character '0'.
I think there could be a more consistent approach but
this '0' is a conditional pivot between numbers and strings
that might facilitate buggy code otherwise.
Hey look, they made a single unique message to warn of this and
even silently pop in a short cut for you if you don't remember.
Well, sometimes.
-sln
------------------------------
Date: Sun, 28 Feb 2010 09:55:20 -0600
From: Tad McClellan <tadmc@seesig.invalid>
Subject: Re: Requesting regular expression help
Message-Id: <slrnhol486.5rb.tadmc@tadbox.sbcglobal.net>
sln@netherlands.com <sln@netherlands.com> wrote:
> On Sat, 27 Feb 2010 12:33:34 +0100, "Peter J. Holzer" <hjp-usenet2@hjp.at> wrote:
>
>> while (<FH>)
>>is actually a shorthand for
>> while (defined($_ = <FH>))
>>so even if the last line of a file is "0" without a trailing newline,
>>the loop will still be executed.
> while (($bar = <DATA>) && $flag )
> produces traditional behavior (no shortcut), with a nice
> little unwanted message:
> Value of <HANDLE> construct can be "0"; test with defined() at ..
The warning is wanted for the reason already given, this loop
might exit earlier than intended (because $flag will not be
evaluated if $bar eq '0').
> The point being that one of these will get into its block,
> the other won't.
> if ($bar=<DATA>) { } # thanks message: Value of <HANDLE> construct can be ...
> while ($bar=<DATA>) { } # no message here ..
while ($bar=<DATA>)
is actually a shorthand for
while (defined($bar=<DATA>))
(see for yourself with:
perl -MO=Deparse -e 'while ($bar=<DATA>) { }'
)
> where DATA contains the single character '0'.
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.liamg\100cm.j.dat/"
------------------------------
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 2840
***************************************
