[29351] in Perl-Users-Digest

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

Perl-Users Digest, Issue: 595 Volume: 11

daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Jun 28 14:14:21 2007

Date: Thu, 28 Jun 2007 11:14:11 -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           Thu, 28 Jun 2007     Volume: 11 Number: 595

Today's topics:
    Re: Oh great gurus of the list, I need help with a regu <tadmc@seesig.invalid>
    Re: Oh great gurus of the list, I need help with a regu anno4000@radom.zrz.tu-berlin.de
    Re: Oh great gurus of the list, I need help with a regu <savagebeaste@yahoo.com>
    Re: Oh great gurus of the list, I need help with a regu <mritty@gmail.com>
    Re: Oh great gurus of the list, I need help with a regu <art@xiotek.com>
        pattern match of possibly "dangerous" strings <alexxx.magni@gmail.com>
    Re: pattern match of possibly "dangerous" strings <noreply@gunnar.cc>
    Re: pattern match of possibly "dangerous" strings <alexxx.magni@gmail.com>
    Re: pattern match of possibly "dangerous" strings <mritty@gmail.com>
    Re: Perl Best Practices - Code Formatting. <baxter.brad@gmail.com>
    Re: Perl Best Practices - Code Formatting. <jwkenne@attglobal.net>
        Perl Standard for Remote Objects. <ilias@lazaridis.com>
    Re: Portable general timestamp format, not 2038-limited  sla29970@gmail.com
    Re: User Management and Authentication with Perl <ilias@lazaridis.com>
    Re: using wildcards with -e <mritty@gmail.com>
    Re: using wildcards with -e <mritty@gmail.com>
        Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)

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

Date: Thu, 28 Jun 2007 10:54:14 GMT
From: Tad McClellan <tadmc@seesig.invalid>
Subject: Re: Oh great gurus of the list, I need help with a regular expression please
Message-Id: <slrnf874h4.f9m.tadmc@tadmc30.sbcglobal.net>

Clenna Lumina <savagebeaste@yahoo.com> wrote:

> I think the usefulness it would 
> represent would of made it a shoe in?
            ^^^^^^^^
            ^^^^^^^^  heh. So it's a case of mistaken identity huh?


    http://en.wiktionary.org/wiki/shoo-in


-- 
Tad McClellan
email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"


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

Date: 28 Jun 2007 11:10:57 GMT
From: anno4000@radom.zrz.tu-berlin.de
Subject: Re: Oh great gurus of the list, I need help with a regular expression please
Message-Id: <5ehja1F38qqtmU1@mid.dfncis.de>

Tad McClellan  <tadmc@seesig.invalid> wrote in comp.lang.perl.misc:
> Clenna Lumina <savagebeaste@yahoo.com> wrote:
> 
> > I think the usefulness it would 
> > represent would of made it a shoe in?
>             ^^^^^^^^
>             ^^^^^^^^  heh. So it's a case of mistaken identity huh?
> 
> 
>     http://en.wiktionary.org/wiki/shoo-in

Ah, thanks.  That shoe had me puzzled.

Anno


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

Date: Thu, 28 Jun 2007 09:24:41 -0700
From: "Clenna Lumina" <savagebeaste@yahoo.com>
Subject: Re: Oh great gurus of the list, I need help with a regular expression please
Message-Id: <5ei5mgF37tak8U1@mid.individual.net>

Tad McClellan wrote:
> Clenna Lumina <savagebeaste@yahoo.com> wrote:
>
>> I think the usefulness it would
>> represent would of made it a shoe in?
>            ^^^^^^^^
>            ^^^^^^^^  heh. So it's a case of mistaken identity huh?

Oh, so now I'm the only one on the planet who doesn't know the correct 
spelling of "shoo-in", heh.. brilliant detective work once again... 
(note the sarcasm.)

>    http://en.wiktionary.org/wiki/shoo-in

And you're called me a troll in another thread? You're the one who KEEPS 
"flame-baiting" and quite frankly this IS a form of trolling. So who is 
the real troll here? The one being accused of it without merit, or the 
person acting like one?

All I see is you following my every step as I walk down the sidewalk to 
see if I stumble, ready to shout "ah ha!" at the slightest miss-step, 
and it make you look all the more foolish.

-- 
CL 




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

Date: Thu, 28 Jun 2007 09:52:32 -0700
From:  Paul Lalli <mritty@gmail.com>
Subject: Re: Oh great gurus of the list, I need help with a regular expression please
Message-Id: <1183049552.498795.234980@g4g2000hsf.googlegroups.com>

On Jun 27, 12:15 pm, "Clenna Lumina" <savagebea...@yahoo.com> wrote:
> Paul Lalli wrote:

> > $/ is a string.  You cannot put a regular expression into
> > it.  (Though see File::Stream for a way around that
> > restriction)
>
> Although being able to use $/ as a regex would be rather nifty,
> if you think about it.

As I said, see File::Stream, which allows you to do just that.

Paul Lalli





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

Date: Thu, 28 Jun 2007 09:56:48 -0700
From: "Art VanDelay" <art@xiotek.com>
Subject: Re: Oh great gurus of the list, I need help with a regular expression please
Message-Id: <QLRgi.7945$bP5.3259@newssvr19.news.prodigy.net>

Tad McClellan wrote:

> Clenna Lumina <savagebeaste@yahoo.com> wrote:

> > I think the usefulness it would
> > represent would of made it a shoe in?

>            ^^^^^^^^
>            ^^^^^^^^  heh. So it's a case of mistaken identity huh?


I agree, "would have" would have been more grammatically correct, but 
last time I checked, no one's perfect. Oh wait, except you, Mr. 
Infallible? Right?

In the end, you're just trolling and from the looks of it, trying to 
start crap-filled off-shoot like the one you started a few threads down.


>    http://en.wiktionary.org/wiki/shoo-in


So what?


http://www.google.com/search?as_q=%22shoe+in%22&hl=en&num=100
http://groups.google.com/groups?as_q=%22shoe+in%22&hl=en&num=100

1,010,000 occurrences, 54,100 in news groups alone. Hardly a mistake of 
a single individual.

Half the world knows "shoe in" incorrectly, assuming it is incorrect. 
Google doesn't even attempt to offer a correction.

http://www.google.com/search?as_q=%22shoo+in%22&hl=en&num=100
http://groups.google.com/groups?as_q=%22shoo+in%22&hl=en&num=100

354,000 from the web-side, 15,500 from news groups. What does this say? 
That either
 - a) "shoe in" is correct, or
 - b) "shoe in" is far more common despite being incorrect.

Either way, it should not be surprising to see a mistake like that. 
Making huge deals about it make you appear small and insecure, like a 
school yard bully who has nothing better to do.



So I ask again: So what?



-- 
Art

P.S. I know I don't post here regularly, and there are some here who 
might say I have no right to comment (I do read this group regularly), 
but there are times when something is so ridiculously stupid, I feel 
something just has to be said. 




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

Date: Thu, 28 Jun 2007 15:00:22 -0000
From:  "alexxx.magni@gmail.com" <alexxx.magni@gmail.com>
Subject: pattern match of possibly "dangerous" strings
Message-Id: <1183042822.208502.39080@q69g2000hsb.googlegroups.com>

Hi all,
I have a small program that crawls my filesystem, checking filenames
and doing useful stuff.
The heart of it, of course is a pattern match line, where the filename
under check is compared to a pattern.
Everything was running perfectly until I got:

/0ale/excursions/digital/manuals/O'Reilly Perl CD Bookshelf v2.0/
advprog/examples/Extending/Typemaps_with_XS/00comment.txt exists,
updating it

Nested quantifiers in regex; marked by <-- HERE in m/^\s+Car_c++ <--
HERE _obj ! (\S.*)/ at /0ale/excursions/digital/script/comment-dev
line 271.


(1st line is my prog. output, 2nd line is the error)
apart from the fun fact that the error came while crawling the Perl
Bookshelf, I immediately noticed that names containing special chars
(as that damn directory Car_c++_obj) can bring trouble.
How can I be sure that a generic string read in $_ can be safely put
in a RE, without its chars being misunderstood as RE special chars???

Thanks!

Alessandro Magni



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

Date: Thu, 28 Jun 2007 17:06:52 +0200
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: pattern match of possibly "dangerous" strings
Message-Id: <5ei1a0F38h3ajU1@mid.individual.net>

alexxx.magni@gmail.com wrote:
> I have a small program that crawls my filesystem, checking filenames
> and doing useful stuff.
> The heart of it, of course is a pattern match line, where the filename
> under check is compared to a pattern.
> Everything was running perfectly until I got:
> 
> /0ale/excursions/digital/manuals/O'Reilly Perl CD Bookshelf v2.0/
> advprog/examples/Extending/Typemaps_with_XS/00comment.txt exists,
> updating it
> 
> Nested quantifiers in regex; marked by <-- HERE in m/^\s+Car_c++ <--
> HERE _obj ! (\S.*)/ at /0ale/excursions/digital/script/comment-dev
> line 271.
> 
> 
> (1st line is my prog. output, 2nd line is the error)
> apart from the fun fact that the error came while crawling the Perl
> Bookshelf, I immediately noticed that names containing special chars
> (as that damn directory Car_c++_obj) can bring trouble.
> How can I be sure that a generic string read in $_ can be safely put
> in a RE, without its chars being misunderstood as RE special chars???

     perldoc -f quotemeta

-- 
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl


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

Date: Thu, 28 Jun 2007 15:37:34 -0000
From:  "alexxx.magni@gmail.com" <alexxx.magni@gmail.com>
Subject: Re: pattern match of possibly "dangerous" strings
Message-Id: <1183045054.842873.274700@o61g2000hsh.googlegroups.com>

thank you,
I didnt know about this particular kind of quote - it sertainly works
now with a simple $q=quotemeta($_);

Alessandro

On Jun 28, 5:06 pm, Gunnar Hjalmarsson <nore...@gunnar.cc> wrote:
> alexxx.ma...@gmail.com wrote:
> > I have a small program that crawls my filesystem, checking filenames
> > and doing useful stuff.
> > The heart of it, of course is a pattern match line, where the filename
> > under check is compared to a pattern.
> > Everything was running perfectly until I got:
>
> > /0ale/excursions/digital/manuals/O'Reilly Perl CD Bookshelf v2.0/
> > advprog/examples/Extending/Typemaps_with_XS/00comment.txt exists,
> > updating it
>
> > Nested quantifiers in regex; marked by <-- HERE in m/^\s+Car_c++ <--
> > HERE _obj ! (\S.*)/ at /0ale/excursions/digital/script/comment-dev
> > line 271.
>
> > (1st line is my prog. output, 2nd line is the error)
> > apart from the fun fact that the error came while crawling the Perl
> > Bookshelf, I immediately noticed that names containing special chars
> > (as that damn directory Car_c++_obj) can bring trouble.
> > How can I be sure that a generic string read in $_ can be safely put
> > in a RE, without its chars being misunderstood as RE special chars???
>
>      perldoc -f quotemeta
>
> --
> Gunnar Hjalmarsson
> Email:http://www.gunnar.cc/cgi-bin/contact.pl




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

Date: Thu, 28 Jun 2007 10:00:47 -0700
From:  Paul Lalli <mritty@gmail.com>
Subject: Re: pattern match of possibly "dangerous" strings
Message-Id: <1183050047.371248.154880@o61g2000hsh.googlegroups.com>

On Jun 28, 11:37 am, "alexxx.ma...@gmail.com" <alexxx.ma...@gmail.com>
wrote:
> On Jun 28, 5:06 pm, Gunnar Hjalmarsson <nore...@gunnar.cc> wrote:
> >      perldoc -f quotemeta

> I didnt know about this particular kind of quote - it
> sertainly works now with a simple $q=quotemeta($_);

Read the doc Gunnar pointed you to again.  It's simpler than that.
Just use the \Q (and possibly \E) characters within your regexp.

perldoc perlre

Paul Lalli



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

Date: Thu, 28 Jun 2007 13:03:43 -0000
From:  Brad Baxter <baxter.brad@gmail.com>
Subject: Re: Perl Best Practices - Code Formatting.
Message-Id: <1183035823.809215.93170@q69g2000hsb.googlegroups.com>

On Jun 27, 9:47 pm, Brad Baxter <baxter.b...@gmail.com> wrote:
> I'm a bit relieved.  I had been coding with tabs for all of those
> reason for a number of years.  I stopped when a) no one else in our
> group did, and b) I found that CPAN in general frowned on the
> practice.  :-(
>
> In truth, I'm agnostic.  I thought I was doing a Good Thing, but
> spaces are fine with me.

Pardon the autopost.  That came out sounding like an indictment of my
colleagues that is neither true not intended.  Instead: a) too often
others in our group would use spaces ... and when there's a mix, the
advantages of tabs become disadvantages.  At least I didn't refer to
them as "cow-orkers" (my favorite typo of the week).  Ouch.

In fact, if I decide to be a programmer my next life, I would come
here to work.  Well, here or St. Martin.

--
Brad



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

Date: Thu, 28 Jun 2007 11:22:11 -0400
From: "John W. Kennedy" <jwkenne@attglobal.net>
Subject: Re: Perl Best Practices - Code Formatting.
Message-Id: <DmQgi.5$Zk6.2@newsfe12.lga>

Charlton Wilbur wrote:
>>>>>> "M" == Michele Dondi <bik.mido@tiscalinet.it> writes:
> 
>     M> A simple cellular sample would suffice. And now that you make
>     M> me think of it wine is supposed to *become* (as opposed to
>     M> *symbolize* - at least for the Catholic Church, hey I'm Italian
>     M> and I know these things) his blood during the consacration. So
>     M> the question should be easy to settle down. I wonder why nobody
>     M> has thought of this before...
> 
> The bread and wine become *in essence* His body and blood, but they
> remain *in accident* bread and wine -- in other words, it still looks
> like bread and wine, and to all tests appears still to be bread and
> wine, but it *really*, on a spiritual level, is Christ's body and
> blood. I suspect that even according to the doctrine of
> transubstantiation such things as DNA are accidents rather than
> essence; it wasn't devised by 21st century scientists, after all.

In (nearly) everyday terms, the doctrine of transubstantiation says (and 
has always said, since Aquinas first stated it in the 13th century) that 
the metaphysical breadness of the bread and the metaphysical wineness of 
the wine are miraculously changed into metaphysical body-of-Christness 
and blood-of-Christness, and nothing else is changed.

> (As for myself, I'm Episcopalian, where the doctrine is, more or less,
> "Transubstantiation?  Consubstantiation?  Heck, we don't know, we just
> do it because He said so, and we think that getting together to
> worship is a good thing.")

The doctrine as of this month appears to be, "Hey, he was a great 
prophet, almost as great as Mohamed." (Google "Redding" and "Seattle".)
-- 
John W. Kennedy
"The whole modern world has divided itself into Conservatives and 
Progressives. The business of Progressives is to go on making mistakes. 
The business of the Conservatives is to prevent the mistakes from being 
corrected."
   -- G. K. Chesterton


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

Date: Thu, 28 Jun 2007 12:14:48 -0000
From:  Ilias Lazaridis <ilias@lazaridis.com>
Subject: Perl Standard for Remote Objects.
Message-Id: <1183032888.468572.289610@q75g2000hsh.googlegroups.com>

Is there any standard library to deal with remote objects on perl?

ideally whilst using a standard security library.

 .

--
http://dev.lazaridis.com/lang/ticket/19



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

Date: Thu, 28 Jun 2007 14:32:29 -0000
From:  sla29970@gmail.com
Subject: Re: Portable general timestamp format, not 2038-limited
Message-Id: <1183041149.275562.114490@o11g2000prd.googlegroups.com>

On Jun 27, 10:51 pm, Paul Rubin <http://phr...@NOSPAM.invalid> wrote:
> According to <http://en.wikipedia.org/wiki/UTC>, UTC is derived from
> TAI.

According to <http://en.wikipedia.org/wiki/TAI>, TAI is a proper time,
but the very first section in the TAI discussion page cites a refereed
paper by the person then in charge of TAI which asserts that is not
true.

As for the primacy of UTC vs. TAI, this is the classical chicken and
egg problem.  The bureaucratic reality is opposed to the physical
reality.

> it's always within 20 nsec.  This seems like the kind of correction
> that can be applied after the fact.

It is the nature of horology that *all* clocks need corrections
applied after the fact.  The question is whether a given clock and its
time distribution system is good enough for the given application.

> The difficulty/impossibility of computing intervals on UTC because of leap seconds suggests TAI is a superior timestamp format.

TAI is a superior time scale for processes on the surface of the earth
which only care about nanosecond precision, but it is not practically
available nor legal nor applicable off the surface of the earth.  TAI
is itself corrected after the fact by the issue of TT(BIPMxx).




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

Date: Thu, 28 Jun 2007 11:16:22 -0000
From:  Ilias Lazaridis <ilias@lazaridis.com>
Subject: Re: User Management and Authentication with Perl
Message-Id: <1183029382.821374.187150@m36g2000hse.googlegroups.com>

On Jun 26, 11:14 am, Tim Southerwood <t...@dionic.net> wrote:
> Ilias Lazaridis coughed up some electrons that declared:
>
>
>
> >  * reuse the existent apache httppw files
> >  * move over to the linux user management
> >  * move over to an LDAP system
> >  * move over to a decentral system (e.g. openID)
>
> OK - I think PAM is what you want at the client end as you can reconfigure
> the client PAM config at each stage to use different auth/account services.
>
> I guess that for each stage, you'll need to write your own perl to manage
> the backend.

ok, you mean those which are not available yet.

> I would consider getting the core data into a database of some sort
> (Postgresql works well for this IME) and drive that data into the backend
> via perl.

I forgot to mention, that this should work fine with

 * Standard RMI (Remote Method Invocation) of perl



 .

--
http://dev.lazaridis.com/lang/ticket/18



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

Date: Thu, 28 Jun 2007 10:12:29 -0700
From:  Paul Lalli <mritty@gmail.com>
Subject: Re: using wildcards with -e
Message-Id: <1183050749.589447.8970@k79g2000hse.googlegroups.com>

On Jun 27, 6:18 pm, "John W. Krahn" <d...@example.com> wrote:
> Peter Makholm wrote:
> > DMB <dumm...@hotmail.com> writes:
>

> >> if (-e $done_dir."*.DOC") {
> >>        print "found it\n";
> >> } else {
> >>        print "nope\n";
> >> }
>
> > You might want to look at the glob function which expands these
> > kinds of wildcards into a list of files. So something like
>
> > if (grep { -e $_ } glob("$donedir/*.DOC") ) {
> >     print "Found it";
> > }
>
> You shouldn't need the grep, this should work:
>
> if ( glob "$donedir/*.DOC" ) {
>      print "Found it";
> }

Danger, danger Will Robinson!!  That bit of code will work only if
both of the following are true:
1) The string actually does contain shell meta characters.
2) The block is not being used in a loop.

If you later change your "pattern" to actualy be a single file, your
code will break.  This is especially a problem if you're reading the
pattern from the user.  Observe:

~/temp $ ls
~/temp $ perl -le'print for glob("foo.*")'
~/temp $ perl -le'print for glob("foo.bar")'
foo.bar
~/temp $

If the code is being called in a loop of some kind, and there are, say
N files that match the pattern, your if statement will fail every (N
+1)th time.  Observe:

~/temp $ touch foo.1 foo.2 foo.3
~/temp $ perl -le'
for (1..10) {
  if (glob("foo.*")) {
    print "yes"
  } else {
    print "no"
  }
}
'
yes
yes
yes
no
yes
yes
yes
no
yes
yes


All things considered, it's better to stick with the grep, and thereby
call glob() in a scalar context, explicitly testing the existance of
each return value.

Paul Lalli



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

Date: Thu, 28 Jun 2007 10:13:27 -0700
From:  Paul Lalli <mritty@gmail.com>
Subject: Re: using wildcards with -e
Message-Id: <1183050807.877637.276590@g4g2000hsf.googlegroups.com>

On Jun 28, 1:12 pm, Paul Lalli <mri...@gmail.com> wrote:

> All things considered, it's better to stick with the grep, and
> thereby call glob() in a scalar context, explicitly testing the
> existance of each return value.

s/scalar/list/;

Paul Lalli



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

Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin) 
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>


Administrivia:

#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc.  For subscription or unsubscription requests, send
#the single line:
#
#	subscribe perl-users
#or:
#	unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.  

NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice. 

To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.

#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.

#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.


------------------------------
End of Perl-Users Digest V11 Issue 595
**************************************


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