[33108] in Perl-Users-Digest
Perl-Users Digest, Issue: 4384 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Mar 5 14:09:19 2015
Date: Thu, 5 Mar 2015 11:09:06 -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 Thu, 5 Mar 2015 Volume: 11 Number: 4384
Today's topics:
Re: function returning a list of the indices of its tru <derykus@gmail.com>
Re: function returning a list of the indices of its tru <derykus@gmail.com>
Re: variable expansion issue <rweikusat@mobileactivedefense.com>
Re: variable expansion issue <gravitalsun@hotmail.foo>
Re: variable expansion issue <rweikusat@mobileactivedefense.com>
Re: variable expansion issue <gravitalsun@hotmail.foo>
Re: variable expansion issue <rweikusat@mobileactivedefense.com>
Re: variable expansion issue <gravitalsun@hotmail.foo>
Re: variable expansion issue <rweikusat@mobileactivedefense.com>
Re: variable expansion issue <jblack@nospam.com>
Re: variable expansion issue <rweikusat@mobileactivedefense.com>
Re: variable expansion issue <m@rtij.nl.invlalid>
Re: variable expansion issue <gravitalsun@hotmail.foo>
Re: variable expansion issue <bauhaus@futureapps.invalid>
Re: variable expansion issue <gravitalsun@hotmail.foo>
Re: variable expansion issue <rweikusat@mobileactivedefense.com>
Re: variable expansion issue <rweikusat@mobileactivedefense.com>
Re: variable expansion issue <m@rtij.nl.invlalid>
Re: variable expansion issue <gravitalsun@hotmail.foo>
Re: variable expansion issue <jurgenex@hotmail.com>
Re: variable expansion issue <rweikusat@mobileactivedefense.com>
Re: variable expansion issue <rweikusat@mobileactivedefense.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 4 Mar 2015 14:30:10 -0800 (PST)
From: "C.DeRykus" <derykus@gmail.com>
Subject: Re: function returning a list of the indices of its true arguments
Message-Id: <2704dc0e-3f33-410b-a646-c6611b5ca2fa@googlegroups.com>
On Thursday, February 26, 2015 at 1:31:58 PM UTC-8, Rainer Weikusat wrote:
> sub trues
> {
> map { $_[$_] ? $_ : () } 0 .. $#_;
> }
>
> I actually needed this for something and found it rather amusing.
Too bad it's still experimental (v5.18+), eg:
perl -E 'while(each @arr){say $_ if $arr[$_]}' 3 "foo" 0 4
0
1
3
--
Charles DeRykus
------------------------------
Date: Wed, 4 Mar 2015 14:32:53 -0800 (PST)
From: "C.DeRykus" <derykus@gmail.com>
Subject: Re: function returning a list of the indices of its true arguments
Message-Id: <dbbb73da-201f-4279-bd39-a84175425a42@googlegroups.com>
On Wednesday, March 4, 2015 at 2:30:18 PM UTC-8, C.DeRykus wrote:
> On Thursday, February 26, 2015 at 1:31:58 PM UTC-8, Rainer Weikusat wrote:
> > sub trues
> > {
> > map { $_[$_] ? $_ : () } 0 .. $#_;
> > }
> >
> > I actually needed this for something and found it rather amusing.
>
> Too bad it's still experimental (v5.18+), eg:
>
> perl -E 'while(each @arr){say $_ if $arr[$_]}' 3 "foo" 0 4
^^^^^ ^^^^^
perl -E 'while(each @ARGV){say $_ if $ARGV[$_]}' 3 "foo" 0 4
------------------------------
Date: Wed, 04 Mar 2015 14:31:52 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: variable expansion issue
Message-Id: <871tl4u947.fsf@doppelsaurus.mobileactivedefense.com>
George Mpouras <gravitalsun@hotmail.foo> writes:
> On 4/3/2015 12:46 μμ, Rainer Weikusat wrote:
>> George Mpouras <gravitalsun@hotmail.foo> writes:
>> That's the same kind of problem we already had here not that long ago:
>> The filesystem (namespace) is a resource shared among all processes
>> running on the machine. This implies that the result of a stat-call
>> represent the state at the time the check was made and are not
>> necessarily still valid at any later time.
>>
>
> this do not apply here.
This does apply here. The code you posted was
say("dir \"$_\" is missing"), next unless -d $_;
chdir $_ || warn "Could not chdir to \"$_\" because \"$!\"\n";
The first line stats the name and continues the loop in case the result
was not "it's a directory". But this doesn't mean $_ will still exist as
a directory by the time the chdir is executed and it also doesn't mean
that $_ wouldn't have existed as a directory at the time the chdir had
been executed had it been executed.
> This is unsafe
>
> stat $file;
> ... if -f _;
>
> This is safe
>
> stat $file;
> ... if -f $file;
There's no qualitative difference between your first and your second
example: In both cases, the Perl code works with possibly stale
information. Not even the time window for "stuff going wrong" is
necessarily smaller for the 2nd case: The perl process could be
preempted because of a higher-priority process becoming runnable after
it returned from the kernel and before it got around to acting based on
the stat result it took with it and not run anymore for the next 2 hours
or so (or a user could suspend it with ^Z and not continue it until a
week later).
'stat and then do something based on the result' is what OO-inclined
persons call "an anti-pattern": Something people are wont to do despite
it's fundamentally broken.
------------------------------
Date: Wed, 04 Mar 2015 20:27:03 +0200
From: George Mpouras <gravitalsun@hotmail.foo>
Subject: Re: variable expansion issue
Message-Id: <md7ipq$2iqb$1@news.ntua.gr>
>>
>> stat $file;
>> ... if -f _;
>>
>> This is safe
>>
>> stat $file;
>> ... if -f $file;
>
> There's no qualitative difference between your first and your second
using the _ pseudo file, operators do not check the real node at file
system, they just return the cached data from the first usage.
------------------------------
Date: Wed, 04 Mar 2015 18:33:25 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: variable expansion issue
Message-Id: <87385ksjd6.fsf@doppelsaurus.mobileactivedefense.com>
George Mpouras <gravitalsun@hotmail.foo> writes:
>>>
>>> stat $file;
>>> ... if -f _;
>>>
>>> This is safe
>>>
>>> stat $file;
>>> ... if -f $file;
>>
>> There's no qualitative difference between your first and your second
[explanation of this]
> using the _ pseudo file, operators do not check the real node at file
> system, they just return the cached data from the first usage.
This doesn't matter, as explained in my previous posting.
------------------------------
Date: Wed, 04 Mar 2015 21:05:21 +0200
From: George Mpouras <gravitalsun@hotmail.foo>
Subject: Re: variable expansion issue
Message-Id: <md7l1l$2pn6$1@news.ntua.gr>
On 4/3/2015 8:33 μμ, Rainer Weikusat wrote:
> George Mpouras <gravitalsun@hotmail.foo> writes:
>>>>
>>>> stat $file;
>>>> ... if -f _;
>>>>
>>>> This is safe
>>>>
>>>> stat $file;
>>>> ... if -f $file;
>>>
>>> There's no qualitative difference between your first and your second
>
> [explanation of this]
>
>> using the _ pseudo file, operators do not check the real node at file
>> system, they just return the cached data from the first usage.
>
> This doesn't matter, as explained in my previous posting.
>
it matters with significance analogue to the passed time from the first
"real" check
------------------------------
Date: Wed, 04 Mar 2015 19:27:09 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: variable expansion issue
Message-Id: <87y4ncr2b6.fsf@doppelsaurus.mobileactivedefense.com>
George Mpouras <gravitalsun@hotmail.foo> writes:
> On 4/3/2015 8:33 μμ, Rainer Weikusat wrote:
>> George Mpouras <gravitalsun@hotmail.foo> writes:
>>>>>
>>>>> stat $file;
>>>>> ... if -f _;
>>>>>
>>>>> This is safe
>>>>>
>>>>> stat $file;
>>>>> ... if -f $file;
>>>>
>>>> There's no qualitative difference between your first and your second
>>
>> [explanation of this]
>>
>>> using the _ pseudo file, operators do not check the real node at file
>>> system, they just return the cached data from the first usage.
>>
>> This doesn't matter, as explained in my previous posting.
>
> it matters with significance analogue to the passed time from the
> first "real" check
The amount of time which has passed in unpredictable (as already
explained) in either case and the only thing which matters is that "time
has passed", ie, that there are two indepdenent operations instead of a
single (atomic) operation.
------------------------------
Date: Wed, 04 Mar 2015 21:48:02 +0200
From: George Mpouras <gravitalsun@hotmail.foo>
Subject: Re: variable expansion issue
Message-Id: <md7nhl$311b$1@news.ntua.gr>
On 4/3/2015 9:27 μμ, Rainer Weikusat wrote:
>
> The amount of time which has passed in unpredictable (as already
> explained) in either case and the only thing which matters is that "time
> has passed", ie, that there are two indepdenent operations instead of a
> single (atomic) operation.
>
this have not to do with personal beliefs it is objective.
if after some time a file time have disappeared the -f _ will return
lies (unsafe but fast) while -f $file will return the truth (safe)
------------------------------
Date: Wed, 04 Mar 2015 20:07:44 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: variable expansion issue
Message-Id: <87twy0r0fj.fsf@doppelsaurus.mobileactivedefense.com>
George Mpouras <gravitalsun@hotmail.foo> writes:
> On 4/3/2015 9:27 μμ, Rainer Weikusat wrote:
>>
>> The amount of time which has passed in unpredictable (as already
>> explained) in either case and the only thing which matters is that "time
>> has passed", ie, that there are two indepdenent operations instead of a
>> single (atomic) operation.
>>
>
> this have not to do with personal beliefs it is objective.
Indeed it is. Your belief is wrong and the objective fact is that an
arbitrary amount of time can pass between any two machine instructions
executed on a CPU because an asynchronous interrupt could occur and
cause the system to execute 'other code' until it again choses to stop
with that. Which includes (but is not restricted to) the two examples
already mentioned:
- higher priority process becoming runnable
- perl processes suspended via 'keyboard control'
And there are quite a few machine instructions between the point where
the kernel examined the directoy entry and the end of the perl pp_stat
function (pp_sys.c) already.
------------------------------
Date: Wed, 4 Mar 2015 14:30:20 -0600
From: John Black <jblack@nospam.com>
Subject: Re: variable expansion issue
Message-Id: <MPG.2f612755d00db29e98981b@news.eternal-september.org>
In article <871tl4u947.fsf@doppelsaurus.mobileactivedefense.com>,
rweikusat@mobileactivedefense.com says...
> 'stat and then do something based on the result' is what OO-inclined
> persons call "an anti-pattern": Something people are wont to do despite
> it's fundamentally broken.
Is there an alternative to the 'broken' anti-pattern?
John Black
------------------------------
Date: Wed, 04 Mar 2015 20:58:05 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: variable expansion issue
Message-Id: <87h9u0qy3m.fsf@doppelsaurus.mobileactivedefense.com>
John Black <jblack@nospam.com> writes:
> rweikusat@mobileactivedefense.com says...
>> 'stat and then do something based on the result' is what OO-inclined
>> persons call "an anti-pattern": Something people are wont to do despite
>> it's fundamentally broken.
>
> Is there an alternative to the 'broken' anti-pattern?
This depends on what you're trying to do. Eg, for the example in
question, just doing the chdir is completely sufficient: It will change
the directory if this was possible or return an error code indicating
why it wasn't[*]. Generally, a file system operation has to be tried in
order to determine if it will succeed.
[*] I've written a couple of 'supposed to be as reliable as possible'
autonomously operating background programs in the past where every
filesystem operation was repeated infinitively with some delay in between
in case the error could conceivably go away over time.
------------------------------
Date: Thu, 5 Mar 2015 13:32:54 +0100
From: Martijn Lievaart <m@rtij.nl.invlalid>
Subject: Re: variable expansion issue
Message-Id: <m0vlsb-s87.ln1@news.rtij.nl>
On Wed, 04 Mar 2015 21:48:02 +0200, George Mpouras wrote:
> On 4/3/2015 9:27 μμ, Rainer Weikusat wrote:
>>
>> The amount of time which has passed in unpredictable (as already
>> explained) in either case and the only thing which matters is that
>> "time has passed", ie, that there are two indepdenent operations
>> instead of a single (atomic) operation.
>>
>>
>
> this have not to do with personal beliefs it is objective.
>
> if after some time a file time have disappeared the -f _ will return
> lies (unsafe but fast) while -f $file will return the truth (safe)
-f $file will return the truth *at that instant*. Using the result may be
slightly safer (but only slightly) than using -f _, but it is still
unsafe. The file may still disappear between the call to -f $file and
acting on the result of that call.
So either solution is unsafe, and the latter only lulls you into a false
sense of security.
That said, there are times when -f is appropriate. But in those cases the
file *should* not change! So if it changes, you are hosed, no matter
which solution.
For instance, I just hacked up this for debugging in a program I am
writing (yes, hacked. Notice the use of cat):
sub getUID {
if (-f 'UID.txt') {
my $txt = `cat UID.txt`;
chomp($txt);
$txt .= "\0"x6;
$txt = substr($txt, 0, 6);
$verbose and say "using UID " . UID2txt($txt);
return $txt;
}
... normal determination of UID
}
Here, if I as the user, remove the UID.txt file between the call to -f an
qx, I get what I deserve. But that is not different from using -f _.
If I needed this to be resilient, I would have just opened the file. if
this succeeds, read the file and use its contents. If ENOENT, proceed
with normal determination of UID. If another error, terminate with
suitable error message (or warn and proceed wit normal determination).
So, sorry, but you are wrong. Both solutions are wrong, and the latter is
not really safer than the first, but may lull you into a false sense of
security and can thus be seen as even more dangerous.
M4
------------------------------
Date: Thu, 05 Mar 2015 15:11:54 +0200
From: George Mpouras <gravitalsun@hotmail.foo>
Subject: Re: variable expansion issue
Message-Id: <md9klr$ei$1@news.ntua.gr>
>
> -f $file will return the truth *at that instant*. Using the result may be
> slightly safer (but only slightly) than using -f _, but it is still
> unsafe. The file may still disappear between the call to -f $file and
> acting on the result of that call.
what make you think what you write is not elementary ?
files can change or deleted ? this is breaking news.
------------------------------
Date: Thu, 05 Mar 2015 14:36:59 +0100
From: "G.B." <bauhaus@futureapps.invalid>
Subject: Re: variable expansion issue
Message-Id: <md9m4c$snj$1@dont-email.me>
On 05.03.15 14:11, George Mpouras wrote:
>>
>> -f $file will return the truth *at that instant*. Using the result may be
>> slightly safer (but only slightly) than using -f _, but it is still
>> unsafe. The file may still disappear between the call to -f $file and
>> acting on the result of that call.
>
> what make you think what you write is not elementary ?
> files can change or deleted ? this is breaking news.
To some, stat is as new as -T, considering the former is being
used optimistically in new programs. Some ignore the issue:
for in any case, "safety" requires a wider scope of
investigation than just looking at a Perl program and assume
*nix things. (Not news either?) People do things not just for
technical reasons, not just because they know some
set of manual pages. Sometimes the motives, technical
or not, are at odds with what should be, from a safety
point of view.
So, pedantically speaking, not only may `cat ...` invoke
some unexpectedly interesting executable (trust issue if
the hack survives…), the entire setup needs investigation,
from the janitor's habits to the firmware in all harddrives.
------------------------------
Date: Thu, 05 Mar 2015 16:26:26 +0200
From: George Mpouras <gravitalsun@hotmail.foo>
Subject: Re: variable expansion issue
Message-Id: <md9p1k$ca8$1@news.ntua.gr>
On 5/3/2015 15:36, G.B. wrote:
> On 05.03.15 14:11, George Mpouras wrote:
>>>
>>> -f $file will return the truth *at that instant*. Using the result
>>> may be
>>> slightly safer (but only slightly) than using -f _, but it is still
>>> unsafe. The file may still disappear between the call to -f $file and
>>> acting on the result of that call.
>>
>> what make you think what you write is not elementary ?
>> files can change or deleted ? this is breaking news.
>
> To some, stat is as new as -T, considering the former is being
> used optimistically in new programs. Some ignore the issue:
> for in any case, "safety" requires a wider scope of
> investigation than just looking at a Perl program and assume
> *nix things. (Not news either?) People do things not just for
> technical reasons, not just because they know some
> set of manual pages. Sometimes the motives, technical
> or not, are at odds with what should be, from a safety
> point of view.
>
> So, pedantically speaking, not only may `cat ...` invoke
> some unexpectedly interesting executable (trust issue if
> the hack survives…), the entire setup needs investigation,
> from the janitor's habits to the firmware in all harddrives.
>
I totally agree
------------------------------
Date: Thu, 05 Mar 2015 15:21:02 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: variable expansion issue
Message-Id: <87ioefmpwh.fsf@doppelsaurus.mobileactivedefense.com>
George Mpouras <gravitalsun@hotmail.foo> writes:
>> -f $file will return the truth *at that instant*. Using the result may be
>> slightly safer (but only slightly) than using -f _, but it is still
>> unsafe. The file may still disappear between the call to -f $file and
>> acting on the result of that call.
>
> what make you think what you write is not elementary ?
> files can change or deleted ? this is breaking news.
That's something you seemed to argue against yesterday.
------------------------------
Date: Thu, 05 Mar 2015 15:26:48 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: variable expansion issue
Message-Id: <87egp3mpmv.fsf@doppelsaurus.mobileactivedefense.com>
Martijn Lievaart <m@rtij.nl.invlalid> writes:
> On Wed, 04 Mar 2015 21:48:02 +0200, George Mpouras wrote:
>> On 4/3/2015 9:27 μμ, Rainer Weikusat wrote:
>>> The amount of time which has passed in unpredictable (as already
>>> explained) in either case and the only thing which matters is that
>>> "time has passed", ie, that there are two indepdenent operations
>>> instead of a single (atomic) operation.
>>
>> this have not to do with personal beliefs it is objective.
>>
>> if after some time a file time have disappeared the -f _ will return
>> lies (unsafe but fast) while -f $file will return the truth (safe)
>
> -f $file will return the truth *at that instant*. Using the result may be
> slightly safer (but only slightly) than using -f _,
It's easier to fool oneself into believing that the result may be more
likely of representing reality when the visible code "looks atomic" but
in case the visible code actually ends up being executed by a virtual
machine, that's obviously nonsense (although a seriously popular piece
of nonsense): Anecdotical information about the past is not useful for
predicting the future, even if vast quantities are amassed and
post-produced using complicated looking formulae in order to give an
appearance of "scientificness": Reality is such that the current state
of the filesystem at any time after the check is unknown and that it is
also unknown how much time really passed between the actual check and
the time the Perl code gets to see the result, let alone act on it.
------------------------------
Date: Thu, 5 Mar 2015 17:26:42 +0100
From: Martijn Lievaart <m@rtij.nl.invlalid>
Subject: Re: variable expansion issue
Message-Id: <2ncmsb-k9b.ln1@news.rtij.nl>
On Thu, 05 Mar 2015 15:11:54 +0200, George Mpouras wrote:
>> -f $file will return the truth *at that instant*. Using the result may
>> be slightly safer (but only slightly) than using -f _, but it is still
>> unsafe. The file may still disappear between the call to -f $file and
>> acting on the result of that call.
>
> what make you think what you write is not elementary ?
> files can change or deleted ? this is breaking news.
Then why did you argue against that? This was about using -d and chdir.
You changed it into using -f _ and -f $file, which is still essentially
the same. Which you implied by posting it.
I'm done with this silly thread, I just hope others do not follow your
broken advice.
M4
------------------------------
Date: Thu, 05 Mar 2015 19:23:19 +0200
From: George Mpouras <gravitalsun@hotmail.foo>
Subject: Re: variable expansion issue
Message-Id: <mda3e8$195m$1@news.ntua.gr>
On 5/3/2015 6:26 μμ, Martijn Lievaart wrote:
>
> I'm done with this silly thread, I just hope others do not follow your
> broken advice.
>
> M4
>
as you like.
but i am not sure you even understant what is my "broken advise"
even when I am saying self proove things like -? node is safer than -? _
I am laso done with this thread
------------------------------
Date: Thu, 05 Mar 2015 09:43:14 -0800
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: variable expansion issue
Message-Id: <j95hfal6o50kub0i847eg1tutsam3kj817@4ax.com>
George Mpouras <gravitalsun@hotmail.foo> wrote:
>>
>> -f $file will return the truth *at that instant*. Using the result may be
>> slightly safer (but only slightly) than using -f _, but it is still
>> unsafe. The file may still disappear between the call to -f $file and
>> acting on the result of that call.
>
>what make you think what you write is not elementary ?
Well, it is elementary. Which makes it even more surprising that you
have been vehemently arguing against it for the past dozen postings.
Or coming to think of it, maybe taht part is not surprising at all.
jue
------------------------------
Date: Thu, 05 Mar 2015 17:46:15 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: variable expansion issue
Message-Id: <87d24nl4m0.fsf@doppelsaurus.mobileactivedefense.com>
George Mpouras <gravitalsun@hotmail.foo> writes:
> On 5/3/2015 6:26 μμ, Martijn Lievaart wrote:
>> I'm done with this silly thread, I just hope others do not follow your
>> broken advice.
>>
>> M4
>>
>
> as you like.
> but i am not sure you even understant what is my "broken advise"
>
> even when I am saying self proove things like -? node is safer than -? _
The problem is that you apparently don't understand that neither
stat('node');
-f _;
nor
-f 'node'
is an atomic operation, ie one whose processing will be completed
entirely after it started without any other process capable of changing
the state of the filesystem while this processing happens. The first is
two perl ops, the second only one but 'a Perl op' is a usually rather
lengthy C function in the perl binary which does a system call somewhere
midstream. And only small part of the code executing as part of the system
call is atomic. The system can stop processing both the op code and a
large part of the system call code at any time because of something it
considers to be more important (eg, as already mentioned twice, an
interrupt caused by a frame coming in from the network which causes a
higher-priority process to become runnable which may keep running for 'a
long time') and not continue with it for an amount of time which can't
be predicted by the Perl code: There's no way telling if the time
between 'kernel determined the result and 'Perl checks it' will be
larger for the first or for the second case. And that's just the
perspective for a single CPU but modern computers usually have more
than one. And even if -f 'node' was atomic, this wouldn't help because
it wouldn't include any code running after the check.
http://en.wikipedia.org/wiki/Time_of_check_to_time_of_use
------------------------------
Date: Thu, 05 Mar 2015 17:51:24 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: variable expansion issue
Message-Id: <878ufbl4df.fsf@doppelsaurus.mobileactivedefense.com>
"G.B." <bauhaus@futureapps.invalid> writes:
> On 05.03.15 14:11, George Mpouras wrote:
>>> -f $file will return the truth *at that instant*. Using the result may be
>>> slightly safer (but only slightly) than using -f _, but it is still
>>> unsafe. The file may still disappear between the call to -f $file and
>>> acting on the result of that call.
>>
>> what make you think what you write is not elementary ?
>> files can change or deleted ? this is breaking news.
>
> To some, stat is as new as -T, considering the former is being
> used optimistically in new programs. Some ignore the issue:
> for in any case, "safety" requires a wider scope of
> investigation than just looking at a Perl program and assume
> *nix things. (Not news either?) People do things not just for
> technical reasons, not just because they know some
> set of manual pages. Sometimes the motives, technical
> or not, are at odds with what should be, from a safety
> point of view.
>
> So, pedantically speaking, not only may `cat ...` invoke
> some unexpectedly interesting executable (trust issue if
> the hack survives…), the entire setup needs investigation,
> from the janitor's habits to the firmware in all harddrives.
You're stopping too early. Ultimatively, everything ends with the yet
unanswered questions "What is the universe and how did it come to be?".
But that's not the least bit practical: Relying on 'unchangedness' of
the filesystem state can often be avoided, there's no need to postpone
that until the origin of matter has been determined.
------------------------------
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 4384
***************************************
