[32580] in Perl-Users-Digest
Perl-Users Digest, Issue: 3852 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Jan 4 18:09:24 2013
Date: Fri, 4 Jan 2013 15:09:08 -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, 4 Jan 2013 Volume: 11 Number: 3852
Today's topics:
Re: Benefits for professional Perl programmers <news@lawshouse.org>
Re: CGI Question <rweikusat@mssgmbh.com>
Re: CGI Question <cwilbur@chromatico.net>
Re: CGI Question <cwilbur@chromatico.net>
Re: CGI Question <hjp-usenet2@hjp.at>
Re: CGI Question <jimsgibson@gmail.com>
Re: CGI Question <edgrsprj@ix.netcom.com>
Re: CGI Question <edgrsprj@ix.netcom.com>
Re: CGI Question <rweikusat@mssgmbh.com>
Re: CGI Question <news@lawshouse.org>
Re: CGI Question <cwilbur@chromatico.net>
Re: Date in CSV/TSV question <kst-u@mib.org>
Re: Date in CSV/TSV question <rweikusat@mssgmbh.com>
Re: DESTROY gotcha <derykus@gmail.com>
Re: DESTROY gotcha <ben@morrow.me.uk>
Re: DESTROY gotcha <rweikusat@mssgmbh.com>
Re: DESTROY gotcha <derykus@gmail.com>
Re: Sample program from Programming Perl (Camel book) n <no@thanks.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 03 Jan 2013 23:22:12 +0000
From: Henry Law <news@lawshouse.org>
Subject: Re: Benefits for professional Perl programmers
Message-Id: <XM6dncWjFLg4j3vNnZ2dnUVZ7vOdnZ2d@giganews.com>
On 02/01/13 15:57, E.D.G. wrote:
> "E.D.G." <edgrsprj@ix.netcom.com> wrote in message
> news:AKmdnasLqqSQkHnNnZ2dnUVZ_hWdnZ2d@earthlink.com...
>
> I now have three highly unique and I feel important Perl language
> based computer programs running.
Is this one of them? http://www.freewebz.com/eq-forecasting/302.zip
I didn't know that you could write FORTRAN in Perl.
--
Henry Law Manchester, England
------------------------------
Date: Wed, 02 Jan 2013 16:31:23 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: CGI Question
Message-Id: <87zk0rwnqc.fsf@sapphire.mobileactivedefense.com>
Scott Bryce <sbryce@scottbryce.com> writes:
> On 1/2/2013 8:25 AM, E.D.G. wrote:
>> There shouldn't be any problems with www ownership.
>
> OK, but the password file should be in a directory outside of the www
> directory, not below it.
I'd like to second that strongly: Unless the server was specifically
configured to prohibit this, having the password file in the WWW tree
very likely means anybody who knows the name of this file get download
it by using a suitable URL, eg, https://your.server.org/passwords.txt.
(and if the OP isn't using HTTPS, he would be very good advised to
start doing so immediately --- nowadays, people access 'the internet'
from their laptops/ smartphones etc while using 'open' WiFi hotspots
in public locations and other people can and do exploit this to
collect authentication information sent in clear).
------------------------------
Date: Wed, 02 Jan 2013 11:18:18 -0500
From: Charlton Wilbur <cwilbur@chromatico.net>
Subject: Re: CGI Question
Message-Id: <87vcbf1rud.fsf@new.chromatico.net>
>>>>> "EDG" == E D G <edgrsprj@ix.netcom.com> writes:
EDG> "Charlton Wilbur" <cwilbur@chromatico.net> wrote in message
EDG> news:874nj038d0.fsf@new.chromatico.net...
>> You are making a colossal mistake.
EDG> I have already made extensive changes to the WWWBoard
EDG> program version that I am planning to use.
If you don't know enough to evaluate the original code and see that it
is riddled with flaws, you don't know enough to improve its security
when you modify it.
The cost of your mistake will be borne not by you but by hundreds of
other people who are spammed or who have to fend off cracking attemps by
people who have trivially cracked your box.
Don't continue in this mistake.
Charlton
--
Charlton Wilbur
cwilbur@chromatico.net
------------------------------
Date: Wed, 02 Jan 2013 11:21:29 -0500
From: Charlton Wilbur <cwilbur@chromatico.net>
Subject: Re: CGI Question
Message-Id: <87obh71rp2.fsf@new.chromatico.net>
>>>>> "HL" == Henry Law <news@lawshouse.org> writes:
HL> Quite so. My theory is that E.D.G. (don't you love those dots)
HL> is actually a highly sophisticated Turing-test bot.
You say Turing; I say Dunning-Kruger. I believe Mr Occam votes with me.
Charlton
--
Charlton Wilbur
cwilbur@chromatico.net
------------------------------
Date: Wed, 2 Jan 2013 23:45:40 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: CGI Question
Message-Id: <slrnke9e4k.a2n.hjp-usenet2@hrunkner.hjp.at>
On 2013-01-01 21:24, Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
> "Peter J. Holzer" <hjp-usenet2@hjp.at> writes:
>> On 2013-01-01 16:21, Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
>>> Scott Bryce <sbryce@scottbryce.com> writes:
>>>>> Also in that directory will be the password file that will have a
>>>>> .txt extension.
>>>>
>>>> Don't do that. Move the password file to a directory above the document
>>>> root where it cannot be accessed via the internet. (The passwords are
>>>> encrypted, aren't they?)
>>>
>>> ... and encrypting them doesn't help.
>>
>> It actually helps rather a lot.
>
> As 'piece of mind' feature possibly
Neither "piece of mind" nor "peace of mind". It is a useful 2nd line of
defense after the attacker has gotten hold of the password file. Of
course it only helps those with reasonably complex passwords. "Rainer1"
won't delay an attacker for long.
> Paraphrasing from Wikipedia:
>
> ,----
>| Password shadowing first appeared in UNIX systems with the development
>| of System V Release 3.2 in 1988 and BSD4.3 Reno in 1990.
> `----
Old news. Not sure why you think you have to bring that up. Scott
already advised to make the password file non-public and I suggested (in
the part you snipped) a way to make the password file completely
unaccessable by the web server. But I still think passwords should not
be stored as plain text.
hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | Sysadmin WSR | Man feilt solange an seinen Text um, bis
| | | hjp@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
------------------------------
Date: Wed, 02 Jan 2013 15:51:48 -0800
From: Jim Gibson <jimsgibson@gmail.com>
Subject: Re: CGI Question
Message-Id: <020120131551484805%jimsgibson@gmail.com>
In article <yc6dnbjRtbupK37NnZ2dnUVZ_omdnZ2d@earthlink.com>, E.D.G.
<edgrsprj@ix.netcom.com> wrote:
> "Charlton Wilbur" <cwilbur@chromatico.net> wrote in message
> news:87zk0s1thw.fsf@new.chromatico.net...
>
> > And it's pretty clear that the "international scientific community"
> > needs to hire a few minimally competent sysadmins, because it's apparent
> > taht the "international scientific community" doesn't have the first
> > clue about network security.
>
> I totally agree that this type of effort should be managed by
> professional computer programmers. And the overall effort is in fact moving
> along at two different levels.
>
> 1. There is this very basic effort that has been discussed here that I
> myself am attempting in part to see what is possible.
>
> 2. I am attempting to convince governments and NGOs etc. that they need to
> get a formal effort organized that would make it possible for scientists
> around the world to do a better job of providing them with important
> technical information in a timely manner and also in a manner that they can
> understand the information.
>
> There are already a number of research groups and other resources
> such as Wikipedia.org on the Internet that are making it possible for
> scientists to compare notes with one another regarding various subjects.
> And they are probably helpful to some extent, especially Wikipedia. But
> they cannot solve the specific problem that I am attempting to deal with
> here. It has too many highly complex issues associated with it for those
> groups to deal with.
>
You might want to consider using a Perl script replacement for WWWBoard
that has been re-written with security in mind:
<http://nms-cgi.sourceforge.net/scripts.shtml>
I have no experience with either script.
--
Jim Gibson
------------------------------
Date: Thu, 3 Jan 2013 14:29:19 -0600
From: "E.D.G." <edgrsprj@ix.netcom.com>
Subject: Re: CGI Question
Message-Id: <gYednbvWzsa2d3jNnZ2dnUVZ_hCdnZ2d@earthlink.com>
"Jim Gibson" <jimsgibson@gmail.com> wrote in message
news:020120131551484805%jimsgibson@gmail.com...
> You might want to consider using a Perl script replacement for WWWBoard
> that has been re-written with security in mind:
>
> <http://nms-cgi.sourceforge.net/scripts.shtml>
Thanks for the comment.
That particular script appears to generate E-mail notes rather than bulletin
board postings. However I plan to ill take a closer look at it. Even if it
does only E-mail work, some of the code might be helpful.
------------------------------
Date: Thu, 3 Jan 2013 14:33:31 -0600
From: "E.D.G." <edgrsprj@ix.netcom.com>
Subject: Re: CGI Question
Message-Id: <FZOdneUqcI6CdnjNnZ2dnUVZ_s6dnZ2d@earthlink.com>
"Rainer Weikusat" <rweikusat@mssgmbh.com> wrote in message
news:87zk0rwnqc.fsf@sapphire.mobileactivedefense.com...
> (and if the OP isn't using HTTPS, he would be very good advised to
> start doing so immediately --- nowadays, people access 'the internet'
Thanks for the suggestion. As I stated in another post, there might be only
a half dozen researchers posting notes to the board. So, I don't think that
their losing track of their passwords will be a problem. But I am planning
to do some checking on https anyway. I do know how it works. But I had not
thought of using it for this application.
------------------------------
Date: Thu, 03 Jan 2013 20:44:20 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: CGI Question
Message-Id: <8738yixahn.fsf@sapphire.mobileactivedefense.com>
"E.D.G." <edgrsprj@ix.netcom.com> writes:
> "Rainer Weikusat" <rweikusat@mssgmbh.com> wrote in message
>> (and if the OP isn't using HTTPS, he would be very good advised to
>> start doing so immediately --- nowadays, people access 'the internet'
>
> Thanks for the suggestion. As I stated in another post, there might
> be only a half dozen researchers posting notes to the board. So, I
> don't think that their losing track of their passwords will be a
> problem.
The problem is that _other people_ might be able to intercept the
traffic and thus, gain access to the passwords. This used to be
more-or-less a non-issue since shared-medium ethernets went out of
use, however, nowadays, it is again an issue because of a new kind of
'shared-medium ethernet' commonly known as WiFi. Especially since
so-called 'open wireless hotspots' provided as a convenience to
customers in public locations are not uncommon.
------------------------------
Date: Thu, 03 Jan 2013 22:42:18 +0000
From: Henry Law <news@lawshouse.org>
Subject: Re: CGI Question
Message-Id: <J-qdnczdi5DXlHvNnZ2dnUVZ8t-dnZ2d@giganews.com>
On 03/01/13 20:29, E.D.G. wrote:
> "Jim Gibson" <jimsgibson@gmail.com> wrote in message
>> You might want to consider using a Perl script replacement for WWWBoard
>> that has been re-written with security in mind:
>>
>> <http://nms-cgi.sourceforge.net/scripts.shtml>
> That particular script appears to generate E-mail notes rather than
> bulletin board postings. However I plan to ill take a closer look at
> it. Even if it does only E-mail work, some of the code might be helpful.
There are fifteen scripts on that page, one of which is WWWBoard, as Jim
suggested. It is a message board, which is what you want.
Do you have a clue?
--
Henry Law Manchester, England
------------------------------
Date: Thu, 03 Jan 2013 17:59:08 -0500
From: Charlton Wilbur <cwilbur@chromatico.net>
Subject: Re: CGI Question
Message-Id: <87zk0pzxdv.fsf@new.chromatico.net>
>>>>> "EDG" == E D G <edgrsprj@ix.netcom.com> writes:
EDG> As I stated in another post, there might be only a half dozen
EDG> researchers posting notes to the board.
As I have pointed out repeatedly: it's not the half dozen people who are
authorized to use this software who are using it legitimately that you
have to worry about. It's the several hundred thousand hackers,
crackers, script kiddies, and wannabe mafiosi who are going to find and
exploit the flaws in your code to make your computer do things you don't
want it to do.
There is a legitimate possibility that within 24 hours of you turning on
this service, that your computer will be compromised and used as a
kiddie porn distribution node.
If you weren't aware that that could happen, let alone knowing how to
prevent it or discover that it's going on and shut it down, you have no
business telling us what you think will or will not be a problem.
Charltobn
--
Charlton Wilbur
cwilbur@chromatico.net
------------------------------
Date: Fri, 04 Jan 2013 13:35:11 -0800
From: Keith Thompson <kst-u@mib.org>
Subject: Re: Date in CSV/TSV question
Message-Id: <lnzk0o4oog.fsf@nuthaus.mib.org>
Henry Law <news@lawshouse.org> writes:
[...]
> You could use Date::Calc, particularly the Decode_Date_EU function; it's
> overkill if what you've described is really all there is, but it saves
> programming. A truly lazy^H^H^H^Hcreative programmer would look for
> something to decode the tab-separated file too; maybe Text::CSV would do
> that? I've only ever used it for comma separated data, (which, er, is
> what it's for).
Yes, quoting "perldoc Text::CSV":
The module accepts either strings or files as input and
can utilize any user-specified characters as delimiters,
separators, and escapes so it is perhaps better called ASV
(anything separated values) rather than just CSV.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
------------------------------
Date: Fri, 04 Jan 2013 21:55:51 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Date in CSV/TSV question
Message-Id: <87d2xk62ag.fsf@sapphire.mobileactivedefense.com>
Henry Law <news@lawshouse.org> writes:
> On 02/01/13 10:22, Dave Saville wrote:
>> On Tue, 1 Jan 2013 23:56:14 UTC, Dr Eberhard Lisse <nospam@lisse.NA>
>> wrote:
>>
>>> I have a Tab Separated File of roughly 1000 likes with the first fields like
>>>
>>> "07 Jan 2011" "TFR"
>>> "05 Jan 2011" "DR"
>>
>> Not clear if the file has the quotes or you are using them to show the
>> fields. Assuming you have extracted the first field then split on
>> space to day month year. Set up an array of month names. Find the
>> index of the given month. Regenerate the field with sprintf. $new =
>> sprintf($year-%2.2d-$day, $index); For simplicity put a dummy month on
>> the front of the list, perl arrays index from 0, so @months = qw(crap
>> Jan Feb ..........
>
> You could use Date::Calc, particularly the Decode_Date_EU function;
> it's overkill if what you've described is really all there is, but it
> saves programming. A truly lazy^H^H^H^Hcreative programmer would look
> for something to decode the tab-separated file too; maybe Text::CSV
> would do that?
Nice example how it 'saves programming':
,----
| #!/usr/bin/perl
| use strict;
| use warnings;
| use 5.010;
|
| use Date::Calc qw( Decode_Date_EU );
| use Text::CSV;
|
| my $csv = Text::CSV->new( { sep_char=>"\t", quote_char=>'"' } )
| or die "Failed to create CSV object: $!\n";
| while ( 1 ) {
| my $row = $csv->getline( \*DATA );
| last unless $row->[0]; # getline returns zero-length arrayref;
| irritating
| my ( $year, $month, $day ) = Decode_Date_EU( $row->[0] );
| die "Bad date" unless $year;
| printf "%04d-%02d-%02d\t%s\n", $year, $month, $day, $row->[1];
| }
`----
That's 14 lines of code. Alternate version without Date::Calc and
Text::CSV
,----
| %months = map { $_, sprintf('%02d', ++$n); } qw(Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec);
|
| while (<>) {
| s/^"(\d+)\s+(\S+)\s+(\d+)"/"$3-$months{$2}-$1"/;
| print;
| }
`----
That's good enough for the problem which was described and it's four
lines of code. "Truly creative", -10 lines of code were saved here
and a comment explaining an 'ugly' workaround for deficiency in the
downloaded code had to be added as well[*],
while (1) {
.
.
last if ... # can't use a proper loop here ...
}
with the help of 170 lines of code downloaded from the
internet. This means this 'creative solution' totals 184 lines of
code.
[*] while ($row = $csv->getline(\*DATA), @$row) { ... }
It can also be argued that the 'truly lazy' programmer (like all truly
lazy people) is mainly interested in avoiding work. Even if someone
thinks he pays him to perform work instead ...
------------------------------
Date: Wed, 2 Jan 2013 10:57:20 -0800 (PST)
From: "C.DeRykus" <derykus@gmail.com>
Subject: Re: DESTROY gotcha
Message-Id: <407d58eb-6e3a-48f9-b1af-2da07996bfa6@googlegroups.com>
On Wednesday, January 2, 2013 4:08:18 AM UTC-8, Rainer Weikusat wrote:
> "C.DeRykus" <derykus@gmail.com> writes:
>
> >> As far as I could determine, this isn't documented anywhere, hence,
>
> [...]
>
>
>
> >> -------------
>
> >>
>
> >> package Boo;
>
> >>
>
> >>
>
> >>
>
> >> sub new
>
> >>
>
> >> {
>
> >>
>
> >> return bless([], $_[0]);
>
> >>
>
> >> }
>
> >>
>
> >>
>
> >>
>
> >> sub DESTROY
>
> >>
>
> >> {
>
> >>
>
> >> $_[2]->the_end_of_the_world_lost();
>
> >>
>
> >> }
>
> >>
>
> >>
>
> >>
>
> >> package main;
>
> >>
>
> >>
>
> >>
>
> >> my $o = Boo->new();
>
> >>
>
> >> $o = undef;
>
> >>
>
> >>
>
> >>
>
> >> print("So we had to continue ...\n");
>
> >>
>
> >> ------------
>
> >> will print 'So we had to continue ...' (this caused me quite some head
>
>
>
> [...]
>
>
>
> > Perl special cases exceptions in DESTROY and so they're
>
> > untrappable. With -w though you'll at least see:
>
> >
>
> > (in cleanup) Can't call method "the_end_of_the_world_lost"
>
> > on an undefined value at ...
>
> >
>
> > Here's some background on the problem (and controversy):
>
> > http://www.perlmonks.org/index.pl?node_id=924488
>
>
>
> That's actually about a somewhat different issue, namely, 'user
>
> exceptions' in destructors, not about fatal execution errors perl
>
> can only detect at runtime (and the behaviour I observed occurred on
>
> 5.10.1). And the main issue here is really that the 'in cleanup'
Hm, the discussion didn't touch on it but perl's
handling of any destructor fatality is the same
eg,
(in cleanup) Illegal division by zero ...
There's at least more explanation in perldiag:
(in cleanup) %s
(W misc) This prefix usually indicates that a
DESTROY() method raised the indicated exception.
...
>
> explanation is the only documentation about this I'm presently aware
>
> of[*].
>
>
>
> [*] Considering that this isn't documented, it is - by definition - a
>
> bug :->.
At least a nasty, poorly documented feature...
--
Charles DeRykus
------------------------------
Date: Thu, 3 Jan 2013 01:20:40 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: DESTROY gotcha
Message-Id: <803fr9-507.ln1@anubis.morrow.me.uk>
Quoth "C.DeRykus" <derykus@gmail.com>:
>
> Hm, the discussion didn't touch on it but perl's
> handling of any destructor fatality is the same
> eg,
>
> (in cleanup) Illegal division by zero ...
>
> There's at least more explanation in perldiag:
>
> (in cleanup) %s
> (W misc) This prefix usually indicates that a
> DESTROY() method raised the indicated exception.
> ...
<snip>
>
> At least a nasty, poorly documented feature...
As of 5.16 this is documented in perlobj, though I don't believe the
fact that PROPAGATE does the same thing is documented anywhere yet.
Previously it was only documented rather obliquely in perlcall, which is
not exactly where ordinary users would be looking.
I agree the feature is unfortunate. Presumably it was added when
DESTROY was introduced (in 5002, I think), as a way of preventing
destructors from interfering with code which wasn't expecting to get
exceptions. Since exception handling in Perl was extremely immature at
the time, it probably seemed like the safest thing to do.
Ben
------------------------------
Date: Thu, 03 Jan 2013 13:44:26 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: DESTROY gotcha
Message-Id: <87hamyxtxh.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth "C.DeRykus" <derykus@gmail.com>:
>>
>> Hm, the discussion didn't touch on it but perl's
>> handling of any destructor fatality is the same
>> eg,
>>
>> (in cleanup) Illegal division by zero ...
>>
>> There's at least more explanation in perldiag:
>>
>> (in cleanup) %s
>> (W misc) This prefix usually indicates that a
>> DESTROY() method raised the indicated exception.
>> ...
> <snip>
>>
>> At least a nasty, poorly documented feature...
>
> As of 5.16 this is documented in perlobj,
Not really (except if the behaviour was changed). The corresponding
text is "If your DESTROY method throws an error, this error will be
ignored." But this is not just about application code running from a
destructor invoking die but about any (AFAIK) otherwise fatal runtime
error occurring while running a DESTROY method.
In my case, this was some 'database serialization' code whose
execution was triggered when an object was removed from this database
after the last reference to it went away when the referencing object
was destroyed[*]. This basically uses Data::Dumper to write the
contents of an anonymous array of objects to a text file. Afterwards,
to counteract anything which might have been done when 'freezing' the
objects, Data::Dumper::Freezer) a 'thaw' method is invoked for all
objects in the anonymous array. Because of an error in some other
code, one of the array elements wasn't an object but undef. The "Can't
call ... on an undefined value" error caused by that was ignored. Some
time later, a new object was added to this database, triggering
another serialization, this time not from 'a cleanup context'. Hence,
the attempt to invoke ->thaw using the undef value introduced earlier
aborted now (this was a part of the events which occured prior to this
program going into a crash - restart - crash - restart loop I had to
infer from the available diagnostic output after the 'visible problem'
was noticed and the corrupted on-disk database removed).
[*] Yes, I'm really doing 'application reference counting' for objects
on top of the perl garbage collection mechanism.
------------------------------
Date: Fri, 4 Jan 2013 07:53:44 -0800 (PST)
From: "C.DeRykus" <derykus@gmail.com>
Subject: Re: DESTROY gotcha
Message-Id: <cb4729eb-0af0-40c7-97f7-97b6b442eab4@googlegroups.com>
On Thursday, January 3, 2013 5:44:26 AM UTC-8, Rainer Weikusat wrote:
> Ben Morrow <ben@morrow.me.uk> writes:
>
> > Quoth "C.DeRykus" <derykus@gmail.com>:
>
> >>
>
> >> Hm, the discussion didn't touch on it but perl's
>
> >> handling of any destructor fatality is the same
>
> >> eg,
>
> >>
>
> >> (in cleanup) Illegal division by zero ...
>
> >>
>
> >> There's at least more explanation in perldiag:
>
> >>
>
> >> (in cleanup) %s
>
> >> (W misc) This prefix usually indicates that a
>
> >> DESTROY() method raised the indicated exception.
>
> >> ...
>
> > <snip>
>
> >>
>
> >> At least a nasty, poorly documented feature...
>
> >
>
> > As of 5.16 this is documented in perlobj,
>
>
>
> Not really (except if the behaviour was changed). The corresponding
>
> text is "If your DESTROY method throws an error, this error will be
>
> ignored." But this is not just about application code running from a
>
> destructor invoking die but about any (AFAIK) otherwise fatal runtime
>
> error occurring while running a DESTROY method.
>
>
Hm, maybe eval and exit on error as a safeguard..?
sub DESTROY
{
return if ${^GLOBAL_PHASE} eq 'DESTRUCT';
eval {
...
$_[2]->the_end_of_the_world_lost();
...
};
print "fatal error in DESTROY: $@" and exit 1 if $@;
}
...
--
Charles DeRykus
------------------------------
Date: Thu, 03 Jan 2013 00:45:25 +0000
From: Stuart Golodetz <no@thanks.com>
Subject: Re: Sample program from Programming Perl (Camel book) not running as expected
Message-Id: <kc2kb5$q51$2@speranza.aioe.org>
On 25/12/2012 01:09, MeV wrote:
> On Monday, December 24, 2012 11:50:50 AM UTC-8, Rainer Weikusat
> wrote:
>> Michael Vilain <vilain@NOspamcop.net> writes:
>>
>>> hiabhijeet@gmail.com wrote:
>>>
>>>> I am trying to execute the following sample program on WINDOWS
>>>> but its not executing as expected. Its only reading the first
>>>> line from the file and displaying it. Its not reading the rest
>>>> of the lines -
>>>>
>>
>>
>>
>> [...]
>>
>>> Check the line endings on the file. I don't know if the Windows
>>> Perl implementation uses "\n" as a line ending as UNIX and MacOS
>>> versions of Perl or "\r\n" for Windows standard.
>>
>> This is supposed to be transparent for files opened in text mode
>> (the default): A WinDOS/2-perl should translate \xd\xa to 'a
>> logical \n' on input and translate this 'logical \n' back to \xd\xa
>> on output except if binmode was used to disable this behaviour.
>>
>>
>>
>> NB: I haven't tested this.
>
> It definitely isn't transparent on MacOS X. If you open a
> Windows-formatted file in MacOS X perl, you get the exact behavior he
> described. That's what twigged me to the problem. If you change the
> file to UNIX line-endings, the problem goes away and perl works as
> expected.
>
> Don't know what editors there are on Windows that support setting or
> changing the line-endings. vi on Unix will tell you if a Windows
> file has ^M line endings. BBEdit and Textwrangler on MacOS supports
> this trivially.
Notepad++ will let you change line endings on Windows, for what it's worth.
- S
------------------------------
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:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#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 3852
***************************************
