[12231] in Perl-Users-Digest
Perl-Users Digest, Issue: 5831 Volume: 8
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat May 29 21:07:24 1999
Date: Sat, 29 May 99 18:01:25 -0700
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, 29 May 1999 Volume: 8 Number: 5831
Today's topics:
Re: Perl "constructors" (Abigail)
Re: Perl "constructors" (Abigail)
Re: perl -w, "uninitialized" variables, and the Perl la (Ronald J Kimball)
Perl scripts on Berkeley Unix/Apache? (ValH.)
Re: Question: Opening and closing files. (Larry Rosler)
Re: Y2K infected Perl code <ebohlman@netcom.com>
Re: Y2K infected Perl code (Lane Core Jr.)
Re: Y2K infected Perl code <gellyfish@gellyfish.com>
Re: Y2K infected Perl code (Alastair)
Special: Digest Administrivia (Last modified: 12 Dec 98 (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 29 May 1999 19:56:49 -0500
From: abigail@delanet.com (Abigail)
Subject: Re: Perl "constructors"
Message-Id: <slrn7l13jt.7ub.abigail@alexandra.delanet.com>
Eric The Read (emschwar@rmi.net) wrote on MMLXXXIX September MCMXCIII in
<URL:news:xkfzp2ygvug.fsf@valdemar.col.hp.com>:
{}
{} It's not only that, though. Perl really only has one type of exception:
{} $@. It's not even *possible* for Perl to automatically propogate
{} "uninteresting" exceptions, because there's only one kind. Another
{} annoying thing is that a subroutine can raise an exception, and the
{} caller is not forced to deal with it. This severely limits the
{} usefulness of eval/die as an exception handling mechanism, to my mind.
No, that's a feature. If I call a library function and that function is
supposed to open a file, but dies with a useful error message if it can't,
why should I be forced to deal with it? I can't open the file, the program
hence can't do anything useful, so dieing is fine.
Why the extra work?
Abigail
--
%0=map{reverse+chop,$_}ABC,ACB,BAC,BCA,CAB,CBA;$_=shift().AC;1while+s/(\d+)((.)
(.))/($0=$1-1)?"$0$3$0{$2}1$2$0$0{$2}$4":"$3 => $4\n"/xeg;print#Towers of Hanoi
-----------== Posted via Newsfeeds.Com, Uncensored Usenet News ==----------
http://www.newsfeeds.com The Largest Usenet Servers in the World!
------== Over 73,000 Newsgroups - Including Dedicated Binaries Servers ==-----
------------------------------
Date: 29 May 1999 19:59:13 -0500
From: abigail@delanet.com (Abigail)
Subject: Re: Perl "constructors"
Message-Id: <slrn7l13od.7ub.abigail@alexandra.delanet.com>
Eric The Read (emschwar@rmi.net) wrote on MMXCII September MCMXCIII in
<URL:news:xkfn1yuh2lv.fsf@valdemar.col.hp.com>:
,, kaih=7HPvvhDXw-B@khms.westfalen.de (Kai Henningsen) writes:
,, > emschwar@rmi.net (Eric The Read) wrote on 21.05.99 in <xkfvhdmgjy4.fsf@valdemar.col.hp.com>:
,, >
,, > > And there's *still* no way to automatically die on an uncaught exception.
,, >
,, > Huh? I must not be getting something here. How do you not die on an
,, > uncaught die()? Seems a contradiction to me.
,,
,, #!/usr/bin/perl -w
,,
,, eval { die "ack!"; };
,,
,, print "returning normally\n";
,, exit 0;
,, __END__
,,
,, Since eval is perl's version of try, I'd expect the uncaught die() in
,, there to propogate upward, and cause a die() in the outer program-- if it
,, were really an exception. Since it's not really an exception, it doesn't
,, require a catch (or, in the case of Perl, a "if($@) {...}".
Huh? eval caught the die for you. Just the fact you don't bother to check
whether eval caught an exception or not doesn't change the fact it was
caught.
Abigail
--
perl -MTime::JulianDay -lwe'@r=reverse(M=>(0)x99=>CM=>(0)x399=>D=>(0)x99=>CD=>(
0)x299=>C=>(0)x9=>XC=>(0)x39=>L=>(0)x9=>XL=>(0)x29=>X=>IX=>0=>0=>0=>V=>IV=>0=>0
=>I=>$r=-2449231+gm_julian_day+time);do{until($r<$#r){$_.=$r[$#r];$r-=$#r}for(;
!$r[--$#r];){}}while$r;$,="\x20";print+$_=>September=>MCMXCIII=>()'
-----------== Posted via Newsfeeds.Com, Uncensored Usenet News ==----------
http://www.newsfeeds.com The Largest Usenet Servers in the World!
------== Over 73,000 Newsgroups - Including Dedicated Binaries Servers ==-----
------------------------------
Date: Sat, 29 May 1999 20:07:02 -0400
From: rjk@linguist.dartmouth.edu (Ronald J Kimball)
Subject: Re: perl -w, "uninitialized" variables, and the Perl language spec
Message-Id: <1dsl0kq.1mj669c1i3sjx0N@p112.tc3.state.ma.tiac.com>
John Siracusa <macintsh@cs.bu.edu> wrote:
> Ronald J Kimball <rjk@linguist.dartmouth.edu> wrote:
> > The danger is that the values of your variables were probably left
> > uninitialized by mistake. For example:
>
> My issue is with the concept of "probably." In the situations you
> listed, there's no ambiguity about what will happen with the
> "uninitialized" values. If they really are uninitalized, you'll
> get undef or an empty string.
Here's a closer look at my second example:
#!/usr/local/bin/perl -w
$_ = 'foo';
/(bar)/;
print "$1\n";
__END__
Use of uninitialized value at - line 3.
#!/usr/local/bin/perl -w
$_ = 'foo';
/(foo)/;
print "$1\n";
/(bar)/;
print "$1\n";
__END__
foo
foo
No warning this time, because $1 has a value. But it's the value from
the first match, because the second match failed...
The question is not what will happen (undef will become '' or 0), but
whether that is what should happen. Use of an uninitialized value often
signifies an error.
> Big-brother-ish second-guessing of
> programmer intentions in the hopes of spotting errors is not part
> of The Perl Way, IMO.
Guessing programmer intentions is exactly what Perl is about. That's
what DWIM means.
> Yes, that's why -w is optional, but it's a
> shame that -w is straddled with such a mix of what could probably
> be considered "warning levels."
In a future version of Perl, warning levels will be under the
programmer's control.
> The shenanigans required to make -w completely happy are well
> beyond the scope of "good programming practices," IMO, and venture
> into the land of "serve the machine"-type busywork. I cringe
> every time I see a "# to satisfy -w" comment next to some obscure,
> needlessly complex programming construct*.
Okay, I'll stop commenting them. *grin*
-w enforces good programming practices. Clearly, not reading a variable
before it is written is a good programming practice.
> But the genuinely good
> bits of -w are so compelling that most serious perl programmers
> develop under it anyway. I'd like to see some sort of separation
> within -w in the future. Maybe -w1, -w2, etc. to indicate the
> level of persnicketiness.
Ah, see above. You will. :)
> * See "$foo = ${[split(' ', $goo)]}" in another recent clpm thread.
Uh, that warning is because
$foo = split()
is *deprecated*. If you do ignore that warning, then sooner or later
your code will *stop working*. So you can't blame that on -w.
--
_ / ' _ / - aka -
( /)//)//)(//)/( Ronald J Kimball rjk@linguist.dartmouth.edu
/ http://www.tiac.net/users/chipmunk/
"It's funny 'cause it's true ... and vice versa."
------------------------------
Date: 29 May 1999 17:21:45 PDT
From: vhealey@qwestinternet.net (ValH.)
Subject: Perl scripts on Berkeley Unix/Apache?
Message-Id: <7iq0ap$9k3@chronicle.concentric.net>
Hi Perl Gurus,
I'm a newbie to Perl on Berkeley Unix/Apache and have been given only a few
instructions by my web hosting outfit. I have run Perl scripts on NT, with very
few problems, but this Unix machine baffles me.
The web host says that the scripts should be referenced: /bin/perl, so I make
the following dinky script in Windows Notepad (yes, a text file):
#!/bin/perl
print "Hello, world\n";
I upload this file, using Ascii mode to the cgi-bin and use WS_FTP to Chmod it
755. Then I call it from an HTML file with
<A HREF="http://www.mydomain.com/cgi-bin/hello.pl">Hello world</A>
I have tried several other small scripts, that run under NT, but all fail.
IE 5 says "server error" and Netscape 4.5 says "the server made a boo boo."
Would greatly appreciate comments on this and, if possible, an example script
that actually runs on the Unix/Apache.
tia,
valh.
------------------------------
Date: Sat, 29 May 1999 15:45:23 -0700
From: lr@hpl.hp.com (Larry Rosler)
Subject: Re: Question: Opening and closing files.
Message-Id: <MPG.11ba0dcb9fb5104e989b33@nntp.hpl.hp.com>
In article <slrn7l0m5s.7ub.abigail@alexandra.delanet.com> on 29 May 1999
16:07:28 -0500, Abigail <abigail@delanet.com> says...
> Tony Bowden (tony@blackstar.co.uk) wrote on MMLXVII September MCMXCIII in
> <URL:news:7g9k5d$732$1@nclient3-gui.server.ntli.net>:
> || Abigail <abigail@fnx.com> wrote:
> || > David Cassell (cassell@mail.cor.epa.gov) wrote on MMLXII September
> || > MCMXCIII in <URL:news:37210A44.47C2D26A@mail.cor.epa.gov>:
> ||
> || The 2562nd of September 1993?
>
> Uhm, yes. Is something wrong with that?
Uhm, yes. Because it is the 2062nd of September 1993.
--
(Just Another Larry) Rosler
Hewlett-Packard Company
http://www.hpl.hp.com/personal/Larry_Rosler/
lr@hpl.hp.com
------------------------------
Date: Sat, 29 May 1999 22:12:29 GMT
From: Eric Bohlman <ebohlman@netcom.com>
Subject: Re: Y2K infected Perl code
Message-Id: <ebohlmanFCILou.18D@netcom.com>
Alan J. Flavell <flavell@mail.cern.ch> wrote:
: The Perl community took responsibility for making comprehensive
: documentation available. I take my hat off to them (or would, if I wore
: one). Those who preferred superstition over reading the documentation,
: and thereby created Y2K problems where there were no Y2K problems, must
: accept the responsibility for what they did.
And those who preferred facts over superstition have no special
responsibility to the superstitious coders.
Jocelyn has made it pretty clear that the target audience for most of
her writing is PWPH (People With Pointy Hair). They're known to be more
responsive to FUD than facts. Usenet provides plenty of opportunities to
observe the interesting sociological phenomena that happen when someone
accustomed to a FUD-receptive audience suddenly finds him or herself in
front of a fact-receptive audience (probably the most famous case on
Usenet involved Andrew Milne, a PR writer for the Church of Scientology.
His posting history came to an abrupt end after the Co$ lost a court case
(Spaink, et.al.) in the Netherlands and he posted a press release
claiming the Co$ had won the case).
------------------------------
Date: Sat, 29 May 1999 23:39:50 GMT
From: elcore@sgi.net (Lane Core Jr.)
Subject: Re: Y2K infected Perl code
Message-Id: <37507a9c.109077977@news.sgi.net>
On 28 May 1999 20:49:13 GMT, Stefaan.Eeckels@ecc.lu (Stefaan A
Eeckels) wrote:
>In article <374ed9b7.2337186@news.sgi.net>,
> elcore@sgi.net (Lane Core Jr.) writes:
>> On 28 May 1999 12:04:34 +0100, Jonathan Stowe
>> <gellyfish@gellyfish.com> wrote:
>>
>>>I think that uri's point is that basically if someone is too dumb to have
>>>read and understood the documentation for the localtime function then its
>>>basically tough shit - it is not a problem with Perl its a problem with
>>>the meatware.
>>
>> Yeah, but it's still a problem. :-(
>But most emphatically *not* a Perl problem. If you use your
>Toyota to kill a couple of pedestrians it is *your* problem,
>not Toyota's.
Most emphatically not a COBOL problem then, either. :-^
---------------------------------------------------------------------------
Mr. Lane Core Jr. elcore@sgi.net http://users.sgi.net/~elcore/elc_y2k.htm
---------------------------------------------------------------------------
"More software projects have gone awry for lack of calendar time than for
all other causes combined". Frederick P. Brooks, _The Mythical Man-Month_
------------------------------
Date: 29 May 1999 23:29:31 -0000
From: Jonathan Stowe <gellyfish@gellyfish.com>
Subject: Re: Y2K infected Perl code
Message-Id: <7ipt8r$37t$1@gellyfish.btinternet.com>
In comp.lang.perl.misc finsol@ts.co.nz wrote:
> In article <slrn7kt1us.1d8.M.Ray@carlova.ulcc.ac.uk>,
> M.Ray@ulcc.ac.uk (Malcolm Ray) wrote:
>>
>> Programming should not be done by guesswork.
>
> Yes, we all have opinions on how programming should be done and who
> should be doing it. But thats not going to solve the immediate problem
> of existing code thats wrongly programmed. Is that not more of a concern
> right now? What have you and other Perl developers done about that?
And as has been asked over and over and over and over again what do
*you* propose *we* do about it - shall I tie Matt Wright to a burning
cross on Parliament green with a sign saying 'So Die All Abusers of
Localtime' ? Shall I infiltrate GCHQ and reprogramme one of their famed
robots to find all extent installations of WWWBoard and patch the code ?
Do I need to threaten to kill each Tellytubbie in turn until the Script
Kiddies fix their guestbooks and banner programs. What do you want ? I
live near a large agricultural area - I can probably get the white chickens
if someone else can make enough black candles. What do you want ?
> Will
> all Perl Y2K problems that occur be non-critical?
Hey I thought you were the Y2K guru - you tell us. In the company that
I work for there are Perl applications that are critical to the day to
day functioning of the business - serious stuff - and I can guarantee
that none of those will exhibit any problems come the turn of the year.
How true that is of every company that has a commitment in Perl code
would be a difficult one to call but I would certainly say it is true
for all the Perl programmers that I know or are regular posters here.
After all you have set yourself up as the Y2K guru - you tell us ...
> Does the Perl
> community take no responsibility in ensuring that Perl developers get
> the message that there is a need to check Perl code for Y2K problems?
Again how do you propose that such a thing would be done ?
> Particularly if there is the chance that they have not fully understood
> the usage of localtime.
>
I dont know how more explicit you can be than :
Also, $year is the
number of years since 1900, that is, $year is 123
in year 2023, and not simply the last two digits
of the year.
I'm sure if you felt that could be stated more clearly a patch would
be most gratefully received by the maintainers of the documentation.
/J\
--
Jonathan Stowe <jns@gellyfish.com>
Some of your questions answered:
<URL:http://www.btinternet.com/~gellyfish/resources/wwwfaq.htm>
Hastings: <URL:http://www.newhoo.com/Regional/UK/England/East_Sussex/Hastings>
------------------------------
Date: Sun, 30 May 1999 00:21:56 GMT
From: alastair@calliope.demon.co.uk (Alastair)
Subject: Re: Y2K infected Perl code
Message-Id: <slrn7l14od.5f.alastair@calliope.demon.co.uk>
finsol@ts.co.nz <finsol@ts.co.nz> wrote:
>
>Does the Perl community take no responsibility in ensuring that Perl developers
>get the message that there is a need to check Perl code for Y2K problems?
>Particularly if there is the chance that they have not fully understood
>the usage of localtime.
s/Perl/C/g;
s/Perl/C++/g;
s/Perl/pascal/g;
What do you want the 'Perl community' to do? Except RTFM like in *any* other
programming language? If people can't understand the documentation then they
shouldn't be programmming.
Is the 'Perl community' going to get sued?
You remind me of someome on this newsgroup, ages ago, who was whining about
programming being 'too technical'!
--
Alastair
work : alastair@psoft.co.uk
home : alastair@calliope.demon.co.uk
------------------------------
Date: 12 Dec 98 21:33:47 GMT (Last modified)
From: Perl-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Special: Digest Administrivia (Last modified: 12 Dec 98)
Message-Id: <null>
Administrivia:
Well, after 6 months, here's the answer to the quiz: what do we do about
comp.lang.perl.moderated. Answer: nothing.
]From: Russ Allbery <rra@stanford.edu>
]Date: 21 Sep 1998 19:53:43 -0700
]Subject: comp.lang.perl.moderated available via e-mail
]
]It is possible to subscribe to comp.lang.perl.moderated as a mailing list.
]To do so, send mail to majordomo@eyrie.org with "subscribe clpm" in the
]body. Majordomo will then send you instructions on how to confirm your
]subscription. This is provided as a general service for those people who
]cannot receive the newsgroup for whatever reason or who just prefer to
]receive messages via e-mail.
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". The real FAQ, as it
appeared last in the newsgroup, can be retrieved with the request "send
perl-users FAQ". 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". It appears twice
weekly in the group, but is not distributed in the digest.
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 V8 Issue 5831
**************************************
