[28779] in Perl-Users-Digest
Perl-Users Digest, Issue: 23 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat Jan 13 21:05:38 2007
Date: Sat, 13 Jan 2007 18:05:03 -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 Sat, 13 Jan 2007 Volume: 11 Number: 23
Today's topics:
Re: Ascii characters in a loop <RedGrittyBrick@SpamWeary.foo>
Re: Ascii characters in a loop <RedGrittyBrick@SpamWeary.foo>
Re: Ascii characters in a loop <novafyre@hotmail.com>
Re: matching a complicated url in a regular expression <DJStunks@gmail.com>
Re: Unix commands <abigail@abigail.be>
Re: Unix commands <john@castleamber.com>
Re: Unix commands <john@castleamber.com>
Re: Unix commands <john@castleamber.com>
Re: Unix commands <abigail@abigail.be>
Re: Unix commands <abigail@abigail.be>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sun, 14 Jan 2007 00:05:56 +0000
From: RedGrittyBrick <RedGrittyBrick@SpamWeary.foo>
Subject: Re: Ascii characters in a loop
Message-Id: <fIadndjSBbZ47jTYRVnyggA@bt.com>
Mark Hobley wrote:
> The following loop works fine in Perl:
>
> for ($l = 'a'; $l le 'y'; $l++) {
> print "$l";
> }
>
> However, if I try to loop from a through to z, the loop does not work:
It does but it produces results you might not have expected.
>
> for ($l = 'a'; $l le 'z'; $l++) {
> print "$l";
> }
>
Because of the way the post-increment operator works on strings.
See `perldoc perlop` under Auto-increment.
The value after 'z' is 'aa' and 'aa' is still stringwise less than 'z'.
Luckily 'zz' is greater than 'z'.
------------------------------
Date: Sun, 14 Jan 2007 00:13:00 +0000
From: RedGrittyBrick <RedGrittyBrick@SpamWeary.foo>
Subject: Re: Ascii characters in a loop
Message-Id: <ltudnQDaFPMR6DTYRVnygAA@bt.com>
RedGrittyBrick wrote:
> Mark Hobley wrote:
>> The following loop works fine in Perl:
>>
>> for ($l = 'a'; $l le 'y'; $l++) {
>> print "$l";
>> }
>>
>> However, if I try to loop from a through to z, the loop does not work:
>
> It does but it produces results you might not have expected.
>
>>
>> for ($l = 'a'; $l le 'z'; $l++) {
>> print "$l";
>> }
>>
>
> Because of the way the post-increment operator works on strings.
> See `perldoc perlop` under Auto-increment.
>
> The value after 'z' is 'aa' and 'aa' is still stringwise less than 'z'.
>
> Luckily 'zz' is greater than 'z'.
Oh yes,
Why exactly don't you want a foreach loop?
C:\>perl -e "for $x ('a'..'z') { print \"$x,\";}"
a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p,q,r,s,t,u,v,w,x,y,z,
C:\>perl -e "$e='z'; for $x ('a'..$e) { print \"$x,\";}"
a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p,q,r,s,t,u,v,w,x,y,z,
------------------------------
Date: Sat, 13 Jan 2007 17:39:49 -0700
From: Mark Donovan <novafyre@hotmail.com>
Subject: Re: Ascii characters in a loop
Message-Id: <C1CEC9E5.8FD5%novafyre@hotmail.com>
On 1/13/07 16:04, in article rm4o74-cqk.ln1@neptune.markhobley.yi.org, "Mark
Hobley" <markhobley@hotpop.deletethisbit.com> wrote:
> The following loop works fine in Perl:
>
> for ($l = 'a'; $l le 'y'; $l++) {
> print "$l";
> }
>
> However, if I try to loop from a through to z, the loop does not work:
>
> for ($l = 'a'; $l le 'z'; $l++) {
> print "$l";
> }
>
> I know that a for each loop would work, but that is not what I want.
>
I think you're expecting: abcdefghijklmnopqrstuvwxyz
And if that's what you want, you must use ne instead of le to end the loop.
for ($l = 'a'; $l ne 'z'; $l++) {
print "$l";
}
If you replace
print "$l";
with
print "$l ";
you can see what's happening. Change the comparison from le the ne, and the
loop stops at z, but with le, the loop does not stop until zz is less than
z.
Try this little experiment.
print join(' ', sort qw( a b c x y z aa bb cc xx yy zz )), "\n";
There are two things happening in your second loop. First, Auto-increment
for string data is smarter than you expect, maybe too smart. The next value
after z is aa. Second, operators like lt, le, eq, ne, ge, and gt are
stringwise comparisons. This means the result of a comparison reflects the
sorting order of the strings, and as you see from the experiment, aa is less
than z.
--
Regards,
Mark
------------------------------
Date: 13 Jan 2007 15:14:36 -0800
From: "DJ Stunks" <DJStunks@gmail.com>
Subject: Re: matching a complicated url in a regular expression
Message-Id: <1168730075.199280.190300@s34g2000cwa.googlegroups.com>
Nospam wrote:
> http://www.dailymotion.com/flash/flvplayer.swf?20061026012254&url=http%3A%2F%2Fash-v76.ash.youtube.com%2Fget_video%3Fvideo_id%3Du3iK2fP0Nfs
>
> I have a series of links similar to this:
> http://www.example.com/example/example.swf?20061026012254&url=http%3A%2F%2Fash-v76.bash.randsamp.com%2Fget_samp%3Fsamp_id%3Du3iK2fP0Nfs
>
> How do I place it in a regular expresion to match the whole url, would
> something like this work:
>
> /www\.example\.com\.swf/
that doesn't look like the whole URL to me. In fact, swf isn't a
recognized IANA TLD (http://data.iana.org/TLD/tlds-alpha-by-domain.txt)
anyway, to answer your question, "Regexp::Common::URI -- provide[s]
patterns for URIs."
-jp
------------------------------
Date: 13 Jan 2007 23:13:26 GMT
From: Abigail <abigail@abigail.be>
Subject: Re: Unix commands
Message-Id: <slrneqipsh.ge.abigail@alexandra.abigail.be>
Tintin (tintin@invalid.invalid) wrote on MMMMDCCCLXXXIII September
MCMXCIII in <URL:news:45a92ff4$0$13114$88260bb3@free.teranews.com>:
||
|| "Abigail" <abigail@abigail.be> wrote in message
|| news:slrneqg79p.ge.abigail@alexandra.abigail.be...
|| > ?? my @files = `ls /some/directory`;
|| >
|| > That surely beats:
|| >
|| > opendir my $dh => '/some/directory' or die "opendir: $!";
|| > my @files = grep {!/^\./} readdir $dh;
|| > closedir $dh;
|| >
|| > which takes three times as many lines.
||
|| In that instance, the cat is shorter, but why use the above, when you can do
||
|| my @files = </some/directory/*>;
Because glob expands like the csh does. And the csh often does things
I don't expect. So I avoid glob. Besides, glob() has changed subtlety
between perl versions.
Abigail
--
perl -e '$a = q 94a75737420616e6f74686572205065726c204861636b65720a9 and
${qq$\x5F$} = q 97265646f9 and s g..g;
qq e\x63\x68\x72\x20\x30\x78$&eggee;
{eval if $a =~ s e..eqq qprint chr 0x$& and \x71\x20\x71\x71qeexcess}'
------------------------------
Date: 13 Jan 2007 23:19:44 GMT
From: John Bokma <john@castleamber.com>
Subject: Re: Unix commands
Message-Id: <Xns98B7B04627F2Ecastleamber@130.133.1.4>
Andrew DeFaria <Andrew@DeFaria.com> wrote:
> John Bokma wrote:
>>>> Maybe reread "<X5CdnYE4KLbIpDXYnZ2dnUVZ_rHinZ2d@comcast.com>"
>>> That's an email address. Tell me, how do I read an email address?
>> Usenet newbie?
> Hardly.
Odd, have problems quoting and posting in general and mistake a message
ID for an email address.
> Hmmm...
> http://groups.google.com/groups?
selm=X5CdnYE4KLbIpDXYnZ2dnUVZ_rHinZ2d@c
> omcast.com yields:
>
> The requested message,
> X5CdnYE4KLbIpDXYnZ2dnUVZ_rHinZ2d@comcast.com, could not be found..
"if the message has been archived in Google"
<Xns98B79525AECDCcastleamber@130.133.1.4>
> Finding it by hand I take it you mean when I said:
>
> Because 1) it's inefficient in that you are forking and exec'ing a
No, the part before it:
> Depends on what you're doing of course.
> process to do it and 2) portability - there's no guarantee that
> the next platform you port this to has the same commands. For
> example, you use "ls" above. But there is no "ls" under Windows.
> If instead you use a more Perl like way your Perl script will
> immediately port without and issue.
>
> This was in response to your statement "Why would I copy a program
> that does already its work perfectly and reinvent the wheel?".
Yes, it sounded silly. It still does. Like I said: it depends on what
you're doing. The fork overhead and the portability, if you know what
you're doing, might be considered a small price to pay for not inventing
the wheel again.
> Sorry
> but I still just don't see it. Your claim is that I stated one must
> follow some rigid rule.
That's how I read your posts. If people state that there are plenty of
situations one can call an external program because fork overhead and
portability (or lack off) are a non-issue you call them lazy,
incompetent and start a pissing contest.
--
John Experienced Perl programmer: http://castleamber.com/
Perl help, tutorials, and examples: http://johnbokma.com/perl/
------------------------------
Date: 13 Jan 2007 23:20:58 GMT
From: John Bokma <john@castleamber.com>
Subject: Re: Unix commands
Message-Id: <Xns98B7B07BE680Acastleamber@130.133.1.4>
Andrew DeFaria <Andrew@DeFaria.com> wrote:
> I am sooooo sorry. I'll get right on making all my code non-portable and
> inefficient! Give me a break!
I and many others prefer if you start to educate yourself on Usenet. I
mean, posting in HTML is not done. And you called yourself "hardly" a
Usenet newbie.
--
John Experienced Perl programmer: http://castleamber.com/
Perl help, tutorials, and examples: http://johnbokma.com/perl/
------------------------------
Date: 13 Jan 2007 23:36:46 GMT
From: John Bokma <john@castleamber.com>
Subject: Re: Unix commands
Message-Id: <Xns98B7B328944C8castleamber@130.133.1.4>
Andrew DeFaria <Andrew@DeFaria.com> wrote:
> John Bokma wrote:
>> Andrew DeFaria <Andrew@DeFaria.com> wrote:
>>> What an argument to authority?!? Apparently you are also in the
>>> "let's write non-portable and inefficient code" camp.
>> First of all, calling an external program doesn't mean it's
>> non-portable.
> Calling `ls /path/file` certainly is in that ls is not guaranteed to
> be there
where?
> nor is it guaranteed that "/" a valid directory separator.
nor is it guaranteed that there is a perl executable, nor is it
guaranteed that it's the version you're expecting. Nor is it guaranteed
that your Perl program doesn't trigger a platform specific bug in Perl
or the modules you're using. Comes with the job.
> These are portability concerns not impossible hurdles!
Nor is installing ls (for example) an impossible hurdle. If it is, then
it was implied by the requirements of the job, and I wouldn't have
chosen that solution (if it was already apropriate in the first place).
What is it you don't get?
>> Second of all, calling an external program doesn't mean it's
>> inefficient (inefficient in what? excution time, memory usage,
>> development time?)
>
> The first two.
Don't know what your rates are but there are plenty of external programs
that if I have to copy those in Perl that its cheaper to buy an
additional computer or a faster one.
Also, if execution time / memory usage are an issue Perl might be very
well have been a bad choice in the first place.
>> Programming is about using the right tool(s). Using an external
>> program can be the right tool or the wrong tool.
> Yes I agree 100%. It can be the right tool and it also can be the
> wrong tool.
Exactly, I already wrote "Depends on what you're doing of course."
<Xns98B6B0CB3A0D1castleamber@130.133.1.4>
>> To me, and probably others as well, you make it sound like it's not a
>> right tool.
> It demonstrably isn't in that using opendir, etc. is better in terms
> of both memory usage and execution time and really isn't a gigantic
> stretch in terms of development time. Perhaps right and wrong are too
> strong of terms. How about good and better?
Fine with me. You understand that "Depends on what you're doing" was a
reply to "It's generally preferable to use Perl when you write Perl
programs."
I disagree with that. There are plenty of examples that in my opinion an
external program is preferable. Perl is amongst others a glue language.
>> And between the lines I read "never a right tool".
> Your imagination!
>> Maybe my bad, but your heated replies convince me more and more that
>> I am correct on this.
>>
>> And no, you can't prove your point (whatever it is) by showing
>> examples of bad external tool usage and generalize this into: fork
>> overhead and non-portability. Depending on circumstances those
>> arguments might be irrelevant.
> Fork overhead and non-portability are legitimate concerns.
In some situations yes. In plenty of others no. Like I wrote (again):
"Depends on what you're doing"
> Sure people
> can just hack off a system call to ls or something else. Again, I've
> never said there's any sort of rigid rules here. However, are you
> saying that fork overhead and portability issues irrelevant?
Depends on what you're doing
> All I was
> saying, when asked "Why would somebody not use something like 'ls'?",
> fork overhead and portability are two very legitimate reasons why
> somebody would not want to use "ls" in this circumstance. And there
> are other circumstances where the same applies.
I quote the whole thing again:
"
>> It's generally preferable to use Perl when
>> you write Perl programs.
> Depends on what you're doing of course. Why would I copy a program
> that does already its work perfectly and reinvent the wheel? Increase
> development time, and make many mistakes while doing so?
Because 1) it's inefficient in that you are forking and exec'ing a
process to do it and 2) portability - there's no guarantee that the next
platform you port this to has the same commands. For example, you use
"ls" above. But there is no "ls" under Windows. If instead you use a
more Perl like way your Perl script will immediately port without and
issue.
"
My "Depends..." was a comment on the "generally ... use Perl ... write
Perl". You seemed to be trying to make a point by staring yourself blind
on ls.
Again notice that "Depends on what you're doing" is includes all kind of
external programs that can be called from Perl.
Which I do now and then, because when I do so I consider it the (my)
best possible solution.
--
John Experienced Perl programmer: http://castleamber.com/
Perl help, tutorials, and examples: http://johnbokma.com/perl/
------------------------------
Date: 13 Jan 2007 23:38:11 GMT
From: Abigail <abigail@abigail.be>
Subject: Re: Unix commands
Message-Id: <slrneqirap.ge.abigail@alexandra.abigail.be>
Andrew DeFaria (Andrew@DeFaria.com) wrote on MMMMDCCCLXXXIII September
MCMXCIII in <URL:news:7sCdnV2zsL0xszTYnZ2dnUVZ_oipnZ2d@comcast.com>:
//
// Abigail wrote:
// > Bleh. If you do 10,000 calls to 'ls' and it's slow, then it's the disk
// > access that's the bottleneck, not the forks.
// My point is, if 10,000 accesses are required, strapping them with
// additional inefficiencies of 10,000 fork/execs is silly. Now you are
// free to be silly if you want....
But even if you think that, how does that lead to "never use 'ls'"?
While I often write programs that check the content of a single directory,
I don't recall ever writing a program that needed to trawl through
thousands of directories where I couldn't use 'find' (which I prefer
over File::Find).
// > (and the only time I worked for a company where the company decided to
// > port their product to Windows they abandoned their effort after 18
// > months, as they found out their customers weren't interested). If it
// > were to be done, any program would have to be modified anyway.
// Listen sonny, I've probably worked at far more companies than you, many
// who use various platforms. I was talking about writing tools that are
// used in house and not necessarily products sold to end users, though
// there is wisdom in writing portable code nevertheless.
All the Perl programs (and most of the programs in other languages)
I've written for my employers have been in-house tools as well. And
because they are in-house tools, I know in which environment they are
going to be run. Really, if I'm writing a tool to deploy a specific
piece of software that only runs on AIX and for which we have bought
half a million dollars worth of hardware on which Windows won't even run,
I'm not going to worry whether my tool is going to be run on Windows.
Specially not if the tool needs to be ready yesterday.
// there is wisdom in writing portable code nevertheless. I really have a
// hard time understanding your viewpoint. You are actually arguing that
// writing non-portable code that is inefficient is a good thing! I'm sure
// you'll go far with that attitude.
I never argued one should write inefficient code. Or to increase
non-portableness. But programming means making trade-offs. One
trade-off you make is the choice of language. You pick Perl for
whatever reason, but you trade in bucket loads of efficientness.
Whining about efficiency on seeing a single fork/exec but keeping
your mouth shut about the choice of a very slow language is stupid.
// > Yes, and? Just because you have to port your programs to Windows,
// Actually many times I've ported my programs and tools to Unix too!
// > doesn't mean I have to restrict myself and not to use the excellent
// > tools any Unix system gives me.
// You just go ahead and stick your little head back into that ground and
// ignore the fact that Unix isn't the only operating system in town. Now
// don't get me wrong, I use Unix all the time and prefer it. However at
// least I don't live in a cave.
// > I've seen Perl scripts on Windows. And I've seen 'ls' on Windows as
// > well. And 'cat'. And 'echo'. And every other common Unix tool. Unix
// > tools have been ported to Windows. More than once even.
// Granted! Hey I'm a firm advocate on usage of Cygwin. In fact I'd jump
// for joy if MS required it on every installation of Windows!
Good for you. I myself couldn't care less what MS requires on
whatever installation of Windows. As I said, I don't deal with
Windows and I can afford it to pick my place of employment such
that I don't have to deal with Windows either.
// However in the real world you don't always have that. You see aside from
// you sitting in your dark Unix dungeons and dragons cave I've been out in
// the real world and while ls, cat, echo, etc. can be installed on a
// Windows box often it isn't. To code assuming it's there, all the while
// incurring additional fork/exec overhead when there are many much more
// efficient and much more Perl like ways of doing it (in your Perl script,
// we were talking about Perl, remember?) seems to me to be stupid, short
// sighted, lazy, etc.
I just don't like wasting my companies time to make a tool more complex
so it may be run (something I wouldn't even know lacking the OS to
test it out) on a platform that's very unlikely to be used.
// > I'm just saying that if you want to use the argument that certain
// > tools aren't standard on Windows, you should consider that perl isn't
// > standard either.
// If I'm asked to write a Perl script by the client then assuming there'll
// be a Perl interpreter is not a silly assumption.
And just a few paragraphs ago, you were talking about writing in-house tools.
Abigail
--
A perl rose: perl -e '@}-`-,-`-%-'
------------------------------
Date: 13 Jan 2007 23:48:31 GMT
From: Abigail <abigail@abigail.be>
Subject: Re: Unix commands
Message-Id: <slrneqirua.ge.abigail@alexandra.abigail.be>
Andrew DeFaria (Andrew@DeFaria.com) wrote on MMMMDCCCLXXXIII September
MCMXCIII in <URL:news:7sCdnV2zsL0xszTYnZ2dnUVZ_oipnZ2d@comcast.com>:
##
## No my argument is that you shouldn't do 10,000 fork/execs to grep to do
## these regex matches - you should do them internally as that's more
## efficient. Are you really that dense that you cannot see that?
Funny that you mention that example. Some time ago I wrote a program
that repeatedly (as in hundreds of thousands of times) needed to find
words given a certain pattern (the pattern varied). My first attempt
was to read in all the words in an array and use 'grep {/pattern/}'.
It was unbearingly slow, until I started to use the external grep.
The program became much, much faster.
Abigail
--
$_ = "\112\165\163\1648\141\156\157\164\150\145\1628\120\145"
. "\162\1548\110\141\143\153\145\162\0128\177" and &japh;
sub japh {print "@_" and return if pop; split /\d/ and &japh}
------------------------------
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 23
*************************************
