[25609] in Perl-Users-Digest

home help back first fref pref prev next nref lref last post

Perl-Users Digest, Issue: 7853 Volume: 10

daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Mar 4 06:05:59 2005

Date: Fri, 4 Mar 2005 03:05:25 -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           Fri, 4 Mar 2005     Volume: 10 Number: 7853

Today's topics:
        cant display generated html in browser (perl script) (Piet L.)
    Re: cant display generated html in browser (perl script <nobull@mail.com>
    Re: disagree with a few things in perlsec <tadmc@augustmail.com>
    Re: disagree with a few things in perlsec <newspost@kohombanDELETE.net>
    Re: disagree with a few things in perlsec <newspost@kohombanDELETE.net>
    Re: disagree with a few things in perlsec el_roachmeister@yahoo.com
    Re: disagree with a few things in perlsec el_roachmeister@yahoo.com
    Re: disagree with a few things in perlsec <matternc@comcast.net>
    Re: disagree with a few things in perlsec nospam@geniegate.com
    Re: disagree with a few things in perlsec <do-not-use@invalid.net>
        goto &Package::func destroying @_?! <not@invalid.invalid>
    Re: goto &Package::func destroying @_?! <nobull@mail.com>
    Re: goto &Package::func destroying @_?! (Anno Siegel)
    Re: How to specify [regex] beginning of line/unlimited  <tadmc@augustmail.com>
    Re: How to specify [regex] beginning of line/unlimited  <jgibson@mail.arc.nasa.gov>
    Re: How to specify [regex] beginning of line/unlimited  <ljames@apollo3.com>
    Re: How to specify [regex] beginning of line/unlimited  <jkeen_via_google@yahoo.com>
    Re: Log::Agent in ActivePerl Windows? <jkeen_via_google@yahoo.com>
    Re: Log::Agent in ActivePerl Windows? <jkeen_via_google@yahoo.com>
    Re: minor re, problelm <georgekinley@hotmail.com>
    Re: mod_perl hosting <lawrence.tierney@bipcontracts.com>
        Msql-Mysql-modules: unable to find my mySQL 'include' d francescomoi@europe.com
        negative backreference? eric.hall@gmail.com
    Re: negative backreference? (Anno Siegel)
        Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)

----------------------------------------------------------------------

Date: 3 Mar 2005 22:03:07 -0800
From: PietLaroy@hotmail.com (Piet L.)
Subject: cant display generated html in browser (perl script)
Message-Id: <c47f81f6.0503032203.268fa55@posting.google.com>

Hey,
I've written a perl script which creates an xml file based on input
parameters.
Now I have an xslt to display the information, but the problem is that
my browser (microsoft internet explorer) can not display the info.

Here is what I use to generate the xml/xslt transformation

my $xslt = XML::XSLT->new (myxsl, warnings => 1);
$xslt->transform (myxsl);
print $xslt->toString;
##print $xslt->serve(myxml);
$xslt->dispose();


My xslt looks like

<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
	<xsl:output method="html" encoding="ISO-8859-1"/>
	<xsl:template match="/">
		<html><head>
                <link rel="stylesheet" 
href="http://www.vub.ac.be/styles/vub.css" type="text/css"/>
		</head><body><div id="pageheader"><h1><span>XXX</span></h1>
		</div><div id="content"><div id="content"><div
id="contenttitle"><h2><span>MY CONTENTTITLE</span></h2></div><div
id="contenttext"><xsl:for-each select="//publication"><ul><li
value="0"><h4>
		<xsl:value-of select="//title_1"/></h4><xsl:value-of
select="//name"/></li></ul></xsl:for-each>
	</div></div></div></body></html></xsl:template></xsl:stylesheet>


I didn't display the xml and so, because the transformation works when
I test it in an xslt editor.

The only thing that is display is the title and so, 
Does my problem have to do with the xml::xslt parser? And so, how do I
solve this?

thx


------------------------------

Date: Fri, 04 Mar 2005 08:58:59 +0000
From: Brian McCauley <nobull@mail.com>
Subject: Re: cant display generated html in browser (perl script)
Message-Id: <d097mh$2v$1@sun3.bham.ac.uk>

Piet L. wrote:

> I've written a perl script which creates an xml file based on input
> parameters.

The fact that the XML was generated by Perl does not necessarily make 
this a Perl question.

> Now I have an xslt to display the information, but the problem is that
> my browser (microsoft internet explorer) can not display the info.
> 
> Here is what I use to generate the xml/xslt transformation
> 
> my $xslt = XML::XSLT->new (myxsl, warnings => 1);
> $xslt->transform (myxsl);
> print $xslt->toString;
> ##print $xslt->serve(myxml);
> $xslt->dispose();

I've never used XML::XSLT but from a quick look at the documentation it 
appears that transform() should be open_xml().  Also you do now show us 
the definitions of the myxsl and myxml functions.

Please produce a _minimal_ but _complete_ script.

Anyhow this is not the 'right' way to use XSL on the web.  You should 
simply put a processing instruction in the XML to tell the browser where 
to fetch the XSLT.



------------------------------

Date: Thu, 3 Mar 2005 20:00:17 -0600
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: disagree with a few things in perlsec
Message-Id: <slrnd2fg9h.444.tadmc@magna.augustmail.com>

el_roachmeister@yahoo.com <el_roachmeister@yahoo.com> wrote:
> 
> Tad McClellan wrote:
> 
>> Because it is not "protected" by obscurity.
>>
>> Obscurity only reduces the odds, it is still not "protected" it
>> is merely "hidden" (which might be Good Enough in some situations).
> 
> Dictionary
> pro·tect (pr?-t?kt') pronunciation
> tr.v., -tect·ed, -tect·ing, -tects.
> 
>    1. To keep from being damaged, attacked, stolen, or injured; guard
> 
> Obscurity accomplishes this, 


No it doesn't. That is the point being made in the docs.

Obscurity does not "keep from being damaged" it only reduces the odds 
of it being damaged.

Having 10 people who can break in instead of 1000 people who
can break in is not "keeping it from damage".

Thanks for providing the definition that supports my position.  :-)


> therefore obscurity protects.

Uh huh.


-- 
    Tad McClellan                          SGML consulting
    tadmc@augustmail.com                   Perl programming
    Fort Worth, Texas


------------------------------

Date: Fri, 04 Mar 2005 10:10:41 +0800
From: GreenLeaf <newspost@kohombanDELETE.net>
Subject: Re: disagree with a few things in perlsec
Message-Id: <38pufmF5qumdhU1@individual.net>

el_roachmeister@yahoo.com wrote:

> A wealthy person hides a treasure on an island.

How much wealthy is irrelevant. Where do *you* prefer to keep *your* 
money? Bank or Island? :o)

And why?


------------------------------

Date: Fri, 04 Mar 2005 10:18:30 +0800
From: GreenLeaf <newspost@kohombanDELETE.net>
Subject: Re: disagree with a few things in perlsec
Message-Id: <38puubF5qk2v1U1@individual.net>

el_roachmeister@yahoo.com wrote:
> 
> Obscurity accomplishes this, therefore obscurity protects.
> 

It does not "accomplish" anything. It reduces the *chance* of a security 
breach. Any security that *relies* on chance is almost as good as no 
security.

An old saying I vaguely remember: "First you must tie your camels and 
*then* pray the gods" (that they don't stray away).


------------------------------

Date: 3 Mar 2005 18:29:43 -0800
From: el_roachmeister@yahoo.com
Subject: Re: disagree with a few things in perlsec
Message-Id: <1109903383.740131.308650@l41g2000cwc.googlegroups.com>


GreenLeaf wrote:

> How much wealthy is irrelevant. Where do *you* prefer to keep *your*
> money? Bank or Island? :o)
>
> And why?

I would "prefer" to keep it in a bank located on an island ;-)



------------------------------

Date: 3 Mar 2005 18:40:04 -0800
From: el_roachmeister@yahoo.com
Subject: Re: disagree with a few things in perlsec
Message-Id: <1109904004.108043.193420@l41g2000cwc.googlegroups.com>


Tad McClellan wrote:
> Obscurity does not "keep from being damaged" it only reduces the odds

> of it being damaged.

For that matter nothing can "absolutely" keep anything from being
damaged. Life is all about probabilities and risk. No input guarantees
a certain output, whether it's perl code or anything else. So obscurity
is not protection and neither is "correct" perl code.

> Having 10 people who can break in instead of 1000 people who
> can break in is not "keeping it from damage".

Again using your logic, nothing can keep it from being damaged. Or can
you name something?



------------------------------

Date: Thu, 03 Mar 2005 22:50:30 -0500
From: Chris Mattern <matternc@comcast.net>
Subject: Re: disagree with a few things in perlsec
Message-Id: <Lp-dnRrJ2rabRrrfRVn-tQ@comcast.com>

el_roachmeister@yahoo.com wrote:

> The more obscure you make your script, the fewer the number of pirates
> who can find it. The fewer the number of pirates means the less chance
> of one of them cracking it.  I really don't see what is wrong in this
> logic?

What is wrong with this logic is you are proposing obscuring your script
from "pirates" by making it unusable.  This may make it more secure, but
does not seem really practical.
> 
>  Whether obscurity is the primary or secondary way to secure your code
> entirely depends on the situation. In majority of cases it will not be
> the best way to secure it, but any script that is secure is only one
> way is very not secure at all. This is where I feel perslec needs to
> either eliminate the reference to obscurity or give it the proper
> credit it is due in the greater scheme of things.

-- 
             Christopher Mattern

"Which one you figure tracked us?"
"The ugly one, sir."
"...Could you be more specific?"


------------------------------

Date: Fri, 04 Mar 2005 09:29:31 GMT
From: nospam@geniegate.com
Subject: Re: disagree with a few things in perlsec
Message-Id: <Lucy11099183714670xb27028@air.tunestar.net>

In: <1109882174.262420.288990@g14g2000cwa.googlegroups.com>, el_roachmeister@yahoo.com wrote:
>If you are concerned about security you why are you going to let people
>on your local system see your source? The default should be 700. You
>would only need 755 if you have a definite need to do so.

That point is well taken, I'd have to agree it's valid. (However,
it's obviously assuming multiple users are executing it)

>Security by obscurity is very helpful in reducing your risks. The
>perlsec makes it sounds like it has no effect on protecting it. I
>suggest perslec either eliminate any comments about security by
>obscurity since that really has nothing to do with perl anyways. Or
>they should be more realistic about what it really means.

For stuff intended to be used by others, (0755 in /usr/local/bin) obscurity is
actually a liability, what good is your program if only hackers can find it?

I wouldn't call it "very helpful" maybe a first line of defense, but it's a bit
like protecting your house by covering the door knob with bird poop.

It's better than nothing at all, for single users I guess.

>The convenience store in the bad neighborhood will always get robbed
>day in and day out, while the billions of dollars sitting in bank
>accounts that nobody knows exists will remain untouched.

I think a bank that looks like an airplane and secures it's assets by hiding 
them in the gas tank would have a hard time with customer confidence.

Jamie
-- 
http://www.geniegate.com                    Custom web programming
guhzo_42@lnubb.pbz (rot13)                User Management Solutions


------------------------------

Date: 04 Mar 2005 12:00:07 +0100
From: Arndt Jonasson <do-not-use@invalid.net>
Subject: Re: disagree with a few things in perlsec
Message-Id: <yzdmztjwua0.fsf@invalid.net>


Tad McClellan <tadmc@augustmail.com> writes:
> Chris Mattern <matternc@comcast.net> wrote:
> > el_roachmeister@yahoo.com wrote:
> >> A. Sinan Unur wrote:
> >>> el_roachmeister@yahoo.com wrote in news:1109882174.262420.288990
> >>> @g14g2000cwa.googlegroups.com:
> 
> 
> >>> But, then, your posting history does tell us something:
> >>> 
> >>> http://tinyurl.com/5nzcp
> >> 
> >> Is referencing this really neccessarry?
> > 
> > Probably not; the link is dead, so we can't find out what the Perl
> > advice Sinan thought was amusing was.
> 
> 
>    Message-ID: <5d705481.0410241000.649a77e1@posting.google.com>

I think he meant that the link referenced in that posting is dead. It
is for me, anyway:

"A. Sinan Unur" <u...@llenroc.ude.invalid> wrote in message news:<Xns958CE837A2D0asu1cornelledu@132.236.56.8>...
   > Just for laughs:
   > 
   > http://www.unc.edu/~husted/Work/PerlReference.htm#anchor8


------------------------------

Date: Fri, 04 Mar 2005 15:13:50 +1000
From: Matthew Braid <not@invalid.invalid>
Subject: goto &Package::func destroying @_?!
Message-Id: <d08qqe$172u$1@bunyip2.cc.uq.edu.au>

Hi all,

Unfortunately this is another one that I can't reproduce in a small 
script, but maybe the description will trigger something from someone....

In the system I'm writing library functions can be extended like so:

package Core;
use base qw/Exporter/;
{
	no strict 'refs';
	sub import { # This code severely chopped down to basics
		# Redefine import so that overrides are noticed even
		# in places where the original function has already been
		# imported
		my $class = shift;
		my @funcs = @_;
		my ($caller) = caller();
		for my $f (@funcs) {
			*{"$caller\::$f"} = sub {goto &{"$class\::$f"}};
		}
	}
}
sub foo {
	print "Core::foo GOT (@_)\n";
}
# --- In a file not so very far away...
package Extension;
BEGIN {
	require Core;
	my $old = \&Core::foo;
	sub foo {
		print "Ext::foo GOT (@_)\n";
		goto &$old;
	}
	*Core::foo = \&foo;
}

Of course, extensions can be extended etc etc. The problem I've run in 
to is the goto bit - it seems that if the level of 'extension' is too 
high, the destination of the goto ends up with @_ full of undefs - right 
number of args, wrong values. Even stranger is that if I was expecting a 
hashref keying some objects and I have:

	$arg->{ObjectName}->method;

instead of the usual "Can't call method "method" on an undefined value" 
error, the script is terminated with a signal 11.

Oddly enough, if I throw in the otherwise useless line:

	@_ = @_;

just before the goto, suddenly it works again.

So there is a workaround - either the odd '@_ = @_' thing which looks 
too much like a smiley or instead of goto& just simply call the old 
function as in $old->(@_), but I'm thinking the destruction of @_ and 
the terminate on signal 11 thing may be a bug in perl itself.

Any ideas?

MB


------------------------------

Date: Fri, 04 Mar 2005 09:14:55 +0000
From: Brian McCauley <nobull@mail.com>
Subject: Re: goto &Package::func destroying @_?!
Message-Id: <d098ke$h1$1@sun3.bham.ac.uk>



Matthew Braid wrote:

> Unfortunately this is another one that I can't reproduce in a small 
> script, but maybe the description will trigger something from someone....

It does.

In the last few weeks I've seen a post that shows that there does appear 
to be a bug with the first element of @_ and goto.

Unfortunately having searched comp.lang.perl.* and PerlMonks I can't 
locate it.



------------------------------

Date: 4 Mar 2005 09:43:47 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: goto &Package::func destroying @_?!
Message-Id: <d09akj$aqk$1@mamenchi.zrz.TU-Berlin.DE>

Matthew Braid  <not@invalid.invalid> wrote in comp.lang.perl.misc:
> Hi all,
> 
> Unfortunately this is another one that I can't reproduce in a small 
> script, but maybe the description will trigger something from someone....
> 
> In the system I'm writing library functions can be extended like so:
> 
> package Core;
> use base qw/Exporter/;

Why are you making Exporter a base class?  You're not using it.

> {
> 	no strict 'refs';
> 	sub import { # This code severely chopped down to basics
> 		# Redefine import so that overrides are noticed even
> 		# in places where the original function has already been
> 		# imported
> 		my $class = shift;
> 		my @funcs = @_;
> 		my ($caller) = caller();
> 		for my $f (@funcs) {
> 			*{"$caller\::$f"} = sub {goto &{"$class\::$f"}};

A sub that does nothing but "goto &foo" is equivalent to foo.  As given,
you might as well say

    *{"$caller\::$f"} = \ &{"$class\::$f"};

> 		}
> 	}
> }
> sub foo {
> 	print "Core::foo GOT (@_)\n";
> }
> # --- In a file not so very far away...
> package Extension;
> BEGIN {
> 	require Core;
> 	my $old = \&Core::foo;
> 	sub foo {
> 		print "Ext::foo GOT (@_)\n";
> 		goto &$old;
> 	}
> 	*Core::foo = \&foo;

Here you are changing the package Core.  Normally an importing module
has no business doing that.

> }
> 
> Of course, extensions can be extended etc etc. The problem I've run in 
> to is the goto bit - it seems that if the level of 'extension' is too 

Which goto?  There is one in Core and one in Extension.

> high, the destination of the goto ends up with @_ full of undefs - right 
> number of args, wrong values.

How high is too high?  With your code the arguments are handed down
just fine.

> Even stranger is that if I was expecting a 
> hashref keying some objects and I have:
> 
> 	$arg->{ObjectName}->method;
> 
> instead of the usual "Can't call method "method" on an undefined value" 
> error, the script is terminated with a signal 11.

Signal numbers are system-dependent.  Is that a SEGV?

> Oddly enough, if I throw in the otherwise useless line:
> 
> 	@_ = @_;
> 
> just before the goto, suddenly it works again.
> 
> So there is a workaround - either the odd '@_ = @_' thing which looks 
> too much like a smiley or instead of goto& just simply call the old 
> function as in $old->(@_), but I'm thinking the destruction of @_ and 
> the terminate on signal 11 thing may be a bug in perl itself.

We (or anyone else concerned, like p5p) would have to see the effect.
Your code doesn't show it.

Anno


------------------------------

Date: Thu, 3 Mar 2005 19:55:26 -0600
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: How to specify [regex] beginning of line/unlimited characters/no spaces terminatingn with ":"
Message-Id: <slrnd2fg0e.444.tadmc@magna.augustmail.com>

L. D. James <ljames@apollo3.com> wrote:
> "Jim Keenan" <jkeen_via_google@yahoo.com> wrote in message 
> news:1109885401.403847.38770@o13g2000cwo.googlegroups.com...

>> you should consult the
>> documentation (or the Camel book) re:  non-greedy pattern matching.

>      Thanks, I'll look to order the book since I'm very interested in 
> regular expressions.


While the Camel book is the canonical reference for Perl and it
is good to have eventually, most of its important parts are
already sitting there on your hard disk in the form of the
documentation that comes with perl.

The book to get if you want to know everything about regular
expressions is:

   "Mastering Regular Expressions"  2nd edition


>      Is it possible that using the stars "*" for the record separator rather 
> than the new line would make it easier to grab the comment field, which has 
> numerous new lines?


Yes.


-- 
    Tad McClellan                          SGML consulting
    tadmc@augustmail.com                   Perl programming
    Fort Worth, Texas


------------------------------

Date: Thu, 03 Mar 2005 18:23:26 -0800
From: Jim Gibson <jgibson@mail.arc.nasa.gov>
Subject: Re: How to specify [regex] beginning of line/unlimited characters/no spaces terminatingn with ":"
Message-Id: <030320051823260008%jgibson@mail.arc.nasa.gov>

In article <XNNVd.85733$g16.9250@trndny08>, Jim Keenan
<jkeen_via_google@yahoo.com> wrote:

> Jim Gibson wrote:
> > In article <1109885401.403847.38770@o13g2000cwo.googlegroups.com>, Jim
> > Keenan <jkeen_via_google@yahoo.com> wrote:
> > 
> >>
> >>while (<DATA>) {
> >>    chomp;
> >>    if (/^(\w+?):\s+(.*)/) {
> > 
> > 
> > I think that the '?' is unnecessary in this case because \w will not
> > match a colon. Therefore, a simple (\w+) will stop when it encounters
> > the first colon and need not be set to non-greedy. 
> 
> True.  I was doing this in my last 5 minutes at work, so I didn't have 
> time to fine-tune the answer.

No problem.

> 
> > You can also use
> > ([^:]+) to extract the key if it will include any non-\w characters.
> > 
> 
> Did you try that out?  When I substituted this line:
> 
>      if (/^([^:]+)\s+(.*)/) {

You left out the colon, and I would make whitespace after the colon
optional, suggesting the following (still untested):

      if ( /^([^:]+):\s*(.*)/ ) {


> 
> I got this output:
> 

[ non-matching output snipped]


----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= East/West-Coast Server Farms - Total Privacy via Encryption =---


------------------------------

Date: Thu, 3 Mar 2005 21:53:54 -0500
From: "L. D. James" <ljames@apollo3.com>
Subject: Re: How to specify [regex] beginning of line/unlimited characters/no spaces terminatingn with ":"
Message-Id: <112fjeeip3s933@corp.supernews.com>

"Tad McClellan" <tadmc@augustmail.com> wrote in message 
news:slrnd2f8tq.3p8.tadmc@magna.augustmail.com...
> L. D. James <ljames@apollo3.com> wrote:

>> $/ =
>> "*******************************************************************************\n";
>
>
> Yuk!
>
> You have to get finger prints on the screen to count how many
> asterisks there are supposed to be:
>
>   local $/ = '*' x 80 . "\n";

     Tad.  All your analysis and suggestions on my code was very clear and 
much appreciated.  Changing two lines made every thing work perfect.  Now 
I'm in the process of cleaning up so that my code will continue to work when 
using the "use strict; and use warnings;" specifications.  At "use strict" 
will give me countless compiling errors and abort.

     I'll also be ordering the O'Reilly, Mastering Regular Expressions, 
Second Edition, by Jeffery E. F. Fried, book recommended, ... being very 
specific with the title because there are a few books with the same name 
(minus Second Edition).  I want to be sure to get the right one.

     Thanks for all your input.  Another task resolved.

                           -- L. James

-- 
--------------------------------
L. D. James
ljames@apollo3.com
www.apollo3.com/~ljames 




------------------------------

Date: Fri, 04 Mar 2005 02:58:35 GMT
From: Jim Keenan <jkeen_via_google@yahoo.com>
Subject: Re: How to specify [regex] beginning of line/unlimited characters/no spaces terminatingn with ":"
Message-Id: <v9QVd.58999$W16.49875@trndny07>

Jim Gibson wrote:

> In article <XNNVd.85733$g16.9250@trndny08>, Jim Keenan
> <jkeen_via_google@yahoo.com> wrote:
> 
> 
>>Jim Gibson wrote:
>>
>>>
> 
> 
>>>You can also use
>>>([^:]+) to extract the key if it will include any non-\w characters.
>>>
>>
>>Did you try that out?  When I substituted this line:
>>
>>     if (/^([^:]+)\s+(.*)/) {
> 
> 
> You left out the colon, and I would make whitespace after the colon
> optional, suggesting the following (still untested):
> 
>       if ( /^([^:]+):\s*(.*)/ ) {
> 

Yes, that was it.


------------------------------

Date: Fri, 04 Mar 2005 03:08:20 GMT
From: Jim Keenan <jkeen_via_google@yahoo.com>
Subject: Re: Log::Agent in ActivePerl Windows?
Message-Id: <EiQVd.43550$f%5.36773@trndny03>

whph wrote:

> Hi,
> I'm trying to covert a perl program from unix to run on windows with
> active perl.
> The original code has modules like Log:Agent 

It apparently did not build cleanly when ActiveState tried it; that's 
why they don't have it.  Unfortunately, the printout from make test is 
non-verbose, so it's not possible from that alone to diagnose the 
problem.  There are, however, other PPM repositories around.  Google them.


and HTML::TreeBuilder

Part of HTML::Tree (http://search.cpan.org/~sburke/HTML-Tree-3.18/), 
which, according to http://ppm.activestate.com/BuildStatus/5.8-H.html, 
is distributed as core with ActivePerl8.  In any case, there's no .XS 
file, hence no need for C-compiler, so you should be able to install it 
yourself with 'nmake'.

jimk



------------------------------

Date: Fri, 04 Mar 2005 03:13:10 GMT
From: Jim Keenan <jkeen_via_google@yahoo.com>
Subject: Re: Log::Agent in ActivePerl Windows?
Message-Id: <anQVd.43561$f%5.39746@trndny03>

whph wrote:

> Hi,
> I'm trying to covert a perl program from unix to run on windows with
> active perl.
> The original code has modules like Log:Agent 

Further investigation shows that Log::Agent's latest version has 
repeatedly failed testing on Win32: 
http://testers.cpan.org/show/Log-Agent.html#Log-Agent-0.306

So you're not alone.

jimk


------------------------------

Date: Fri, 04 Mar 2005 09:10:31 GMT
From: "George" <georgekinley@hotmail.com>
Subject: Re: minor re, problelm
Message-Id: <xn0dzcnhudz1461003@news.europe.nokia.com>

Anno Siegel wrote:

> George <georgekinley@hotmail.com> wrote in comp.lang.perl.misc:
> > I have 
> > ($pI,$vI)=($input=~/(\d+),(\d+)/) || ($input=~/(.*),(.*)/);
> > print "($pI,$vI)";
> > which work fine if $input="24,qwerr" but returns (1,) if
> > $input="38,29" why is that
> > why this "or" is not working, and how can I use ?: in this case
> 
> Do you have strict and warnings on?  It doesn't look like it.  You
> should.
> 
> Precedence, context, and a peculiar behavior of "||" work together to
> bring about this result.  First off, "||" has higher precedence than
> "=", so the expression is evaluated as
> 
>     ($pI,$vI)= ( ($input=~/(\d+),(\d+)/) || ($input=~/(.*),(.*)/) );
> 
> Now, in perldoc perlop we find
> 
>        Binary "||" performs a short-circuit logical OR operation.
>        That is, if the left operand is true, the right operand is
>        not even evaluated.  Scalar or list context propagates
>        down to the right operand if it is evaluated.
> 
> The peculiarity is in the last sentence.
> 
> The left operand is evaluated in boolean context, so the first regex
> will return true or false, but not the list of captures.  If the first
> regex matches, that's it, so $pI is set to 1 and $vI remains
> undefined.  If it doesn't match, the second regex is evaluated in
> list context and returns the two captures.
> 
> To make it work right, rewrite it as
> 
>     ($pI, $vI) = ( $input =~ /(\d+),(\d+)/) or
>     ($pI, $vI) = ( $input =~ /(.*),(.*)/);
> 
> 
> Note the use of the low-precedence "or" instead of "||".
> 
> Anno

thank you for taking out time and explaning it 


------------------------------

Date: Fri, 04 Mar 2005 08:41:27 GMT
From: "Lord0" <lawrence.tierney@bipcontracts.com>
Subject: Re: mod_perl hosting
Message-Id: <XaVVd.1060$IQ5.578@newsfe1-gui.ntli.net>

www.gradwell.net 




------------------------------

Date: 4 Mar 2005 01:57:09 -0800
From: francescomoi@europe.com
Subject: Msql-Mysql-modules: unable to find my mySQL 'include' dir
Message-Id: <1109930228.998741.112750@g14g2000cwa.googlegroups.com>

Hi.

Working on mySQL v4.1.9 and Perl v5.8.5 on a Linux machine.

I want to install 'Msql-Mysql-modules'
http://search.cpan.org/~jwied/Msql-Mysql-modules-1.2219/
but when configuring it, I'm requested to specify the path where
mySQL 'lib' and 'include' are.

The only dir I've found on my server is this:
/usr/src/redhat/BUILD/mysql-4.1.9/
where one dir called 'lib' and another called 'libmysql'. However,
this last dir doesn't content the same structure as other mySQL
servers I've worked with (e.g. /usr/local/mysql/lib/mysql), and I'm
not able to install the Perl module, since I get this error message:

-------------------------------------------------------
Cannot find one of lib/mysql/libmysqlclient.a, lib/libmysqlclient.a,
lib/mysql/libmysqlclient.so, lib/libmysqlclient.so in
/usr/src/redhat/BUILD/mysql-4.1.9/ at lib/DBD/mysql/Install.pm line
165, <STDIN> line 4.
------------------------------------------------------

Any suggestion?



------------------------------

Date: 4 Mar 2005 00:02:38 -0800
From: eric.hall@gmail.com
Subject: negative backreference?
Message-Id: <1109923358.420981.126060@z14g2000cwz.googlegroups.com>

I'm a relative newbie with perl/regexp

I'm trying to write a rule for SpamAssassin that looks at the top-most
Received header and checks if the HELO identifer and the reverse DNS
hostname are the same, and apply a weight accordingly.

It's easy to see if they are the same, using an internal debug header
and a backreference. Assume HEADER is of the form "rdns=hostname
helo=hostname" then the simple rule of:

  HEADER =~ /rdns=(.*) helo=\1/

will match when they are the same. But I need to match when they are
different.

I've tried negative look-ahead of various forms, but nothing seems to
work correctly when backreferences are included. Is there a way out of
this hole?

Perl 5.8.1 on SuSE Linux Professional 9.0, if it matters.

Thanks



------------------------------

Date: 4 Mar 2005 08:17:33 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: negative backreference?
Message-Id: <d095it$739$1@mamenchi.zrz.TU-Berlin.DE>

 <eric.hall@gmail.com> wrote in comp.lang.perl.misc:
> I'm a relative newbie with perl/regexp
> 
> I'm trying to write a rule for SpamAssassin that looks at the top-most
> Received header and checks if the HELO identifer and the reverse DNS
> hostname are the same, and apply a weight accordingly.
> 
> It's easy to see if they are the same, using an internal debug header
> and a backreference. Assume HEADER is of the form "rdns=hostname
> helo=hostname" then the simple rule of:
> 
>   HEADER =~ /rdns=(.*) helo=\1/
> 
> will match when they are the same. But I need to match when they are
> different.
> 
> I've tried negative look-ahead of various forms, but nothing seems to
> work correctly when backreferences are included. Is there a way out of
> this hole?

What have you tried?  Negative lookahead should work just fine for this.

Anno


------------------------------

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 V10 Issue 7853
***************************************


home help back first fref pref prev next nref lref last post