[13072] in Perl-Users-Digest
Perl-Users Digest, Issue: 482 Volume: 9
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Aug 12 12:17:15 1999
Date: Thu, 12 Aug 1999 09:10:17 -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, 12 Aug 1999 Volume: 9 Number: 482
Today's topics:
Substitution cuts off rest of line? <dchurch@kabana.net>
Re: Substitution cuts off rest of line? <jpeterson@office.colt.net>
Re: while loop teminates too early (Larry Rosler)
Re: Why use Perl when we've got Python?! <tchrist@mox.perl.com>
Re: Why use Perl when we've got Python?! <I.Clarke@NOSPAM.strs.co.uk>
Re: Why use Perl when we've got Python?! (John Porter)
Win32 Perl (newbie) <jyoyoliu@hotmail.com>
Work around for signal handler crashes <Philip_Dye@norstanconsult.com>
Digest Administrivia (Last modified: 1 Jul 99) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 12 Aug 1999 08:36:22 -0600
From: "Linux GNUBEE" <dchurch@kabana.net>
Subject: Substitution cuts off rest of line?
Message-Id: <7oum3k$7bh$1@macaw.cyberport.com>
I am trying to redirect a form's output to my own cgi program. I have the
entire form in a variable we'll call $line. Here's a sample of what I am
working with.
$line = "<form action="/cgi-bin/formresults" method=post > <INPUT TYPE=TEXT
NAME=searchstring size=50>"
When I try and replace the "/cgi-bin/formresults" and try to keep the rest
of the string the same, it abruptly cuts off. Here is what I am using to do
the substitution:
$line =~ s/action=.*\s/action=\"\/cgi\/mycgi\"/i;
The result becomes
"<form action="/cgi/mycgi" <INPUT TYPE=TEXT NAME=searchstring size=50>"
instead of
"<form action="/cgi/mycgi" method=post > <INPUT TYPE=TEXT NAME=searchstring
size=50>"
When I initially parsed out the FORM from the entire bunch of HTML code, I
had to use a /s option to force each seaprate line into one long string. IS
the above problem happening because those '\n' characters are still
embedded, or is it something else?
Thanks.
dan :)
------------------------------
Date: Thu, 12 Aug 1999 15:29:34 GMT
From: Jon Peterson <jpeterson@office.colt.net>
Subject: Re: Substitution cuts off rest of line?
Message-Id: <yLBs3.65$u07.632@news.colt.net>
Linux GNUBEE <dchurch@kabana.net> wrote:
> $line = "<form action="/cgi-bin/formresults" method=post > <INPUT TYPE=TEXT
> NAME=searchstring size=50>"
> $line =~ s/action=.*\s/action=\"\/cgi\/mycgi\"/i;
> The result becomes
> "<form action="/cgi/mycgi" <INPUT TYPE=TEXT NAME=searchstring size=50>"
Welcome! You have just encountered greedy quantifiers in regular expressions.
It is now time to take a brief pause from writing code, and to teach yourself
a little more about just how regular expressions work. It is IMPORTANT that
you do this, because regular expressions are pretty fundamental to Perl, and
you really want to know them quite well. So, if you have unix access, you will
want to
man perlre
and
man perlfaq6
preferably printing the results for easier reading. If you do not have access
to unix you will want to visit:
http://www.perl.com/cgi-bin/pace/pub/doc/manual/html/pod/perlre.html
and
http://www.perl.com/cgi-bin/pace/pub/doc/manual/html/pod/perlfaq6.html
If you are intrigued by this you may want to check out the O'Reilly book '
Mastering Regular Expresions' to find out even more.
If you want a solution to your problem, you may want to replace * with *? which
is the non-greedy equivalent. But until you understand greedy and non-greedy,
you are playing with fire :-)
------------------------------
Date: Thu, 12 Aug 1999 08:17:37 -0700
From: lr@hpl.hp.com (Larry Rosler)
Subject: Re: while loop teminates too early
Message-Id: <MPG.121c85689ed6f967989e48@nntp.hpl.hp.com>
In article <37b4aebd.1721404@news.skynet.be> on Thu, 12 Aug 1999
13:44:50 GMT, Bart Lateur <bart.lateur@skynet.be> says...
> Larry Rosler wrote:
>
> >> that should be "while(defined( $line = <USERS> ))". what happens if
> >> you've got a line that evaluates to false?
> >
> >Please don't perpetuate that nonsense.
> >
> >For a while, in perl 5.004, there was a warning about that 'problem',
> >which could *never* occur in any real-life situation dealing with valid
> >'text files' (and if they aren't text files, why would one be reading
> >them a 'line' at a time?).
>
> Huh?
> open OUT,">test.txt";
> print OUT "5\n4\n3\n2\n1\n0";
> close OUT;
>
> Are you saying this isn't a text file? It sure looks like one, to me.
A valid text file is, by *my* definition, a sequence of sequences of
characters, where each sub-sequence is terminated by a newline
character. Dangling characters without a terminating newline character
are not valid. [Can anybody point to such an official definition,
please? The binary/text distinction of the file-test operators is
primarily statistical, based on the proportion of non-ASCII characters
in the file, not the structure of the file.]
> And yet, that problem did occur with it. BTW it does occur, without any
> warning, with older Perl versions.
Yes, the warning was ill-advisedly introduced in 5.004. The grossness
of the error is indicated by the fact that a compile-time warning was
produced by 'while ($line = <FILE>) {' but no warning by 'while (<FILE>)
{'. These are semantically identical except in regard to the
destination of the data.
Somebody chose, without effective review, to impose a personal 'hair-
shirt' mentality on Perl, and was permitted somehow to do so by the
'powers-that-be'.
> It was indeed solved with 5.005 (the "defined" is implied), so it will
> no longer fail.
By 'no longer fail' you mean that the final thing returned on a line-by-
line read of such a file is the non-line consisting solely of the
character '0'. A run-time warning on such an occurrence would be
better!
--
(Just Another Larry) Rosler
Hewlett-Packard Laboratories
http://www.hpl.hp.com/personal/Larry_Rosler/
lr@hpl.hp.com
------------------------------
Date: 12 Aug 1999 09:09:20 -0700
From: Tom Christiansen <tchrist@mox.perl.com>
Subject: Re: Why use Perl when we've got Python?!
Message-Id: <37b2e3a0@cs.colorado.edu>
[courtesy cc of this posting mailed to cited author]
This isn't the way to learn, you know. You'll only get people
disagreeing with you, and then you'll disagree back, and you'll
never learn anything. Conflict will not bring understanding.
In comp.lang.perl.misc,
Ian Clarke <I.Clarke@strs.co.uk> writes:
:Perl seems to be more of a rebellion against good language design,
Does it seem that way? It certainly isn't. But one thing you have
to remember is that the goal of Perl was *not* create a good design.
It was to create a language that was useful and usable.
:particularly if you include the time it
:takes to debug the code.
This smells very much of a Pascal programmer levelling criticism on a C
programmer because C allows you to have unbounded pointers, type casts,
and unchecked arrays. The complaint was always "but think of how long
it takes you debugging those core dumps!"
:The first thing that hit me with Perl is that different types of
:variables require different special characters to identify them,
No, it's not like BASIC. Perl has only three basic types: scalars,
arrays, and hashes. If I recall, there were dialects of BASIC in which
you distinguished between integer and string values. Perl doesn't
distinguish between the values. Instead, it distinguishes between
whether something is singular or plural in nature.
Consider the following Python code, which illustrates the three types:
a = 10
b = ["alpha", "beta", "gamma"]
c = { "fred" : "wilma", "barney" : "betty" }
To access elements, you use
print b[0]
to get alpha, and yet despite the obvious analogy, you do not use
print c{"fred"}
But rather
print c["fred"]
You use one syntax for initialization, but a complete different one for
access; this is inconsistent. You cannot tell which fundamental kind
of thing a, b, and c is just by looking at it. And it gets better
when you pull in tuples.
d = ("one", "two", "three")
What is that? It's a constant list. You access is using
print d[0]
The differences in access between b, c, and d are hard to see.
And even worse, consider this:
e = ("unity")
Is that a tuple or a single value? It's a single value. If you
want a tuple, you have to use something like
e = ("unity",)
Although of course you can write that as
e = "unity",
And the only difference is that trailing comma there, which is quite hard
to see. The number of pixels occupied by a comma is quite small That's a
very important distinction to be hidden in something that's easy to miss.
Python holds plenty of inconsistencies and surprises waiting
to assault the sensibilities of the Perl programmer. This isn't
a one-way street.
Just for kicks and grins, try firing up
an interactive Python interpreter and using your mouse to cut and
paste those lines. Here there are all together:
a = 10
b = ["alpha", "beta", "gamma"]
c = { "fred" : "wilma", "barney" : "betty" }
print "a is" a
print "b nought is", b[0]
print "c fred is", c["fred"]
Go ahead. Grab it all with your mouse and punch it all it. You can't
do it. You get the mysterious error
File "<stdin>", line 1
a = 10
^
SyntaxError: invalid syntax
Why is that? Oh, because it's an "invalid syntax". Cool message, dude.
What the heck does it mean?
The reason, of course, is because the leading white space changed the
syntax! I cannot believe that the distaste you hold for using in Perl
dollars to specify variables or differently using [] to access an array
but {} to access a hash can possibly compare with the abhorrence that
fills a Perl programmer when he realizes that the number of spaces
at the front of the line is *syntactically significant*.
To the Perl programmer, or the C programmer, or the Java programmer, or
the Pascal programmer, or the Modula programmer, or the Lisp programmer,
or the BASIC programmer, or just about *anyone*, Python seems in this
respect to be more of a rebellion against good language design than
something with a sane design. What happened to the lessons in language
design of the last thirty years? It's been a long time since the number
of spaces mattered so much. Happy languages like FORTRAN come to mind.
Guido has his justifications for this, but they will not sway someone
until they've sufficiently embraced Python that they can overlook this.
My point is that non-Python programmers find Python filled with plenty
of counterintuitive idiosyncrasies.
Why do people recoil in disgust? Some of it is attributble to their
own unique background experience. Some of it is simple resistance
to change. Some of it is nothing more than laziness and avoidance of
the work it would take to learn what's really going on. Some of it is
misunderstanding. Some of it is not thinking past the costs to assay
the benefits consequent to these costs. Some of it is xenophobia--an
unconscious adherence to one's home turf and accent in the face of a
foreign culture and notation, irrespective of merits.
When you hear non-Python programmers complaining of what they see in
Python as stupid or wrong or ugly or backward-seeming, you will be quick
to point out underlying reasons such as those listed above. But I doubt,
however, that you have yourself ever analysed how your *own* adverse
reactions to C or Perl are elicited by the same unconscious prejudices and
bigotries as irritate you when they are applied by others toward Python.
Perhaps you should.
--tom
--
You want it in one line? Does it have to fit in 80 columns? :-)
--Larry Wall in <7349@jpl-devvax.JPL.NASA.GOV>
------------------------------
Date: Thu, 12 Aug 1999 16:52:11 +0100
From: Ian Clarke <I.Clarke@NOSPAM.strs.co.uk>
Subject: Re: Why use Perl when we've got Python?!
Message-Id: <37B2EDAB.22A495@NOSPAM.strs.co.uk>
> This isn't the way to learn, you know. You'll only get people
> disagreeing with you, and then you'll disagree back, and you'll
> never learn anything. Conflict will not bring understanding.
I agree that conflict won't bring understanding, but I was hoping that
people familiar with the language could explain what is good about Perl,
without trying to start a conflict. It is strange that you launch
straight into a nit-picking attack of Python's syntax, seemingly
designed to provoke exactly the type of debate that, by your own
admission, is of no benefit. I will not rise to the bait, except to say
that I initially applied equal amounts of time to trying to learn Perl
and Python, but ended up getting nowhere with Perl, but becomming
increasingly fond of Python. How many people can claim to have started
using Python, and then, of their own free will, migrated to Perl? (And
if you are such a person, could you please tell my why - as this would
be an answer to my initial question!).
> This smells very much of a Pascal programmer levelling criticism on a C
> programmer because C allows you to have unbounded pointers, type casts,
> and unchecked arrays. The complaint was always "but think of how long
> it takes you debugging those core dumps!"
Perhaps, but just because this argument has been used before does not
render it incorrect.
Anyway, while I appreciate the list of pet-gripes that you have with
Python (none of which I ever had a problem with, but maybe that's just
me), you are missing the point of my post. You have replied to my post
as if it were an attack on Perl, which was not my intention. My
intention is to find out what features Perl has that Python doesn't, and
why I might want to use Perl when we have Python?
> When you hear non-Python programmers complaining of what they see in
> Python as stupid or wrong or ugly or backward-seeming, you will be quick
> to point out underlying reasons such as those listed above. But I doubt,
> however, that you have yourself ever analysed how your *own* adverse
> reactions to C or Perl are elicited by the same unconscious prejudices and
> bigotries as irritate you when they are applied by others toward Python.
On the contrary, as you notice I have not bothered to respond to your
criticisms of Python - there are others who could do this much better
than I. Perhaps I did find Perl's syntax unfriendly when I was first to
exposed to it, however I certainly wouldn't go so far as to describe
myself as prejudiced or a bigot! You are clearly familiar with both
languages, so perhaps you could provide me with a useful comparison,
rather than participating in exactly the kind of nit-picking that you
seem to dislike.
Ian.
------------------------------
Date: Thu, 12 Aug 1999 16:03:30 GMT
From: jdporter@min.net (John Porter)
Subject: Re: Why use Perl when we've got Python?!
Message-Id: <slrn7r5s2h.ggv.jdporter@min.net>
In article <37B28649.9C7F0C1E@NOSPAM.strs.co.uk>, Ian Clarke wrote:
>
>I am not so sure that Perl is "quicker" than Python.
Well clearly, since you don't know Perl, you're really not qualified
to make this kind of judgement.
>it seems that Python's more
>transparent syntax would make it easier to debug, and thus in the long
>run, Python may be quicker.
Transparent syntax? Unfortunately for all of us, there is much more
to a language than its syntax. Take Lisp, for example. No language
has a simpler, more "transparent" syntax than Lisp. Yet readability
is (*cough*) not one of its strong points.
>> As far as I can see ...
>> Python was written just for the sake of writing yet another nice,
>> elegant OO language, that has a much nicer and easier syntax than C++ or
>> even Java.
Not sure what "nicer" means; but the syntax of Python is nothing
if not bizarre, at least from the POV of someone who is used to
C/C++/Java/Pascal/Ada/Basic/Perl/Smalltalk/Eiffel/Lisp/....
>There was a need for an interpreted scripting
>language, which allowed the development of large scalable software -
>Guido felt that Perl did not fit this bill, and I agree.
On what basis? That you are predisposed to agree with Guido?
>Also, while I
>am not sure which came first, Python is hardly the new kid on the block,
>it has been around for a while now.
"New kid" in relation to Perl, which has been around considerably longer.
It was, after all, a prime motivator for Guido...
>Perl seems to be more of a rebellion against good language design,
Seems to you, maybe; but not to me, because "good language design"
is subjective -- much more subjective than we have been brainwashed
to believe by the C.S. establishment for 3 or 4 decades now.
Take a little time to read Perl's creator's thoughts on why he
designed Perl the way he did. I for one can vouche that his approach
has paid off big time in the real world.
>and
>while people claim that this makes it "more efficient" to code in, I
>have yet to see the proof - particularly if you include the time it
>takes to debug the code.
What do you know about how much time it takes to debug Perl code?
I spend 99% percent of my time writing and enhancing Perl code (and
docs), and 1%, if that, fixing bugs in it.
However, I am not in a position to say how well this relates to
Python. I *can* say that it is enormously better than when I was
programming in C and C++.
>The first thing that hit me with Perl is that different types of
>variables require different special characters to identify them, this
>reminds me of Atari Basic of the early 80s,
What, Taint By Assocation? The type indicators are very helpful,
even though they tend to add a little bit of "noise" to the code.
You get used to them quickly.
>and is not a feature we find
>in C. Also, I really don't think that C is the model of what the
>perfect language looks like!
Right. So the fact that type indicators are missing from C is no
knock against Perl. Maybe the opposite.
>So is your advice to everyone who posts a question to a newsgroup "Go
>find out yourself!" or is it just me?
Unfortunately, there is no better way. You could simply believe what
you hear; and that's fine. But if you really want to make your own
informed decision, don't ask Perl fans what they think, because you
won't get an unbiased perspective.
>if someone would only provide me with
>some solid reasons for why I might want to use Perl over Python (other
>than wishy washy "Perl is more efficient to code in" or "I tried Python
>and didn't like it" comments) then I might consider trying Perl.
Maybe market numbers would be meaningful for you.
Consider that there are orders of magnitude more Perl programmers than
Python programmers, Perl programs than Python programs, and Perl jobs
than Python jobs. Despite all the nay-saying from computer-language
elitists, interest in and demand for Perl is surging in the marketplace.
What else could we say that would make a difference to you?
--
John Porter
------------------------------
Date: Thu, 12 Aug 1999 11:00:29 -0500
From: "James Liu" <jyoyoliu@hotmail.com>
Subject: Win32 Perl (newbie)
Message-Id: <P9Cs3.5$1b.238@news.corecomm.net>
I got Oreilly's Learning Perl (Llama book). I'm running Windows 98. what
should I know about how perl runs on windows? please help.
------------------------------
Date: Thu, 12 Aug 1999 15:20:15 GMT
From: "Philip H. Dye" <Philip_Dye@norstanconsult.com>
Subject: Work around for signal handler crashes
Message-Id: <01bee4d5$9ec79700$838ee226@philipd>
Hello all,
After diving deep into the perl code I found the real problem in how the
signal handler setup code. It seems the standard setup code used for other
procedures is being used to setup installed signal handlers. Given that
such code calls malloc() this really isn't kosher. I've worked around the
problem by causing the signals to be deferred until after the malloc() has
completed. This works well enough in my case but such may not always be
the appropriate behavior. And I wonder if any other non-reentrant pieces
of libc might be used by the perl core that should be protected.
I've reported the problem in two different forms using perlbug. I also
later commented that I had a fix, though in retrospect it really is a work
around. I've had no response so far.
Btw, no this does not relate in anyway to the code in the signal handler.
I've demonstrated the problem using the following signal handler at the
perl level:
$SIG{CHLD} = sub { }
I'd be interested in developing a cleaner fix for this if there exists
interest. What puzzles me is why this hasn't been slamming developers
everywhere working with process management.
Have a good day !
Philip
------------------------------
Date: 1 Jul 99 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 1 Jul 99)
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.
To submit articles to comp.lang.perl.misc (and this Digest), send your
article to perl-users@ruby.oce.orst.edu.
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.
The Meta-FAQ, an article containing information about the FAQ, is
available by requesting "send perl-users meta-faq" from
almanac@ruby.oce.orst.edu. The real FAQ, as it appeared last in the
newsgroup, can be retrieved with the request "send perl-users FAQ" from
almanac@ruby.oce.orst.edu. Due to their sizes, neither the Meta-FAQ nor
the FAQ are included in the digest.
The "mini-FAQ", which is an updated version of the Meta-FAQ, is
available by requesting "send perl-users mini-faq" from
almanac@ruby.oce.orst.edu.
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 V9 Issue 482
*************************************
