Test skip()'ing weirdness
Hi,
I've had a report from a user regarding some tests under Darwin (10.5.6,
Leopard, I have no idea if it happens on earlier versions too). I've
since noticed the behaviour under 5.10 on Linux is not what I expected
either.
This is the test code:
#!perl -T
use strict;
use Test::More tests = 1;
SKIP: {
skip( meh, 1 );
ok( 1, dud );
}
Darwin (10.5.6, Leopard)
perl 5.8.8:
$ prove foo.t
foook
All tests successful.
Files=1, Tests=1, 0 wallclock secs ( 0.02 usr 0.00 sys + 0.02 cusr
0.00 csys = 0.04 CPU)
Result: PASS
perl 5.10.0:
$ prove foo.t
foook
1/1 skipped: various reasons
All tests successful, 1 subtest skipped.
Files=1, Tests=1, 0 wallclock secs ( 0.02 cusr + 0.00 csys = 0.02 CPU)
Still not what I excpected, but better than 5.8.8.
Linux (Ubuntu Server 8.04)
perl 5.8.8:
$ prove foo.t
foook
1/1 skipped: meh
All tests successful, 1 subtest skipped.
Files=1, Tests=1, 0 wallclock secs ( 0.05 cusr + 0.00 csys = 0.05 CPU)
perl 5.10.0:
$ prove foo.t
foook
All tests successful.
Files=1, Tests=1, 0 wallclock secs ( 0.05 usr 0.01 sys + 0.04 cusr
0.00 csys = 0.10 CPU)
Result: PASS
5.8.8 is the default system Perl in both Darwin and Linux, 5.10.0 was
installed manually by me. Can anyone please shine a light on this?
Cheers,
Pedro
Re: Test skip()'ing weirdness
Oh yeah, Test::More versions: Pedro Figueiredo wrote: Darwin (10.5.6, Leopard) perl 5.8.8: $ prove foo.t foook All tests successful. Files=1, Tests=1, 0 wallclock secs ( 0.02 usr 0.00 sys + 0.02 cusr 0.00 csys = 0.04 CPU) Result: PASS $ /usr/bin/perl -MTest::More -le 'print $Test::More::VERSION' 0.86 perl 5.10.0: $ prove foo.t foook 1/1 skipped: various reasons All tests successful, 1 subtest skipped. Files=1, Tests=1, 0 wallclock secs ( 0.02 cusr + 0.00 csys = 0.02 CPU) $ /usr/local/bin/perl -MTest::More -le 'print $Test::More::VERSION' 0.86 Still not what I excpected, but better than 5.8.8. Linux (Ubuntu Server 8.04) perl 5.8.8: $ prove foo.t foook 1/1 skipped: meh All tests successful, 1 subtest skipped. Files=1, Tests=1, 0 wallclock secs ( 0.05 cusr + 0.00 csys = 0.05 CPU) $ /usr/bin/perl -MTest::More -le 'print $Test::More::VERSION' 0.62 perl 5.10.0: $ prove foo.t foook All tests successful. Files=1, Tests=1, 0 wallclock secs ( 0.05 usr 0.01 sys + 0.04 cusr 0.00 csys = 0.10 CPU) Result: PASS $ /usr/local/bin/perl -MTest::More -le 'print $Test::More::VERSION' 0.86 5.8.8 is the default system Perl in both Darwin and Linux, 5.10.0 was installed manually by me. Can anyone please shine a light on this? Cheers, Pedro
Re: mod_perl PerlTransHandler weirdness
On Tue, Jun 17, 2003 at 10:43:27PM +0100, Phil Lanch wrote: On Tue, Jun 17, 2003 at 01:38:57PM +0100, Joel Bernstein wrote: On Tue, Jun 17, 2003 at 04:30:03AM -0700, Randal L. Schwartz wrote: you don't want $r-pathinfo (which won't be set during trans). you want $r-uri, which will be something like /THISBITHERE. The only difference that makes is to change the 404 Not Found to 400 Bad Request. you didn't mean numeric addition here (people might think you've been writing Java recently): Eek, does it show? :( - $r-internal_redirect($handlerpage++login=+$login); + $r-internal_redirect($handlerpage..login=.$login); Yes, my bad. I'd already fixed that, but it's good to get a sanity check :-) with this change and using $r-uri, it looks like it might be working, but i don't have PHP built in so can't test it convincingly. Doesn't seem to be. We've currently gone for a custom ErrorDocument 404 page, which does some processing and either 404s or redirects to the user page, having done a db lookup to check if it's a valid user. Which is a bit cracky, but is also how I suggested doing things in the first place (and was told it wasn't an option...) This one is really really bugging me - can anybody suggest an alternative way to do this redirection (I think it's too complicated a case for mod_rewrite)? but mod_rewrite is probably better. The problem (afaict) is that mod_rewrite doesn't offer enough granular control to apply the tests we were using. These may, of course, be overkill, or a result of working at the solution rather than at the problem. Thanks all for the help. /joel
Re: mod_perl PerlTransHandler weirdness
On Wed, Jun 18, 2003 at 11:58:39AM +0100, Joel Bernstein wrote: Doesn't seem to be. We've currently gone for a custom ErrorDocument 404 page, which does some processing and either 404s or redirects to the user page, having done a db lookup to check if it's a valid user. Which is a bit cracky, but is also how I suggested doing things in the first place (and was told it wasn't an option...) but mod_rewrite is probably better. The problem (afaict) is that mod_rewrite doesn't offer enough granular control to apply the tests we were using. These may, of course, be overkill, or a result of working at the solution rather than at the problem. the only test you've mentioned that i think mod_rewrite can't do is a db lookup to check if it's a valid user (assuming that means a lookup in an RDBMS; it *could* do a lookup in a plain DBM file). you could get round that by making mod_rewrite use an external filter program, but that could be a lot scarier than your custom 404 page solution ... -- Phil Lanch0xD78D598DA6635CF32AB24593C98994B7D95B33E3 If I knew then what I know now, I would have said 'I don't recall'. -- Frank Doyle, FBI
mod_perl PerlTransHandler weirdness
Hi, I would not be surprised if this problem has arisen due to me expecting more from Apache+mod_perl than it's capable of. The server is running Apache 1.3.mumble with mod_perl and mod_php. The site has been entirely built in PHP, by somebody else. They want the facility for http://foo.bar.com/david to redirect to http://foo.bar.com/?page=publicprofile.phpname=david . As I understand it, this needs to run at the URI Translation stage in Apache, which is exposed thru mod_perl via PerlTransHandlers. In the event that the request doesn't match these criteria, it needs to return control to Apache in order that the page gets served as normal (through mod_php). Without the handler in place, this all works, but the /david form doesn't, since there's no code in place to do it. Basically, I have a handler Apache::Publicprofile::Redirector::handler() which is in Apache/Publicprofile/Redirector.pm It is loaded in the site Apache config like: ##begin apache config excerpt## [ inside a VirtualHost block, outside Location block ] PerlModule Apache::Publicprofile::Redirector SetHandler perl-script PerlTransHandler Apache::Publicprofile::Redirector PerlSendHeader Off ##end apache config excerpt## I'm attaching the module, with a slight change to remove the actual webserver details, as requested by the guy whose project this is. I hope the code is self-explanatory, please query any bits that aren't. Currently, the behaviour exhibited is as follows: In any case, regardless of whether the handler is returning OK or DECLINED, Apache tries to serve the *source* of /index.php - ie without running it through mod_php. Is the issue perhaps that PerlTransHandler is the wrong stage to run at? Is it even possible to do what they want to do? Any help _much_ appreciated - I'm lost here! /joel Apache-Publicprofile-Redirector.pm Description: Perl program
Re: mod_perl PerlTransHandler weirdness
you don't want $r-pathinfo (which won't be set during trans). you want $r-uri, which will be something like /THISBITHERE. Then again, it's early here, so this could all be wrong. :) -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: mod_perl PerlTransHandler weirdness
On Tue, Jun 17, 2003 at 04:30:03AM -0700, Randal L. Schwartz wrote: you don't want $r-pathinfo (which won't be set during trans). you want $r-uri, which will be something like /THISBITHERE. That could well be the case, and I'll try it. I'm still inclined to think that it's an Apache thing rather than a mod_perl thing - does trans seem like the appropriate stage for this to run at? Also, even if it's failing on this count, then none of the cases should probably work, and it should be catching the return DECLINED; final catch-all case, no? In which case, for non-/name type pages (eg for /foo/bar/baz.html or /images/foo.jpg or even hopefully /index.php) shouldn't the behaviour be exactly as you'd expect from Apache without the transhandler running? Do I need to also emulate any other behaviour that Apache shows during the trans phase? Is it necessary to manually tell Apache to call the standard handlers for the other phases? I can't help but think that either I've missed something truly obvious, or that this is utterly impossible in mod_perl. Then again, it's early here, so this could all be wrong. :) Help appreciated nonetheless. /joel
Re: mod_perl PerlTransHandler weirdness
At 13:38 +0100 6/17/03, Joel Bernstein wrote: This one is really really bugging me - can anybody suggest an alternative way to do this redirection (I think it's too complicated a case for mod_rewrite)? I don't think so. I think this should do the trick: RewriteRule ^/david http://foo.bar.com/?page=publicprofile.phpname=david [R,L] or possibly even: RewriteRule ^/david /?page=publicprofile.phpname=david [R,L] It's been a while since I really fiddled with mod_rewrite much so please excuse me if this doesn't do the trick after all.. Liz
Re: mod_perl PerlTransHandler weirdness
On Tue, Jun 17, 2003 at 03:57:48PM +0200, Elizabeth Mattijsen wrote: At 13:38 +0100 6/17/03, Joel Bernstein wrote: This one is really really bugging me - can anybody suggest an alternative way to do this redirection (I think it's too complicated a case for mod_rewrite)? I don't think so. I think this should do the trick: RewriteRule ^/david http://foo.bar.com/?page=publicprofile.phpname=david [R,L] or possibly even: RewriteRule ^/david /?page=publicprofile.phpname=david [R,L] It's been a while since I really fiddled with mod_rewrite much so please excuse me if this doesn't do the trick after all.. I think you're misunderstanding what I'm doing. Did you read that code attached to the first mail? Should make it clear. Suffice to say, it's not specific cases like /david that we want to match. it'd be a general case of do these cases (eg, does it begin with a '?', is it in the form /.*/.*, ...) match? if so serve directly as Apache and mod_php normally would, otherwise if it's /.* with out another '.' or '/', then take the local bit after the / and redirect to /?page=page.phpname=thelocalbitgoeshere Does that make more sense? Liz /joel
Re: mod_perl PerlTransHandler weirdness
At 16:35 +0100 6/17/03, Joel Bernstein wrote: On Tue, Jun 17, 2003 at 03:57:48PM +0200, Elizabeth Mattijsen wrote: RewriteRule ^/david http://foo.bar.com/?page=publicprofile.phpname=david [R,L] or possibly even: RewriteRule ^/david /?page=publicprofile.phpname=david [R,L] I think you're misunderstanding what I'm doing. Did you read that code attached to the first mail? Should make it clear. Actually, I missed that and now that I've seen it, I'm not sure I understand. Suffice to say, it's not specific cases like /david that we want to match. it'd be a general case of do these cases (eg, does it begin with a '?', is it in the form /.*/.*, ...) match? if so serve directly as Apache and mod_php normally would, otherwise if it's /.* with out another '.' or '/', then take the local bit after the / and redirect to /?page=page.phpname=thelocalbitgoeshere Does that make more sense? Yep, it does. Could you try this then? (off the top of my hat, without a non-production mod_rewrite enabled apache at my disposal): RewriteRule ^/(\w+)$ /?page=publicprofile.phpname=$1 [R,L] Liz
Re: mod_perl PerlTransHandler weirdness
On Tue, Jun 17, 2003 at 01:38:57PM +0100, Joel Bernstein wrote: On Tue, Jun 17, 2003 at 04:30:03AM -0700, Randal L. Schwartz wrote: you don't want $r-pathinfo (which won't be set during trans). you want $r-uri, which will be something like /THISBITHERE. The only difference that makes is to change the 404 Not Found to 400 Bad Request. you didn't mean numeric addition here (people might think you've been writing Java recently): - $r-internal_redirect($handlerpage++login=+$login); + $r-internal_redirect($handlerpage..login=.$login); with this change and using $r-uri, it looks like it might be working, but i don't have PHP built in so can't test it convincingly. This one is really really bugging me - can anybody suggest an alternative way to do this redirection (I think it's too complicated a case for mod_rewrite)? but mod_rewrite is probably better. -- Phil Lanch0xD78D598DA6635CF32AB24593C98994B7D95B33E3 It's a button. You press it. Nobody gets hurt. Get over it. Unless it's a button that says SHOOT ME. -- David Pacheco
Re: [OT] map weirdness
Paul Makepeace wrote:
On Wed, May 28, 2003 at 10:42:55AM +0100, Dominic Mitchell wrote:
sub doit {
I like this method too, esp if combined with ?:
local $_ = $_;
return if $something;
return if $other_thing;
return 1;
}
Just for clarify, return requires a EXPR, it doesn't return $_ by
default.
return EXPR
return Returns from a subroutine, eval, or do FILE with the value
given in EXPR. Evaluation of EXPR may be in list, scalar, or
void context, depending on how the return value will be used,
and the context may vary from one execution to the next (see
wantarray). If no EXPR is given, returns an empty list in
list context, the undefined value in scalar context, and (of
course) nothing at all in a void context.
Yup. I tend to abuse the return alone means undef quite a lot though,
as you can see.
-Dom
Re: [OT] map weirdness
On Tue, 27 May 2003, Luis Campos de Carvalho wrote:
I need to know how I should return values from a map block at a given
point. Obvious, perl prevents me from using return inside a map block.
You can use an eval block to allow you this kind of control.
@array = map {
eval {
if( $something ){
return $thingy;
}
if( $other_thing ){
return @other_thingy;
}
return $last_thingy;
};
} @process_this_thing;
This will probably be slow, and inefficient, but if you really can't find
any other way to do it, it will work (so while it might not make sense in
the above simple case, there may be more complicated tasks you might want
to consider this construct.) Of course, you could just use a foreach
block, which reads better (for the above example at least:)
my @array;
foreach (@process_this_thing)
{
if( $something ){
push @array, $thingy;
next;
}
if( $other_thing ){
push @array, @other_thingy;
next;
}
push @array, $last_thingy;
}
Which is probably cleaner, though I assume since you asked about map you
have some chained map statements that you think work better like that. As
always, TMTOWTDI.
Mark.
--
#!/usr/bin/perl -T
use strict;
use warnings;
print q{Mark Fowler, [EMAIL PROTECTED], http://twoshortplanks.com/};
Re: [OT] map weirdness
Luis Campos de Carvalho wrote:
Hy list =-]
Straight to the point:
I have a map like this:
@array = map {
if( $something ){
# stop, return a scalar from this block.
}
if( $other_thing ){
# stop, return an array if we reach this point.
}
# return an scalar from here.
} @process_this_things;
I need to know how I should return values from a map block at a given
point. Obvious, perl prevents me from using return inside a map block.
So why not use a sub instead? Then you can return to your hearts content.
sub doit {
local $_ = $_;
return if $something;
return if $other_thing;
return 1;
}
@array = map(doit, @process_this_things);
You might get into slight trouble this way if $something and
$other_thing have limited scope. In that case, use a closure:
my $transform = sub {
local $_ = $_;
return if $something;
return if $other_thing;
return 1;
};
@array = map { $transform-() } @process_this_things;
I know that other people have already answered this question, but I hate
having more than one line in a map or grep call. So there. :-)
-Dom
Re: [OT] map weirdness
On Wed, May 28, 2003 at 10:42:55AM +0100, Dominic Mitchell wrote:
sub doit {
I like this method too, esp if combined with ?:
local $_ = $_;
return if $something;
return if $other_thing;
return 1;
}
Just for clarify, return requires a EXPR, it doesn't return $_ by
default.
return EXPR
return Returns from a subroutine, eval, or do FILE with the value
given in EXPR. Evaluation of EXPR may be in list, scalar, or
void context, depending on how the return value will be used,
and the context may vary from one execution to the next (see
wantarray). If no EXPR is given, returns an empty list in
list context, the undefined value in scalar context, and (of
course) nothing at all in a void context.
Paul
--
Paul Makepeace ... http://paulm.com/
If crazy men could fly, then how does he smell.
-- http://paulm.com/toys/surrealism/
[OT] map weirdness
Hy list =-]
Straight to the point:
I have a map like this:
@array = map {
if( $something ){
# stop, return a scalar from this block.
}
if( $other_thing ){
# stop, return an array if we reach this point.
}
# return an scalar from here.
} @process_this_things;
I need to know how I should return values from a map block at a given
point. Obvious, perl prevents me from using return inside a map block.
Can any body teach me a new perl mantra to solve this?
Thank you all very much in advance.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Luis Campos de Carvalho
Analista de sistemas
Intergal Sistemas
http://www.integral.com.br
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
PS: Oh! For those of you that are curious about
what-the-heck-I'm-doing, I'm using Image::Magick perl interface to
handle some sequencial images. If you think you can help, I'm gladly
accept suggestions. Please email me and tell me what you think.
=cut
Re: [OT] map weirdness
On Tue, May 27, 2003 at 03:54:40PM -0300, Luis Campos de Carvalho ([EMAIL PROTECTED])
wrote:
Hy list =-]
Straight to the point:
I have a map like this:
[snip]
I need to know how I should return values from a map block at a given
point. Obvious, perl prevents me from using return inside a map block.
Can any body teach me a new perl mantra to solve this?
The obvious thing would be to change it into an if/elsif/else block.
That way you can guarantee that exactly one branch will be executed.
@array = map {
if( $something ){
# stop, return a scalar from this block.
} elsif( $other_thing ){
# stop, return an array if we reach this point.
} else {
# return an scalar from here.
}
} @process_this_things;
Tho' I might be tempted to write that as:
@array = map { $something ? $scalar :
$other_thing ? @array : $other_scalar
} @process_this_things;
Dave...
--
Brian: Oh screw Maximilian!
Sally: I do.
Brian: So do I.
Weirdness
Given Perl v5.8.0, stable version at Sep 19 2002 00:33:39, the following
are all valid Perl expressions:
3 * 9
3 ** 9
3 * * 9
3 * * * * 9
3 ** * 9
3 ** * * 9
3 ** * * * 9
3 ** * * * * 9
3 * * *
The following is not:
3 * * * 9
Of course this is a very ed up thing to try, don't ask me why I did.
But can anyone explain?
S.
--
Shevek
I am the Borg.
sub AUTOLOAD{my$i=$AUTOLOAD;my$x=shift;$i=~s/^.*://;print$x\n;eval
qq{*$AUTOLOAD=sub{my\$x=shift;return unless \$x%$i;{$x}(\$x);};};}
foreach my $i (3..65535) { {'2'}($i); }
Re: Weirdness
On Sun, Nov 03, 2002 at 11:14:44AM +, Shevek wrote:
Given Perl v5.8.0, stable version at Sep 19 2002 00:33:39, the following
are all valid Perl expressions:
3 * 9
3 ** 9
3 * * 9
3 * * * * 9
3 ** * 9
3 ** * * 9
3 ** * * * 9
3 ** * * * * 9
3 * * *
The following is not:
3 * * * 9
Of course this is a very ed up thing to try, don't ask me why I did.
But can anyone explain?
Given this:
perl -le 'print * * '
*main::*
and my limited knowledge of how tokenisers work
when expecting a term, ** or * * will be interpreted as a typeglob of * in main
when expecting an expression, ** will be interpreted as exponentiation
when expecting an expression, * will be interpreted as multiply
and it seems that:
perl -le 'print * 9 '
*main::9
*main::* and *main::9 aren't numeric, so they are treated as 0.
so you had
3 times 9
3 to the power of 9
3 times *main::9
3 times *main::* times 9
3 to the power of *main::9
then '3 ** * * 9' isn't valid, so you must have typed that somewhere.
3 to the power of *main::* times 9
3 to the power of *main::* times *main::9
3 times *main::*
none of the above was checked with Deparse. Here's the last one, as seen by
Deparse:
perl5.8.0 -MO=Deparse -le 'print 3 ** * * * * 9'
BEGIN { $/ = \n; $\ = \n; }
print 3 ** ** * *9;
-e syntax OK
And the reason I know all this - blame Abigail.
(a sig with ** something which has the value 1. ie 0 ** 0, which perl is
treating as 1. I don't know enough serious maths to know if 0 ** 0 is well
defined. See perl6-language for more maths)
Nicholas Clark
--
Brainfuck better than perl? http://www.perl.org/advocacy/spoofathon/
Re: Weirdness
On Sun, Nov 03, 2002 at 11:34:53AM +, Nicholas Clark wrote: [ question and explanation elided ] And the reason I know all this - blame Abigail. (a sig with ** something which has the value 1. ie 0 ** 0, which perl is treating as 1. I don't know enough serious maths to know if 0 ** 0 is well defined. See perl6-language for more maths) 0 ** x and x ** 0 have different limits as x approaches 0, so if I recall correctly , 0 ** 0 is an indeterminate form, but it is generally accepted (I think) that 1 is the most useful answer because that makes little things like the binomial theorem work properly. Disclaimer - it's many years since I did any real maths. [ Now waiting for someone to say it shows, and give a real answer. ] -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: Array Ref Weirdness
Paul Makepeace wrote: ... OK, OK, so _ is strictly an alphanum; YKWIM. That's debatable. OK, so Perl and C think so (because it can be part of identifiers), but I think most folks on the street would lump it with punctuation. Just like '$', despite the fact that some platforms allow *that* in identifiers (VMS and some flavours of Pascal [HP?] spring to mind). Cheers, Philip -- Philip Newton [EMAIL PROTECTED] datenrevision GmbH Co. OHG http://www.datenrevision.de a gedas company TEL +49-40-797 007-37 Cuxhavener Str. 36, D-21149 Hamburg FAX +49-40-797 007-10
Re: Array Ref Weirdness
On Mon, Dec 10, 2001 at 10:59:47AM -0800, Randal L. Schwartz wrote: ... My hunch is that this works in the same way that @a-[3] ... works, in that an array name is sometimes automatically a ... reference to that array, even though the language definition would ... argue otherwise. I've heard it would take deep voodoo to get the ... current interpreter to have the right info to reject that Yes, I'd heard the same. It's not true though - I wrote a two-line patch (which is in bleadperl) that gives a warning for @foo-[23] and so on. The warning should be upgraded to an error for 5.10, if anyone remembers to do it. .robin.
Array Ref Weirdness
This came up on Perlmonks earlier today.
Code A works as you would expect.
A) push @{ /PAT/ ? \@match : \@nonmatch }, $_ foreach @words;
Code B gives a strange error (you'd expect it not to work, but you might
not be able to guess the error).
B) push @{ /PAT/ ? @match : @nonmatch }, $_ foreach @words;
Given that Code B generates an error, why does Code C work?
C) push @{ $_ % 2 ? @odd : @even }, $_ foreach @ints;
Is it a bug?
Dave...
--
.sig missing...
Re: Array Ref Weirdness
On Mon, Dec 10, 2001 at 06:50:05PM +, Dave Cross wrote:
Given that Code B generates an error, why does Code C work?
C) push @{ $_ % 2 ? @odd : @even }, $_ foreach @ints;
Because C) has seven pieces of uncontrived punctuation in a row
interrupted only by a lone '2' character.
Paul
... OK, OK, so _ is strictly an alphanum; YKWIM.
Re: Array Ref Weirdness
Dave == Dave Cross [EMAIL PROTECTED] writes:
Dave This came up on Perlmonks earlier today.
Dave Code A works as you would expect.
Dave A) push @{ /PAT/ ? \@match : \@nonmatch }, $_ foreach @words;
Dave Code B gives a strange error (you'd expect it not to work, but you might
Dave not be able to guess the error).
Dave B) push @{ /PAT/ ? @match : @nonmatch }, $_ foreach @words;
Dave Given that Code B generates an error, why does Code C work?
Dave C) push @{ $_ % 2 ? @odd : @even }, $_ foreach @ints;
Dave Is it a bug?
Did you see my reply?
... My hunch is that this works in the same way that @a-[3]
... works, in that an array name is sometimes automatically a
... reference to that array, even though the language definition would
... argue otherwise. I've heard it would take deep voodoo to get the
... current interpreter to have the right info to reject that, so
... we'll have to wait until perl 6, where it'll be blessed instead of
... cursed. {grin}
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
[EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
