[23929] in Perl-Users-Digest
Perl-Users Digest, Issue: 6130 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Feb 13 14:10:41 2004
Date: Fri, 13 Feb 2004 11:10:11 -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, 13 Feb 2004 Volume: 10 Number: 6130
Today's topics:
Re: Regular Expression Help Needed (Deja User)
Re: Replacing hundreds of hash keys with their values i <apollock11@hotmail.com>
Re: Replacing unicode characters <twhu@lucent.com>
Re: Replacing unicode characters <flavell@ph.gla.ac.uk>
Subroutines (Ondra)
Re: Subroutines <bmb@ginger.libs.uga.edu>
why do some mail servers treat perl generated mails as (KK)
Re: Why is Perl losing ground? (G Klinedinst)
Re: Why is Perl losing ground? <usenet@morrow.me.uk>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 13 Feb 2004 10:06:30 -0800
From: dejauser@safe-mail.net (Deja User)
Subject: Re: Regular Expression Help Needed
Message-Id: <ba74bae9.0402131006.e8d6dae@posting.google.com>
Thanks for very detailed explanation... There is a 3rd party
application I am using that filters out unwanted lines. It uses GNU
regular expression engine.
------------------------------
Date: Fri, 13 Feb 2004 10:46:29 -0800
From: Arvin Portlock <apollock11@hotmail.com>
Subject: Re: Replacing hundreds of hash keys with their values in a text document
Message-Id: <c0j629$re4$1@agate.berkeley.edu>
> If your %characters doesn't include all the non-ascii in the file, you
> could use
>
> my $to_encode = '[' . (join '', keys %characters) . ']';
> while (<$FILE>) {
> s/($to_encode)/$characters{$1}/g;
> print;
> }
>
> Ben
Boy, do I feel like an idiot. That makes MUCH more sense and is just
what I'll do. I have no idea what I was thinking.
> If you're using 5.8, and don't mind having &#nnnn; instead of named
> entities, you can do
>
> use Encode qw/:fallbacks/;
>
> $PerlIO::encoding::fallback = FB_HTMLCREF;
> binmode STDOUT, ':encoding(ascii)';
>
> open my $FILE, '<:encoding(latin1)', $file or die...;
> # or whatever encoding is appropriate
> print while <$FILE>;
Nah, I have to use SDATA entities. I'm not dealing with HTML.
But this is a good trick for another project: converting unicode
characters to numeric decimal entities in HTML files so older
browsers can view them.
Thanks!
Arvin
------------------------------
Date: Fri, 13 Feb 2004 10:18:11 -0500
From: "Tulan W. Hu" <twhu@lucent.com>
Subject: Re: Replacing unicode characters
Message-Id: <c0iprk$oqj@netnews.proxy.lucent.com>
"Ben Morrow" <usenet@morrow.me.uk> wrote
[snip]
> None at all if you're happy with it. This is how one would have done
> it pre-5.8. The point of 5.8 is that it can now be done like this
> instead:
>
> # state that our file is in UTF8
> open my $FILE, '<:encoding(utf8)', 'filename' or die...;
>
> # state that we want output in latin1
> binmode STDOUT, ':encoding(latin1)';
>
> # now just copy it all across
> print while <$FILE>;
>
> which is simpler.
I tried the above and got the following error message
"\x{2019}" does not map to iso-8859-1 at utf.pl line 8, <$FILE> line 161.
but the pre-5.8 code just removes the characters for me.
In my case, I want it just removes the char instead of giving me an error
since other programs cannot handle unicode yet.
------------------------------
Date: Fri, 13 Feb 2004 16:46:49 +0000
From: "Alan J. Flavell" <flavell@ph.gla.ac.uk>
Subject: Re: Replacing unicode characters
Message-Id: <Pine.LNX.4.53.0402131633490.13801@ppepc56.ph.gla.ac.uk>
On Fri, 13 Feb 2004, Tulan W. Hu wrote:
> "Ben Morrow" <usenet@morrow.me.uk> wrote
>
> > # state that our file is in UTF8
> > open my $FILE, '<:encoding(utf8)', 'filename' or die...;
> >
> > # state that we want output in latin1
> > binmode STDOUT, ':encoding(latin1)';
> >
> > # now just copy it all across
> > print while <$FILE>;
>
> I tried the above and got the following error message
> "\x{2019}" does not map to iso-8859-1 at utf.pl line 8, <$FILE> line 161.
That's a correct statment of fact, isn't it?
> but the pre-5.8 code just removes the characters for me.
Why is it advantageous to hide away an error? It's not as if you
can't hide it for yourself, if you know in advance that hiding is what
you want; but if you haven't decided in advance, then surely an error
report is preferable to unannounced loss of data?
> In my case, I want it just removes the char
Shouldn't be too hard to program, no?
> since other programs cannot handle unicode yet.
Maybe it would be more constructive to down-convert it into some kind
of ASCII or iso-8859-1 surrogate, though.
------------------------------
Date: 13 Feb 2004 06:24:58 -0800
From: neufingero@quick.cz (Ondra)
Subject: Subroutines
Message-Id: <9dd8be90.0402130624.972154e@posting.google.com>
I would like to know what is do the code below:
sub safe {
my $url = shift;
return 1 if ($url =~ /^(javascript|mailto):/is);
for (@safe) { #*******I cann't understand this
return 1 if ($url =~ /\w+:\/\/((\w|-)+\.)*$_/is);
}
return 0;
}
Thanks a lot
Ondrej
------------------------------
Date: Fri, 13 Feb 2004 11:42:19 -0500
From: Brad Baxter <bmb@ginger.libs.uga.edu>
Subject: Re: Subroutines
Message-Id: <Pine.A41.4.58.0402131137280.21302@ginger.libs.uga.edu>
On Fri, 13 Feb 2004, Ondra wrote:
> I would like to know what is do the code below:
>
> sub safe {
>
> my $url = shift;
>
> return 1 if ($url =~ /^(javascript|mailto):/is);
>
> for (@safe) { #*******I cann't understand this
> return 1 if ($url =~ /\w+:\/\/((\w|-)+\.)*$_/is);
> }
> return 0;
>
> }
It looks to me like the _intention_ is to verify whether a url matches a
set of 'safe' urls (presumably stored in @safe). However, I'm not
confident the code above does that very well.
Regards,
Brad
------------------------------
Date: 13 Feb 2004 10:06:09 -0800
From: kewlkarun@yahoo.com (KK)
Subject: why do some mail servers treat perl generated mails as Bulk
Message-Id: <c8fd5039.0402131006.419f197b@posting.google.com>
Hi,
With Mail::Sender I could finally able to send mails from windows
machine. However, when I use yahoo DSL HMTP mail server, my mails are
considered Bulk Emails. Is there a way I can avoid this ?
Peon, just curious as to why cant I use these modules to post mails
to employers? would they be detecting them as spam? if yes, how? what
is the best way to mail the same mail to 10 different people? After
all, programming should be practical!
regards,
-KK
Cognition Peon <cenxnfu@rpr.nevmban.rqh> wrote in message news:<Pine.GSO.4.50.0402120949590.27797-100000@shellfish.ece.arizona.edu>...
> Be Careful!! and don't use those modules to spam!!
> Especially Employers!!
>
> 1:51am, IP packets from KK delivered:
>
> > Wondering if anyone can help me in finding the perl's 'sendmail'
> > equivalent command for windows. I want to send a mail from a window
> > machine. regards,
> >
------------------------------
Date: 13 Feb 2004 08:53:24 -0800
From: g_klinedinst@hotmail.com (G Klinedinst)
Subject: Re: Why is Perl losing ground?
Message-Id: <168f035a.0402130853.135ae59e@posting.google.com>
Dominic <roqetman@hotmail.com> wrote in message news:
<23OVb.1$196.899@news.nyc.globix.net>...
> As a programmer who is addicted to Perl, I am curious as to why Perl is
> losing ground to another bunch of languages, namely: Python, PHP and
> Ruby. I'd like to hear your opinions. Is Perl just not "trendy" anymore?
> Does it still scare programmers who haven't used it? Or do the other
> languages have any major advantages over Perl? I haven't worked in these
> other languages, so I'm not qualified to have much of an opinion here.
> What do you think?
>
> - Dom
I think people are fond of PHP for web stuff due to the inline coding
you can do, which is similar to ASP on a MS platform. To a MS web
programmer writing a cgi program which spits out HTML code is wierd.
Don't know about Python or Ruby, but I am very interested in learning
both.
In general, I think that Perl is slightly less popular now(judging
from internet job postings) than it was a few years ago for two main
reasons: A) a general trend toward OOP and B) simpler syntax in other
languages.
I know people will say that Perl can be object oriented, but of course
it was an afterthought with Perl. Other languages were designed from
the ground up to make Objects easy to work with, and not allow a mix
of procedural and OO. As projects and applications get larger and more
complex people want to use OOP, so they pick a language which is
purely OO, and which implements it cleanly.
People also get turned away by Perls syntax. Readability is the key. A
language which allows something like this:
x!($_%7)||$_,$/;z($_+1);
is going to be harder to read than a language which uses this:
print((isFactor( 5, inputString ) || isFactor( 7, inputString ) ||
inputString));
I know those are not the same thing exaclty and wouldn't come close to
compiling, I just don't have time to write them both completely. The
point is that in Perl, brevity has taken the place of readability.
This GREAT for one-liners, etc but for anything which you have to read
it later, it slows development to a crawl. Even on this newsgroup, if
you try to write readable code, people tell you your variables are too
long, you are using too many methods, etc.
I recently replaced a script on a server at work written by someone in
Perl about two years ago. There was no documentation, and it took me a
few hours to read thru it just to see WTF it did. In fact it took me
less time to re-write it's replacement in Perl than it did to read it
and understand it in the first place. As as aside, the reason I had to
read it in such detail is because no one could remember what exactly
it did. The Perl motto on the Camel book says "There's more than one
way to do it." While the freedom to choose is certainly an advantage
when talking about government, or deoderant, or what to have for
dinner, I think it hurts a programming language in the long run
because it hurts readability. Just my $.02, coming from someone who
spent 5 years in school getting readability and documentation hammered
into me so take it for what it's worth.
That being said, I am going back to program some more Perl, but
luckily it's a small program. :-)
-Greg
------------------------------
Date: Fri, 13 Feb 2004 18:09:56 +0000 (UTC)
From: Ben Morrow <usenet@morrow.me.uk>
Subject: Re: Why is Perl losing ground?
Message-Id: <c0j3tk$6gt$1@wisteria.csv.warwick.ac.uk>
g_klinedinst@hotmail.com (G Klinedinst) wrote:
> Dominic <roqetman@hotmail.com> wrote in message news:
> <23OVb.1$196.899@news.nyc.globix.net>...
> >
> > As a programmer who is addicted to Perl, I am curious as to why Perl is
> > losing ground to another bunch of languages, namely: Python, PHP and
> > Ruby. I'd like to hear your opinions. Is Perl just not "trendy" anymore?
> > Does it still scare programmers who haven't used it? Or do the other
> > languages have any major advantages over Perl? I haven't worked in these
> > other languages, so I'm not qualified to have much of an opinion here.
> > What do you think?
>
> In general, I think that Perl is slightly less popular now(judging
> from internet job postings) than it was a few years ago for two main
> reasons: A) a general trend toward OOP and B) simpler syntax in other
> languages.
>
> I know people will say that Perl can be object oriented, but of course
> it was an afterthought with Perl. Other languages were designed from
> the ground up to make Objects easy to work with, and not allow a mix
> of procedural and OO.
Exactly. There are far too many 'S&M' object languages, that are more
interested in forcing you into writing perfect OO than in actually
getting a job done. Perl's OO is the best I've come across: though
what I am comparing it to is C++ and Java. The fact that in Java you
have to have a class just to hold things like Math.sin just shouts
'bodge' to me: the world doesn't fit into your little box, so rather
than let people out of the box you bend the edges until things almost
fit.
> As projects and applications get larger and more complex people want
> to use OOP, so they pick a language which is purely OO, and which
> implements it cleanly.
OK, I have no experience with Large Projects, but I am given to
understand that it's much easier if people stick to Doing Things
Properly. Fine: have coding standards. Fire anyone who doesn't stick
to them. If you want people to write OO Perl, and not break the
encapsulation, then tell them that. It's perfectly possible to write
pure OO in Perl, it's just that it's *also* possible not
to. TMTOWTDI.
> People also get turned away by Perls syntax. Readability is the key. A
> language which allows something like this:
>
> x!($_%7)||$_,$/;z($_+1);
>
> is going to be harder to read than a language which uses this:
>
> print((isFactor( 5, inputString ) || isFactor( 7, inputString ) ||
> inputString));
Leaving aside the fact that the first is golf, and thus deliberately
obfusticated, I find Perl's punctuation makes things much *easier* to
read. To re-write your Perl example to do what the other did:
print !($_ % 5) || !($_ % 7) || $_;
or
print ( $_ % 5 == 0 or $_ % 7 == 0 or $_ );
Or to solve something closer to the original problem:
print $_ % 5 ?
$_ % 7 ?
$_ :
"buzz" :
"fizz";
I find all three of those more readable than that mess of brackets and
studlyCaps.
> I know those are not the same thing exaclty and wouldn't come close to
> compiling, I just don't have time to write them both completely. The
> point is that in Perl, brevity has taken the place of readability.
Wrong.
> This GREAT for one-liners, etc but for anything which you have to read
> it later, it slows development to a crawl. Even on this newsgroup, if
> you try to write readable code, people tell you your variables are too
> long, you are using too many methods, etc.
..I don't think so. Examples?
> I recently replaced a script on a server at work written by someone in
> Perl about two years ago. There was no documentation, and it took me a
> few hours to read thru it just to see WTF it did.
OK, yes, there's one *hell* of a lot of really badly written Perl out
there. Perl is a tool which treats the programmer as a responsible
adult, capable of making sensible decisions about the compromise
between readability and brevity, between getting the thing working now
and keeping it working later. All too many programmers abuse that
responsibility, but that doesn't make Perl a bad language, it makes
tham bad programmers.
The Perl motto on the Camel book says "There's more than one
> way to do it." While the freedom to choose is certainly an advantage
> when talking about government, or deoderant, or what to have for
> dinner, I think it hurts a programming language in the long run
> because it hurts readability.
It doesn't. It *helps* readability, because you can choose the WTDI
that is most readable in the circumstances. Again, often people don't;
but that's their fault, not Perl's.
Ben
--
The cosmos, at best, is like a rubbish heap scattered at random.
- Heraclitus
ben@morrow.me.uk
------------------------------
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 6130
***************************************
