[28852] in Perl-Users-Digest
Perl-Users Digest, Issue: 96 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Feb 2 03:06:23 2007
Date: Fri, 2 Feb 2007 00:05:07 -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, 2 Feb 2007 Volume: 11 Number: 96
Today's topics:
Re: HTML:Parser how to remove "//<![CDATA[ ... //]]>" ? sl123@netherlands.area
Re: HTML:Parser how to remove "//<![CDATA[ ... //]]>" ? <uri@stemsystems.com>
Re: HTML:Parser how to remove "//<![CDATA[ ... //]]>" ? sl123@netherlands.area
Re: HTML:Parser how to remove "//<![CDATA[ ... //]]>" ? <spamtrap@dot-app.org>
Re: HTML:Parser how to remove "//<![CDATA[ ... //]]>" ? <uri@stemsystems.com>
new CPAN modules on Fri Feb 2 2007 (Randal Schwartz)
Re: perl one liner to remove all but the base file name <ayaz@dev.slash.null>
please explain to me robertchen117@gmail.com
Re: please explain to me <check.sig@for.email.invalid>
Re: Read on closed filehandle <hjp-usenet2@hjp.at>
Stick Lines and Dividers Between Text vjp2@panix.com
Re: Storing results in array rather than printing (NOSPAM)
Re: Upload file fails <cwilbur@chromatico.net>
Re: Upload file fails <purlgurl@purlgurl.net>
Re: Upload file fails <cwilbur@chromatico.net>
Re: Win32::Clipboard mutilates \n <sisyphus1@nomail.afraid.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 01 Feb 2007 07:08:20 -0800
From: sl123@netherlands.area
Subject: Re: HTML:Parser how to remove "//<![CDATA[ ... //]]>" ?
Message-Id: <mhu3s2tf4jhjadd6v8hbdtkp5g1eru9r6m@4ax.com>
On Thu, 1 Feb 2007 09:45:42 +0100, "Dr.Ruud" <rvtol+news@isolution.nl> wrote:
>anno4000@radom.zrz.tu-berlin.de schreef:
>> Gerwin:
>>> Gerwin:
>
>>>> I'm using HTML::Parser to strip HTML tags from my files. I noticed
>>>> how //<![cdata[ ... //]]> and the javascript between that is not
>>>> stripped. Any idea how to do this?
>>>
>>> Well i made a regex to do it:
>>> $content =~ s/(\/\/<!\[.*\/\/]]>)//;
>
>A different separator makes it more legible:
>
> $content =~ s~(//<!\[.*//]]>)~~;
>
>
>>> Is this efficient? If not, what is?
>>
>> Why do you think efficiency matters?
>
>Maybe HTML::Parser already offers a better way.
>
>Or maybe one doesn't always want to remove it, there can be plain text
>inside. Or, but that is more about effectiveness, maybe some CDATA
>sections are spread over more than one line.
Thats why none of this you encorage will work.
If you are stream processing and as you say spread over more than 1 line,
use ROBIC0's approach, buffer untill you have complete comment or cdata:
$RxParseXP1 = qr/(?:<(?:\[CDATA\[(.*?)\]\])|(?:--(.*?[^-])--)>)/s;
# ( <( 0 0 )|( 1 1 ) )
while (!$done)
{
$ln_cnt++;
# stream processing (if not buffered)
if (!$BUFFERED) {
if (!($_ = <$markup_file>)) {
# just parse what we have
$done = 1;
# boundry check for runnaway
if (($complete_comment+$complete_cdata) > 0) {
$ln_cnt--;
}
} else {
$$ref_parse_ln .= $_;
## buffer if needing comment/cdata closure
next if ($complete_comment && !/-->/);
next if ($complete_cdata && !/\]\]>/);
## reset comment/cdata flags
$complete_comment = 0;
$complete_cdata = 0;
## flag serialized comments/cdata buffering
if (/(<!--)|(<!\[CDATA\[)/)
{
if (defined $1) { # complete comment
if ($$ref_parse_ln !~ /<!--.*?-->/s) {
$complete_comment = 1;
next;
}
}
elsif (defined $2) { # complete cdata
if ($$ref_parse_ln !~ /<!\[CDATA\[.*?\]\]>/s) {
$complete_cdata = 1;
next;
}
}
}
## buffer until '>' or eof
next if (!/>/);
}
} else {
$ln_cnt = 1;
$done = 1;
}
When you have it buffered from above (or already buffered), parse it:
## REGEX Parsing loop
while ($$ref_parse_ln =~ /$RxParseXP1/g)
{
## CDATA
if (defined $0) {
}
## COMMENT
elsif (defined $1) {
}
}
}
Either way, whatever comes first, comment or CDATA, that takes precedence till its closure.
------------------------------
Date: Fri, 02 Feb 2007 00:10:46 -0500
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: HTML:Parser how to remove "//<![CDATA[ ... //]]>" ?
Message-Id: <x7ps8tkuuh.fsf@mail.sysarch.com>
>>>>> "s" == sl123 <sl123@netherlands.area> writes:
s> If you are stream processing and as you say spread over more than 1 line,
s> use ROBIC0's approach, buffer untill you have complete comment or cdata:
ok, the first time you backed his code i asked you if it was a
joke. obviously you think it is real code. so i will shred this crap and
hopefully you will see why it is bad code.
s> $RxParseXP1 = qr/(?:<(?:\[CDATA\[(.*?)\]\])|(?:--(.*?[^-])--)>)/s;
s> # ( <( 0 0 )|( 1 1 ) )
why no /x modifier? long and complex regexes always should use /x.
and what if that was inside a comment? or some area that isn't parsed
for html?
s> while (!$done)
loop flags like that are very silly and kiddie code.
s> {
s> $ln_cnt++;
s> # stream processing (if not buffered)
s> if (!$BUFFERED) {
upper case variable names are for constants and such. notice he likes !
all over the place. better to use unless and until.
s> if (!($_ = <$markup_file>)) {
that is just bad. use a named lexical instead of $_. what if the last
line of the file was just '0' with no newline? that fails.
s> # just parse what we have
s> $done = 1;
just bad. really bad to use flags like that. you don't even know what
more code might execute here because the ridiculously long if/else blocks.
s> # boundry check for runnaway
s> if (($complete_comment+$complete_cdata) > 0) {
huh??? is he testing 2 flags for either one being set? has the idiot
ever heard of a boolean or??
s> $ln_cnt--;
we lose lines too??
s> }
s> } else {
s> $$ref_parse_ln .= $_;
s> ## buffer if needing comment/cdata closure
s> next if ($complete_comment && !/-->/);
s> next if ($complete_cdata && !/\]\]>/);
but what about the done flag?? don't mix loop flags with flow control
ops. just dumb. pick one style.
s> ## reset comment/cdata flags
s> $complete_comment = 0;
s> $complete_cdata = 0;
s> ## flag serialized comments/cdata buffering
s> if (/(<!--)|(<!\[CDATA\[)/)
more complex regexes that need /x
s> {
s> if (defined $1) { # complete comment
s> if ($$ref_parse_ln !~ /<!--.*?-->/s) {
s> $complete_comment = 1;
s> next;
the nesting here is getting very deep. a sign of someone who loves
if/else too much. a cleaner design would be simpler, easier to read and
understand.
s> }
s> }
s> elsif (defined $2) { # complete cdata
why check those two separately but match in one regex? just test one
pattern and handle it or test the other. this is bullshit code. way
longer and more complex than it needs to be.
s> if ($$ref_parse_ln !~
s> /<!\[CDATA\[.*?\]\]>/s)
s> {
he uses ! all over and here he switches to !~ which is rarely used.
s> $complete_cdata = 1;
s> next;
s> }
s> }
s> }
s> ## buffer until '>' or eof
s> next if (!/>/);
s> }
can you even tell what this is the else for? it scrolled off my screen.
s> } else {
s> $ln_cnt = 1;
s> $done = 1;
now we're done? do we exit the loop here? who knows? i have to scroll up
and find the if and see it that falls through or what??
s> }
s> When you have it buffered from above (or already buffered), parse it:
s> ## REGEX Parsing loop
s> while ($$ref_parse_ln =~ /$RxParseXP1/g)
s> {
s> ## CDATA
s> if (defined $0) {
oh that is wonderful. a true bug by the way. $0 is the name of the
program and not a grabbed match. not that he does any work in this if
s> }
s> ## COMMENT
s> elsif (defined $1) {
again, an empty else clause. wo what was the purpose of this if/else?
showing off more bad code is my guess.
s> }
s> }
s> }
s> Either way, whatever comes first, comment or CDATA, that takes
s> precedence till its closure.
either way it is horrible code by someone who doesn't know perl or
coding and has proven himself to be very psychotic. you trust this and
you will trust anything. so please stop defending this crap. i didn't
even analyze the actual logic as it is not clear from the poor design.
my guess is that you are his syncophantic alter ego.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
------------------------------
Date: Thu, 01 Feb 2007 11:29:53 -0800
From: sl123@netherlands.area
Subject: Re: HTML:Parser how to remove "//<![CDATA[ ... //]]>" ?
Message-Id: <fac4s2pa98l8jrbkvtiaj7re0cgo78ct7b@4ax.com>
On Fri, 02 Feb 2007 00:10:46 -0500, Uri Guttman <uri@stemsystems.com> wrote:
>>>>>> "s" == sl123 <sl123@netherlands.area> writes:
>
>
> s> If you are stream processing and as you say spread over more than 1 line,
> s> use ROBIC0's approach, buffer untill you have complete comment or cdata:
>
>ok, the first time you backed his code i asked you if it was a
>joke. obviously you think it is real code. so i will shred this crap and
>hopefully you will see why it is bad code.
>
> s> $RxParseXP1 = qr/(?:<(?:\[CDATA\[(.*?)\]\])|(?:--(.*?[^-])--)>)/s;
> s> # ( <( 0 0 )|( 1 1 ) )
>
>why no /x modifier? long and complex regexes always should use /x.
Not sure its relavent here
>
>and what if that was inside a comment? or some area that isn't parsed
>for html?
What if what (?) was inside a comment or some area that wasn't parsed for html?
>
> s> while (!$done)
>
>loop flags like that are very silly and kiddie code.
perhaps a goto is something more to your liking?
>
> s> {
> s> $ln_cnt++;
>
> s> # stream processing (if not buffered)
> s> if (!$BUFFERED) {
>
>upper case variable names are for constants and such. notice he likes !
>all over the place. better to use unless and until.
From looking at code BUFFERED is a very important
>
> s> if (!($_ = <$markup_file>)) {
>
>that is just bad. use a named lexical instead of $_. what if the last
>line of the file was just '0' with no newline? that fails.
I don't think this is true
>
> s> # just parse what we have
> s> $done = 1;
>
>just bad. really bad to use flags like that. you don't even know what
>more code might execute here because the ridiculously long if/else blocks.
huh?
>
> s> # boundry check for runnaway
> s> if (($complete_comment+$complete_cdata) > 0) {
>
>huh??? is he testing 2 flags for either one being set? has the idiot
>ever heard of a boolean or??
Checking this, the addition and comparison here is half the assembly instruction
cycles than to do a double comarison with two jmp's. Could be a performance thing
>
> s> $ln_cnt--;
>we lose lines too??
what is this variable? have you checked?
>
> s> }
> s> } else {
> s> $$ref_parse_ln .= $_;
>
> s> ## buffer if needing comment/cdata closure
> s> next if ($complete_comment && !/-->/);
> s> next if ($complete_cdata && !/\]\]>/);
>
>but what about the done flag?? don't mix loop flags with flow control
>ops. just dumb. pick one style.
It looks like he uses the fall-through method, avoiding the extra machine cycles.
I think the $done flag is set elsewhere as well
>
> s> ## reset comment/cdata flags
> s> $complete_comment = 0;
> s> $complete_cdata = 0;
>
> s> ## flag serialized comments/cdata buffering
> s> if (/(<!--)|(<!\[CDATA\[)/)
>
>more complex regexes that need /x
not sure its relavent for this, could be right, though with no effect
>
> s> {
> s> if (defined $1) { # complete comment
> s> if ($$ref_parse_ln !~ /<!--.*?-->/s) {
> s> $complete_comment = 1;
> s> next;
>
>the nesting here is getting very deep. a sign of someone who loves
>if/else too much. a cleaner design would be simpler, easier to read and
>understand.
The if/then/else construct can't be avoided. The machining can be trimmed.
He did a good job thinning with single if's comparisons to make a path back.
I don't see any faster constructs than what he's got
>
> s> }
> s> }
> s> elsif (defined $2) { # complete cdata
>
>why check those two separately but match in one regex? just test one
>pattern and handle it or test the other. this is bullshit code. way
>longer and more complex than it needs to be.
Yea its either one or the other. Did he expect more?
>
> s> if ($$ref_parse_ln !~
> s> /<!\[CDATA\[.*?\]\]>/s)
> s> {
>
>he uses ! all over and here he switches to !~ which is rarely used.
Looks like he positively wanted to know if that was case. Looks alright
>
> s> $complete_cdata = 1;
> s> next;
> s> }
> s> }
> s> }
> s> ## buffer until '>' or eof
> s> next if (!/>/);
> s> }
>
>can you even tell what this is the else for? it scrolled off my screen.
what "else" are you looking at. Apparently, />/ is like a period at the end of
a sentence. Otherwise better to not do anything at the termination of this block
or will be trouble, you are in the middle of a sentence
>
> s> } else {
> s> $ln_cnt = 1;
> s> $done = 1;
>
>now we're done? do we exit the loop here? who knows? i have to scroll up
>and find the if and see it that falls through or what??
To me it looks like if its streamed (not BUFFERED) he is waiting for a complete
sentence with the />/ to pass through to the formal parser below this. If it
is BUFFERED, means the complete file is passed to the formal parser. Streaming,
it looks like he waits for a complete sentence, parses, goes back up top, gets
another, etc...
>
> s> }
>
> s> When you have it buffered from above (or already buffered), parse it:
>
> s> ## REGEX Parsing loop
> s> while ($$ref_parse_ln =~ /$RxParseXP1/g)
> s> {
> s> ## CDATA
> s> if (defined $0) {
>
>oh that is wonderful. a true bug by the way. $0 is the name of the
>program and not a grabbed match. not that he does any work in this if
My mistake, I transposed his variabes, should have been $1, $2
>
> s> }
> s> ## COMMENT
> s> elsif (defined $1) {
>
>again, an empty else clause. wo what was the purpose of this if/else?
>showing off more bad code is my guess.
I just meant to condense his code for an example. The unfilled block
is left as an exercise
>
> s> }
> s> }
>
> s> }
>
> s> Either way, whatever comes first, comment or CDATA, that takes
> s> precedence till its closure.
>
>either way it is horrible code by someone who doesn't know perl or
>coding and has proven himself to be very psychotic. you trust this and
>you will trust anything. so please stop defending this crap. i didn't
>even analyze the actual logic as it is not clear from the poor design.
>
>my guess is that you are his syncophantic alter ego.
>
>uri
He's probably psycotic or genious, I don't know of him. The code looks good though.
Its possible that the "order" of the parse regex is important. I think it is.
Here:
@UC_Nstart = (
"\\x{C0}-\\x{D6}",
"\\x{D8}-\\x{F6}",
"\\x{F8}-\\x{2FF}",
"\\x{370}-\\x{37D}",
"\\x{37F}-\\x{1FFF}",
"\\x{200C}-\\x{200D}",
"\\x{2070}-\\x{218F}",
"\\x{2C00}-\\x{2FEF}",
"\\x{3001}-\\x{D7FF}",
"\\x{F900}-\\x{FDCF}",
"\\x{FDF0}-\\x{FFFD}",
"\\x{10000}-\\x{EFFFF}",
);
@UC_Nchar = (
"\\x{B7}",
"\\x{0300}-\\x{036F}",
"\\x{203F}-\\x{2040}",
);
$Nstrt = "[A-Za-z_:".join ('',@UC_Nstart)."]";
$Nchar = "[-\\w:\\.".join ('',@UC_Nchar).join ('',@UC_Nstart)."]";
$Name = "(?:$Nstrt$Nchar*?)";
#die "$Name\n";
$RxParseXP1 =
qr/(?:<(?:(?:(\/*)($Name)\s*(\/*))|(?:META(.*?))|(?:($Name)((?:\s+$Name\s*=\s*["'][^<]*['"])+)\s*(\/*))|(?:\?(.*?)\?)|(?:!(?:(?:DOCTYPE(.*?))|(?:\[CDATA\[(.*?)\]\])|(?:--(.*?[^-])--)|(?:ATTLIST(.*?))|(?:ENTITY(.*?)))))>)|(.+?)/s;
# ( <( ( 1 12 2 3 3)|( 4 4)|( 5 56( ) 6 7 7)|( 8 8 )|( !( ( 9 9)|( 0 0 )|( 1 1 )|(
2 2)|( 3 3))))>)|4 4
------------------------------
Date: Fri, 02 Feb 2007 03:01:19 -0500
From: Sherm Pendley <spamtrap@dot-app.org>
Subject: Re: HTML:Parser how to remove "//<![CDATA[ ... //]]>" ?
Message-Id: <m2lkjhc7jk.fsf@Sherm-Pendleys-Computer.local>
sl123@netherlands.area writes:
> He's probably psycotic or genious, I don't know of him.
If you don't know of Robic0, then you should listen to Uri, who *does* know
of him, or just search for Robic0's posts in Google Groups. He's psychotic,
as stupid as it gets, and unjustified arrogance personified. Sorry to burst
your bubble, but Robic0 is about as poor a role model as you'll find in this
or any other group.
> The code looks good though.
If Robic0's code looks good to you, then you need to learn more Perl. Heck,
you need to learn more about programming in *any* language. I don't mean that
as a flame, just a simple statement of fact; the fact that you don't under-
stand the many flaws in his code says more about your own lack of experience
than it does about his code.
sherm--
--
Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net
------------------------------
Date: Fri, 02 Feb 2007 03:03:40 -0500
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: HTML:Parser how to remove "//<![CDATA[ ... //]]>" ?
Message-Id: <x7abzxkmub.fsf@mail.sysarch.com>
>>>>> "s" == sl123 <sl123@netherlands.area> writes:
s> On Fri, 02 Feb 2007 00:10:46 -0500, Uri Guttman <uri@stemsystems.com> wrote:
>>>>>>> "s" == sl123 <sl123@netherlands.area> writes:
>>
>>
s> If you are stream processing and as you say spread over more than 1 line,
s> use ROBIC0's approach, buffer untill you have complete comment or cdata:
>>
>> ok, the first time you backed his code i asked you if it was a
>> joke. obviously you think it is real code. so i will shred this crap and
>> hopefully you will see why it is bad code.
>>
s> $RxParseXP1 = qr/(?:<(?:\[CDATA\[(.*?)\]\])|(?:--(.*?[^-])--)>)/s;
s> # ( <( 0 0 )|( 1 1 ) )
>>
>> why no /x modifier? long and complex regexes always should use /x.
s> Not sure its relavent here
then you don't know what /x is for.
>>
s> while (!$done)
>>
>> loop flags like that are very silly and kiddie code.
s> perhaps a goto is something more to your liking?
no. better code is to my liking. i can't recall needing a loop flag in
perl. that is more like basic. with all the long/deep nested if/elses
you can't track the logic at all.
s> # stream processing (if not buffered)
s> if (!$BUFFERED) {
>>
>> upper case variable names are for constants and such. notice he likes !
>> all over the place. better to use unless and until.
s> From looking at code BUFFERED is a very important
important? one boolean test does not make something important.
>>
s> if (!($_ = <$markup_file>)) {
>>
>> that is just bad. use a named lexical instead of $_. what if the last
>> line of the file was just '0' with no newline? that fails.
s> I don't think this is true
then you don't know perl. sorry.
>>
s> # just parse what we have
s> $done = 1;
>>
>> just bad. really bad to use flags like that. you don't even know what
>> more code might execute here because the ridiculously long if/else blocks.
s> huh?
forget it. if you think loop flags are good (especially when done like
this) then please don't code in perl.
>>
s> # boundry check for runnaway
s> if (($complete_comment+$complete_cdata) > 0) {
>>
>> huh??? is he testing 2 flags for either one being set? has the idiot
>> ever heard of a boolean or??
s> Checking this, the addition and comparison here is half the
s> assembly instruction cycles than to do a double comarison with two
s> jmp's. Could be a performance thing
assembly? what does that have to do with perl? perl is compiled to an
internal form which is interpreted. actually that code is slower in perl
than a boolean test for several reasons. but you won't understand them
so i won't cover it.
>>
s> $ln_cnt--;
>> we lose lines too??
s> what is this variable? have you checked?
looks line line count abbreviated. if it isn't, it is named poorly. if
it is, decrementing a line count makes no sense. but you may understand
it. i won't delve into the logic as i said the code is too bad to
bother.
>> but what about the done flag?? don't mix loop flags with flow control
>> ops. just dumb. pick one style.
s> It looks like he uses the fall-through method, avoiding the extra
s> machine cycles. I think the $done flag is set elsewhere as well
you again don't understand perl and machine cycles. perl HAS NO MACHINE
CYCLES. it has operations in an op loop. you don't optimize perl that
way. and this code could be optimized, simplified and made much better
with a decent design without the stupid loop flag and all those
if/elses.
would you believe i have a 10k line perl system with about 25 else
clauses in total? and it is very clean and readable code throughout. not
hard to do at all if you know perl and coding. eschew else is my new motto.
s> ## flag serialized comments/cdata buffering
s> if (/(<!--)|(<!\[CDATA\[)/)
>>
>> more complex regexes that need /x
s> not sure its relavent for this, could be right, though with no effect
effect? what are you babbling about? /x HAS NO EFFECT on regexes. it is
not meant to have any effect (actually it does on the syntax but not
worth covering here). it is meant for CLARITY. but the author knows not
of that.
>> the nesting here is getting very deep. a sign of someone who loves
>> if/else too much. a cleaner design would be simpler, easier to read and
>> understand.
s> The if/then/else construct can't be avoided. The machining can be
s> trimmed. He did a good job thinning with single if's comparisons
s> to make a path back. I don't see any faster constructs than what
s> he's got
it can easily be simplfied. just a poor design requires all that
if/else stuff. read what i said above with eschew else. this code is
done in basic style.
>>
s> }
s> }
s> elsif (defined $2) { # complete cdata
>>
>> why check those two separately but match in one regex? just test one
>> pattern and handle it or test the other. this is bullshit code. way
>> longer and more complex than it needs to be.
s> Yea its either one or the other. Did he expect more?
huh?? i was suggesting how to clean up that mess. match and test one,
then match and test the other. the way he did it is longer, slower,
clunkier.
>>
s> if ($$ref_parse_ln !~
s> /<!\[CDATA\[.*?\]\]>/s)
s> {
>>
>> he uses ! all over and here he switches to !~ which is rarely used.
s> Looks like he positively wanted to know if that was case. Looks alright
ok, you have blinders on. i give up.
>> can you even tell what this is the else for? it scrolled off my screen.
s> what "else" are you looking at. Apparently, />/ is like a period at
s> the end of a sentence. Otherwise better to not do anything at the
s> termination of this block or will be trouble, you are in the middle
s> of a sentence
you don't get it.
>>
s> } else {
s> $ln_cnt = 1;
s> $done = 1;
>>
>> now we're done? do we exit the loop here? who knows? i have to scroll up
>> and find the if and see it that falls through or what??
s> To me it looks like if its streamed (not BUFFERED) he is waiting
s> for a complete sentence with the />/ to pass through to the formal
s> parser below this. If it is BUFFERED, means the complete file is
s> passed to the formal parser. Streaming, it looks like he waits for
s> a complete sentence, parses, goes back up top, gets another, etc...
insane. you can merge both into one flow with no troubles at all. done
all the time in parsers. you make the input an iterator or sub that
works on the stream or the text. reduces his code by half as there is no
need for such a long if/else block.
s> When you have it buffered from above (or already buffered), parse it:
>>
s> ## REGEX Parsing loop
s> while ($$ref_parse_ln =~ /$RxParseXP1/g)
s> {
s> ## CDATA
s> if (defined $0) {
>>
>> oh that is wonderful. a true bug by the way. $0 is the name of the
>> program and not a grabbed match. not that he does any work in this if
s> My mistake, I transposed his variabes, should have been $1, $2
huh? what transpose? this is your code or his?
>>
s> }
s> ## COMMENT
s> elsif (defined $1) {
>>
>> again, an empty else clause. wo what was the purpose of this if/else?
>> showing off more bad code is my guess.
s> I just meant to condense his code for an example. The unfilled block
s> is left as an exercise
i prefer to read real code, not empty clauses.
s> He's probably psycotic or genious, I don't know of him. The code
s> looks good though. Its possible that the "order" of the parse
s> regex is important. I think it is. Here:
i will bet the house on psychotic. look at his posting history
here. rants and drools and flames all over the place. no one here
respects his code at all.
$done = 1 ;
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
------------------------------
Date: Fri, 2 Feb 2007 05:42:08 GMT
From: merlyn@stonehenge.com (Randal Schwartz)
Subject: new CPAN modules on Fri Feb 2 2007
Message-Id: <JCtMI8.s0E@zorch.sf-bay.org>
The following modules have recently been added to or updated in the
Comprehensive Perl Archive Network (CPAN). You can install them using the
instructions in the 'perlmodinstall' page included with your Perl
distribution.
Acme-Lou-0.03
http://search.cpan.org/~tomita/Acme-Lou-0.03/
Let's together with Lou Ohshiba
----
Algorithm-AhoCorasick-0.01
http://search.cpan.org/~vbar/Algorithm-AhoCorasick-0.01/
efficient search for multiple strings
----
Apache-AuthCookieDBI-1.24
http://search.cpan.org/~matisse/Apache-AuthCookieDBI-1.24/
An AuthCookie module backed by a DBI database.
----
Bio-DOOP-DOOP-0.08
http://search.cpan.org/~tibi/Bio-DOOP-DOOP-0.08/
DOOP API main module
----
Business-CCProcessor-0.05
http://search.cpan.org/~hesco/Business-CCProcessor-0.05/
Pass transaction off to secure processor
----
Cache-Static-0.9905
http://search.cpan.org/~brianski/Cache-Static-0.9905/
Caching without freshness concerns
----
Data-Visitor-Encode-0.02
http://search.cpan.org/~dmaki/Data-Visitor-Encode-0.02/
Encode/Decode Values In A Structure
----
File-Monitor-v0.0.1
http://search.cpan.org/~andya/File-Monitor-v0.0.1/
Monitor files and directories for changes.
----
File-Monitor-v0.0.2
http://search.cpan.org/~andya/File-Monitor-v0.0.2/
Monitor files and directories for changes.
----
FormValidator-Simple-0.21
http://search.cpan.org/~lyokato/FormValidator-Simple-0.21/
validation with simple chains of constraints
----
Fortran-F90Format-0.40
http://search.cpan.org/~vms/Fortran-F90Format-0.40/
Read and write data using FORTRAN 90 I/0 formatting
----
HTML-WebDAO-0.74
http://search.cpan.org/~zag/HTML-WebDAO-0.74/
Perl extension for create complex web application
----
Image-Identicon-0.01
http://search.cpan.org/~hio/Image-Identicon-0.01/
Generate Identicon image
----
Image-Pngslimmer-0.07
http://search.cpan.org/~acmcmen/Image-Pngslimmer-0.07/
slims (dynamically created) PNGs
----
Is-Kennitala-0.03
http://search.cpan.org/~avar/Is-Kennitala-0.03/
Validate and process Icelandic personal identification numbers
----
Lingua-ZH-WordSegment-0.02
http://search.cpan.org/~chenyr/Lingua-ZH-WordSegment-0.02/
Simple Simplified Chinese Word Segmentation
----
Lingua-ZH-WordSegment-0.03
http://search.cpan.org/~chenyr/Lingua-ZH-WordSegment-0.03/
Simple Simplified Chinese Word Segmentation
----
Log-Detect-1.422
http://search.cpan.org/~wsnyder/Log-Detect-1.422/
Read logfiles to detect error and warning messages
----
Mail-Karmasphere-Client-2.06
http://search.cpan.org/~shevek/Mail-Karmasphere-Client-2.06/
Client for Karmasphere Reputation Server
----
Make-Cache-1.042
http://search.cpan.org/~wsnyder/Make-Cache-1.042/
Caching of object and test run information
----
MasonX-WebApp-0.12
http://search.cpan.org/~drolsky/MasonX-WebApp-0.12/
Works with Mason to do processing before Mason is invoked
----
MetaStore-0.22
http://search.cpan.org/~zag/MetaStore-0.22/
Set of classes for multiuser web applications.
----
Net-SIP-0.17
http://search.cpan.org/~sullr/Net-SIP-0.17/
Framework SIP (Voice Over IP, RFC3261)
----
Objects-Collection-0.32
http://search.cpan.org/~zag/Objects-Collection-0.32/
abstract class for collections of data.
----
POE-Component-IRC-5.21
http://search.cpan.org/~bingos/POE-Component-IRC-5.21/
a fully event-driven IRC client module.
----
POE-Component-Server-Chargen-1.04
http://search.cpan.org/~bingos/POE-Component-Server-Chargen-1.04/
a POE component implementing a RFC 864 Chargen server.
----
POE-Component-Server-Daytime-1.04
http://search.cpan.org/~bingos/POE-Component-Server-Daytime-1.04/
a POE component implementing a RFC 865 Daytime server.
----
POE-Component-Server-Discard-1.04
http://search.cpan.org/~bingos/POE-Component-Server-Discard-1.04/
a POE component implementing a RFC 863 Discard server.
----
POE-Component-Server-Qotd-1.04
http://search.cpan.org/~bingos/POE-Component-Server-Qotd-1.04/
a POE component implementing a RFC 865 QotD server.
----
POE-Component-Server-Time-1.04
http://search.cpan.org/~bingos/POE-Component-Server-Time-1.04/
a POE component implementing a RFC 868 Time server.
----
POE-Filter-LZF-1.60
http://search.cpan.org/~bingos/POE-Filter-LZF-1.60/
A POE filter wrapped around Compress::LZF
----
POE-Filter-LZO-1.60
http://search.cpan.org/~bingos/POE-Filter-LZO-1.60/
A POE filter wrapped around Compress::LZO
----
POE-Filter-LZW-1.60
http://search.cpan.org/~bingos/POE-Filter-LZW-1.60/
A POE filter wrapped around Compress::LZW
----
Parallel-Forker-1.214
http://search.cpan.org/~wsnyder/Parallel-Forker-1.214/
Parallel job forking and management
----
Pod-Simple-Wiki-0.07
http://search.cpan.org/~jmcnamara/Pod-Simple-Wiki-0.07/
A class for creating Pod to Wiki filters.
----
Test-YAML-Valid-0.03
http://search.cpan.org/~jrockway/Test-YAML-Valid-0.03/
Test for valid YAML
----
Timestamp-Simple-1.00
http://search.cpan.org/~shoop/Timestamp-Simple-1.00/
Simple methods for timestamping
----
Unix-Processors-2.034
http://search.cpan.org/~wsnyder/Unix-Processors-2.034/
Interface to processor (CPU) information
----
XML-Comma-1.22
http://search.cpan.org/~brianski/XML-Comma-1.22/
A framework for structured document manipulation
----
XML-RSS-Liberal-0.02
http://search.cpan.org/~dmaki/XML-RSS-Liberal-0.02/
XML::RSS With A Liberal Parser
If you're an author of one of these modules, please submit a detailed
announcement to comp.lang.perl.announce, and we'll pass it along.
This message was generated by a Perl program described in my Linux
Magazine column, which can be found on-line (along with more than
200 other freely available past column articles) at
http://www.stonehenge.com/merlyn/LinuxMag/col82.html
print "Just another Perl hacker," # the original
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <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!
------------------------------
Date: Fri, 02 Feb 2007 12:28:08 +0500
From: Ayaz Ahmed Khan <ayaz@dev.slash.null>
Subject: Re: perl one liner to remove all but the base file name
Message-Id: <pan.2007.02.02.07.28.06.588687@dev.slash.null>
"Oxnard" typed:
> If I have a file name like:
>
> /dkdk888/jdty/file.txt
>
> how can I get to just 'file' using a regex. I have come up with
Alternatively, split() and a little bit of regex can do that easily:
perl -e '$x = "/some/path/file.ext"; @x = split("\/", $x);
$x[-1] =~ s|\..+$||g; print $x[-1];'
--
Ayaz Ahmed Khan
A witty saying proves nothing, but saying something pointless gets
people's attention.
------------------------------
Date: 1 Feb 2007 22:46:50 -0800
From: robertchen117@gmail.com
Subject: please explain to me
Message-Id: <1170398810.277590.125950@p10g2000cwp.googlegroups.com>
please explain this to me:
s/\s+(!\W+)/$1 /;
s is replace, expecially (!\W+)
------------------------------
Date: Fri, 02 Feb 2007 09:22:33 +0200
From: Alex <check.sig@for.email.invalid>
Subject: Re: please explain to me
Message-Id: <%EBwh.1946$JE4.535@reader1.news.saunalahti.fi>
robertchen117@gmail.com wrote:
> please explain this to me:
>=20
> s/\s+(!\W+)/$1 /;
>=20
>=20
> s is replace, expecially (!\W+)
perldoc perlre
It's an exclamation mark. AFAIK it doesn't have any special meanin, at
least in this context.
So the regexp replaces one or more whitespace characters followed by one
or more non-alphabetic characters beginning with (and including) an
exclamation mark.
For illustration, try using putting parenthesis around the captured
variable like so (dropping the last space):
perl -ane 's/\s+(!\W+)/($1)/;print'
input:
!"#&%asf
!/(%df
!"#=A1=E8%asdf
#=A1=E8%&asdf
output:
(!"#=A1=E8%)asf
(!/(%)df
!"#=A1=E8%asdf
#=A1=E8%&asdf
Note the lack of a space on the third line, and the lack of an
exclamation mark on the fourth line. I guess the ! in the regexp might
have confused you into thinking it to be the NOT-operator?
HTH
--=20
Alex
e-mail: Domain is iki dot fi. Local-part is alext.
local-part at domain
------------------------------
Date: Fri, 2 Feb 2007 08:25:33 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Read on closed filehandle
Message-Id: <slrnes5prd.9at.hjp-usenet2@yoyo.hjp.at>
On 2007-02-01 23:03, Russ <Russ.Dilley@gmail.com> wrote:
> Also, 'perl -V' does not reference uselargefiles. Is that something
> that is set when perl in initially compiled on the system? Does perl
> need to be recompiled to set this value?
Yes.
hp
--
_ | Peter J. Holzer | Es ist ganz einfach ihn zu verstehen, wenn
|_|_) | Sysadmin WSR | man nur alle wichtigen Worte im Satz durch
| | | hjp@hjp.at | andere ersetzt.
__/ | http://www.hjp.at/ | -- Nils Ketelsen in danr
------------------------------
Date: Fri, 2 Feb 2007 07:43:14 +0000 (UTC)
From: vjp2@panix.com
Subject: Stick Lines and Dividers Between Text
Message-Id: <epuq2i$brh$1@reader2.panix.com>
is that x or *???
perl -pe 'if ($.%4==2){$_.="-" x 37} elseif {$.%4==0) {$_.="=" x 37} $_.="\n"'
< %1 >%1
------------------------------
Date: Thu, 01 Feb 2007 21:05:28 -0600
From: "Mumia W. (NOSPAM)" <paduille.4060.mumia.w+nospam@earthlink.net>
Subject: Re: Storing results in array rather than printing
Message-Id: <epuhlj$qj9$1@aioe.org>
On 02/01/2007 01:13 PM, joseph85750@yahoo.com wrote:
> I have a unix program called zathras which will generate some useful
> output results when a file is piped into it.
>
> ie:
>
> cat /path/to/asci-file.txt | zathras
> (this will output some text I wish to capture)
> [...]
Xhoster's advice is good. In addition, you might consider using Expect.pm.
--
Windows Vista and your freedom in conflict:
http://techdirt.com/articles/20061019/102225.shtml
------------------------------
Date: 01 Feb 2007 21:47:40 -0500
From: Charlton Wilbur <cwilbur@chromatico.net>
Subject: Re: Upload file fails
Message-Id: <87wt31qnqr.fsf@mithril.chromatico.net>
>>>>> "PG" == Purl Gurl <purlgurl@purlgurl.net> writes:
>> the "don't bother with binmode on Unixlikes" advice is
>> outdated.
PG> Are you factually stating there are no systems in use which
PG> are binmode sensitive?
Exactly the opposite, actually; there are many systems in use which
*are* sensitive to binmode. Including some that formerly were not.
PG> I am very skeptical about your statements. You are informing
PG> readers there are no longer any systems, no longer any reasons
PG> to be concerned about binmode being used, or not used.
Er, no. I'm informing readers of exactly the opposite - that when
they expect binary data, they should use the binmode statement.
You're the one advising people to omit them.
PG> Your statements are based upon a premise all systems,
PG> literally all systems run the most recent operating systems
PG> and most recent versions of Perl and based upon a premise
PG> there are no systems found which are binmode sensitive.
No, it's based on the *fact*, documented in the perldocs, that with
various encodings and line disciplines, it's relevant to indicate to
the system whether you expect the file to be binary or text.
Given that I'm advising people to follow the directions in the
perldocs -- namely, to use binmode when you expect binary data, and
not to use it otherwise -- I'm not sure why you're tilting at this
particular windmill. All the world can no longer be safely assumed to
run in ASCII, and input and output layers can make binmode meaningful
even on Unixlikes.
My premise is that when you expect to deal with raw binary data, you
use binmode, as documented in the perldocs. When you expect to deal
with text, you do not. On systems where this does not matter, the
binmode statement is a no-op; on systems where this does matter, the
binmode statement is meaningful. The use of different encodings and
input and output layers means that binmode is meaningful even on
systems where it formerly was not.
What it boils down to is this.
Some systems do not distinguish between text and binary files. On
these systems, using binmode does not change anything.
Other systems *do* distinguish between text and binary files. On
these systems, not using binmode causes problems.
And there are many systems which *formerly* did not distinguish
between text and binary files, but which are now. In particular, you
will get different results if you treat files encoded in UTF-8 or
UTF-16 as binary files than if you treat them as text files.
None of this is based on assuming that the whole world has ceased to
distinguish between binary and text files. On the contrary, it's
based on the evidence that text encodings are not all ASCII anymore.
It's also not based on assuming that the whole world is running 5.8.8.
On the contrary, it's based on future-proofing the script. Sooner or
later, that script is going to be run in a different environment --
possibly because a sysadmin upgraded to 5.8.8 without sending you the
memo - and it's better to be clear about what you intend and expect,
or it is likely to break.
Charlton
--
Charlton Wilbur
cwilbur@chromatico.net
------------------------------
Date: Thu, 01 Feb 2007 19:42:15 -0800
From: Purl Gurl <purlgurl@purlgurl.net>
Subject: Re: Upload file fails
Message-Id: <45C2B317.5030600@purlgurl.net>
Charlton Wilbur wrote:
> Purl Gurl wrote:
(snipped - read thread for full context)
> Er, no. I'm informing readers of exactly the opposite - that when
> they expect binary data, they should use the binmode statement.
> You're the one advising people to omit them.
You are practicing deceit. I wrote no such advice.
> Given that I'm advising people to follow the directions in the
> perldocs -- namely, to use binmode when you expect binary data, and
> not to use it otherwise....
Which prompts a question. Previously you critique my advice
based on a premise my suggestion to remove binmode code for
a Linux machine is not needed. Currently you are writing
precisely what I previously wrote; remove binmode when
not needed. Why is this?
Strikes me you change your tune to fit whatever music is playing.
Those directions in Perl documentation, do those directions cover
and discuss every possible programming circumstances?
A rhetorical question begging no answer. Almost all of us know the
answer. Perl documentation cannot cover every programming possibility.
> Some systems do not distinguish between text and binary files. On
> these systems, using binmode does not change anything.
You do not know this, factually. Systems vary widely, system configurations
vary widely, system users may or may not deploy a system correctly, there
are so many variables involved, your statement cannot be fully factual.
Immediate previous, you write to not use binmode when not needed.
Currently you write leave binmode in code when not needed.
Cake and eat it too.
> It's also not based on assuming that the whole world is running 5.8.8.
> On the contrary, it's based on future-proofing the script. Sooner or
> later, that script is going to be run in a different environment --
> possibly because a sysadmin upgraded to 5.8.8 without sending you the
> memo - and it's better to be clear about what you intend and expect,
> or it is likely to break.
"...future-proofing the script."
Ah, so readers should write scripts to be portable for all versions
of Perl. Does this include Perl 4.x and Perl 6.x versions?
Do all Perl 5.6.x scripts run correctly under Perl 5.8.x versions?
Do all Perl 5.8.x scripts run correctly under Perl 6.x versions?
You have a serious problem. Your Perl 5.8 version scripts will
not run correctly under Perl 6.x versions. You should practice
what you preach. My expectation is you will correct all your
Perl 5.8 scripts to run under both Perl 5.8 and Perl 6.x versions.
This is precisely what you are advising readers,
"...because a sysadmin upgraded to 5.8.8...."
So, get busy fixing your scripts. In time, some system administrator
will upgrade to Perl 6.x and your scripts will be FUBAR! I believe
you should drop out of this newsgroup and spend the next few months
correcting all your scripts to run under any version of Perl. This
is your advice to readers, follow your own advice lest readers should
question your advice.
Does this not exemplify Perl scripts will behave differently under
different versions of Perl? How is it you factually know binmode
will behave the same under all versions of Perl? How is it you
factually know binmode will behave the same on all systems?
Rhetorical question, again. You do not know. I do not know.
Nobody knows, including Randal. No one person can know of all
the variables involved with systems, Perl, Apache and whatever
other programs and system configurations.
Problem here is not my advice to an author, who has subsequently
vanished as is typical, not my advice to remove binmode code when
not needed. True problem is you and another display a long historical
habit of frantically seeking any reason to nitpick and annoy those
participants you do not like.
You, like many of the boys here, change your story with each article,
change your story to fit changing challenges to your opinions. You
boys will write just about anything to create a facade of being
skilled Perl programmers, when you are not. Oh, you are decent
Perl programmers but you are not as skilled of Perl programmers
as you would have readers believe.
You are a player, not a programmer.
Purl Gurl
* for readers who are interested in learning, for this case example,
removing the binmode code eliminates any possibility of that binmode
code be a source of problems. You will not know, it is impossible to
know if that binmode code is problematic if you do not test. Only
method to test is to take the code out and observe results.
That, my friends, is good Scientific Method.
------------------------------
Date: 02 Feb 2007 00:55:21 -0500
From: Charlton Wilbur <cwilbur@chromatico.net>
Subject: Re: Upload file fails
Message-Id: <87ododqf1y.fsf@mithril.chromatico.net>
>>>>> "PG" == Purl Gurl <purlgurl@purlgurl.net> writes:
PG> Charlton Wilbur wrote:
>> Purl Gurl wrote:
PG> (snipped - read thread for full context)
>> Er, no. I'm informing readers of exactly the opposite - that
>> when they expect binary data, they should use the binmode
>> statement. You're the one advising people to omit them.
PG> You are practicing deceit. I wrote no such advice.
From 45C1FE5A.3070104@purlgurl.net, posted today:
PG> Do not use binmode for Unix / Linux systems.
>> Given that I'm advising people to follow the directions in the
>> perldocs -- namely, to use binmode when you expect binary data,
>> and not to use it otherwise....
PG> Which prompts a question. Previously you critique my advice
PG> based on a premise my suggestion to remove binmode code for a
PG> Linux machine is not needed. Currently you are writing
PG> precisely what I previously wrote; remove binmode when not
PG> needed. Why is this?
Because "not needed" is different in the two situations.
You're advising people to omit binmode when on a Linux machine. I'm
advising people to omit binmode when they're expecting textual data.
Continue your logorrhea if you will. I've made my point, and you've
demonstrated that you're unable or unwilling to understand it.
Charlton
--
Charlton Wilbur
cwilbur@chromatico.net
------------------------------
Date: Fri, 2 Feb 2007 18:47:45 +1100
From: "Sisyphus" <sisyphus1@nomail.afraid.com>
Subject: Re: Win32::Clipboard mutilates \n
Message-Id: <45c2ed22$0$5746$afc38c87@news.optusnet.com.au>
"Fred Hare" <fred4414@nethere.com> wrote in message
news:tPidneCOVrYU81_YnZ2dnUVZ8t2snZ2d@giganews.com...
.
.
> OK, I tried 8 different text editors and also
> my $clip = Win32::Clipboard::GetText();
> print "Clipboard content is $clip\n" ;
>
> All but Windows Notepad and UltraEdit converted "0A" back to "0D 0A"
Do they convert back to "0D 0A" or do they simply print the newline on the
strength of the solitary "0A" ?
It seems to me that Win32::Clipboard copies exactly what it is given:
C:\_32\pscrpt>type try.pl
use strict ;
use warnings ;
use Win32::Clipboard ;
my $CLIP = Win32::Clipboard();
my $block = "line1\nline2\nline3\n" ;
for(0 .. length($block) - 1) {
printf "%x ", ord(substr($block, $_, 1));
}
print "\n";
$CLIP->Set($block);
my $text = Win32::Clipboard::GetText();
for(0 .. length($text) - 1) {
printf "%x ", ord(substr($text, $_, 1));
}
C:\_32\pscrpt>perl try.pl
6c 69 6e 65 31 a 6c 69 6e 65 32 a 6c 69 6e 65 33 a
6c 69 6e 65 31 a 6c 69 6e 65 32 a 6c 69 6e 65 33 a
Some text editors (such as Wordpad) seem to happily print a newline on the
strength of a solitary "0A". Others, such as Notepad, will not.
If you want to be sure that the editor does what you want, I think you need
to replace each occurrence of "\n" with "\r\n" - which will hopefully work
for *all* text editors.
Cheers,
Rob
------------------------------
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 96
*************************************
