[33110] in Perl-Users-Digest
Perl-Users Digest, Issue: 4386 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Mar 10 16:09:20 2015
Date: Tue, 10 Mar 2015 13:09:06 -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 Tue, 10 Mar 2015 Volume: 11 Number: 4386
Today's topics:
Re: d <peter@makholm.net>
Re: d <rweikusat@mobileactivedefense.com>
Re: each ARRAY (was: function returning a list of the i <derykus@gmail.com>
Re: each ARRAY (was: function returning a list of the i <derykus@gmail.com>
Re: each ARRAY (was: function returning a list of the i <derykus@gmail.com>
Re: each ARRAY (was: function returning a list of the i <hjp-usenet3@hjp.at>
Re: Setting hash values - Resolved <No-Spam@deezee.org>
Setting hash values <No-Spam@deezee.org>
Re: Setting hash values <rweikusat@mobileactivedefense.com>
Re: Setting hash values <peter@makholm.net>
Re: Setting hash values <hjp-usenet3@hjp.at>
Re: Setting hash values <gravitalsun@hotmail.foo>
Re: Setting hash values <rweikusat@mobileactivedefense.com>
Re: variable expansion issue <bauhaus@futureapps.invalid>
Re: variable expansion issue <rweikusat@mobileactivedefense.com>
Re: variable expansion issue <bauhaus@futureapps.invalid>
Re: variable expansion issue <rweikusat@mobileactivedefense.com>
Re: variable expansion issue <rweikusat@mobileactivedefense.com>
Re: variable expansion issue <bauhaus@futureapps.invalid>
Re: variable expansion issue <rweikusat@mobileactivedefense.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 09 Mar 2015 10:36:32 +0100
From: Peter Makholm <peter@makholm.net>
Subject: Re: d
Message-Id: <87k2yqecm7.fsf@vps1.hacking.dk>
George Mpouras <gravitalsun@hotmail.foo> writes:
>> That is '$foo = $hashref' means that $foo wil reference *the* *same*
>
> its not hashref its copy of flat values
Sorry, that is not how perl works. In your code $hash1{key} is a hashref
and it is this reference that gets copied by the assignment operator.
In Perl the values stored in arrays and hashes are always scalar
values and the only way you can store a array is to store the reference
to an array (which may or may not be annonymous; it doesn't make a
diferrence).
//Makholm
------------------------------
Date: Mon, 09 Mar 2015 13:35:30 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: d
Message-Id: <87a8zmuwd9.fsf@doppelsaurus.mobileactivedefense.com>
Peter Makholm <peter@makholm.net> writes:
> George Mpouras <gravitalsun@hotmail.foo> writes:
>
>>> That is '$foo = $hashref' means that $foo wil reference *the* *same*
>>
>> its not hashref its copy of flat values
>
> Sorry, that is not how perl works. In your code $hash1{key} is a hashref
> and it is this reference that gets copied by the assignment operator.
It's actually a reference to an array stored in a hash.
------------------------------
Date: Sun, 8 Mar 2015 17:25:36 -0700 (PDT)
From: "C.DeRykus" <derykus@gmail.com>
Subject: Re: each ARRAY (was: function returning a list of the indices of its true arguments)
Message-Id: <d15b39c4-5550-4705-a408-e5b73bc6ad27@googlegroups.com>
On Sunday, March 8, 2015 at 4:31:06 AM UTC-7, Peter J. Holzer wrote:
> On 2015-03-04 22:30, C.DeRykus <derykus@gmail.com> wrote:
> > Too bad it's still experimental (v5.18+), eg:
>
> Is it? Neither the docs of 5.14 nor those of 5.20 mention this aspect as
> experimental (or I can't find it). Are confusing this with autoderef,
> which is indeed - as of 5.20 - experimental?
No, it's been there since 5.14 ... perldoc -f each:
Starting with Perl 5.14, "each" can take a scalar EXPR, which
must hold reference to an unblessed hash or array. The argument
will be dereferenced automatically. This aspect of "each" is
considered highly experimental. The exact behaviour may change
in a future version of Perl.
>
> > while(each @arr){say $_ if $arr[$_]}
>
> This is only marginally more convenient than
>
> for (0 .. $#arr) { say $_ if $arr[$_] }
Hardly worth mentioning, but the latter would be a bit slower too.
>
> Where using each on an array shines is that you can use it to get the
> index and value at once:
>
> while (my ($i, $v) = each @arr) { say $i if $v }
>
> It's not much of an improvement (if any) in this trivial example, and
> you could always replace it with
>
> for my $i (0 .. $#arr) {
> $v = $arr[$i];
> ...
> }
>
> but for some loops it makes a difference in readability and it makes
> hashes and array more similar.
--
Charles DeRykus
------------------------------
Date: Sun, 8 Mar 2015 17:38:46 -0700 (PDT)
From: "C.DeRykus" <derykus@gmail.com>
Subject: Re: each ARRAY (was: function returning a list of the indices of its true arguments)
Message-Id: <22b34007-9a63-4693-8d55-085e6f68dc29@googlegroups.com>
On Sunday, March 8, 2015 at 5:25:43 PM UTC-7, C.DeRykus wrote:
> On Sunday, March 8, 2015 at 4:31:06 AM UTC-7, Peter J. Holzer wrote:
> > On 2015-03-04 22:30, C.DeRykus <derykus@gmail.com> wrote:
> > > Too bad it's still experimental (v5.18+), eg:
> >
> > Is it? Neither the docs of 5.14 nor those of 5.20 mention this aspect as
> > experimental (or I can't find it). Are confusing this with autoderef,
> > which is indeed - as of 5.20 - experimental?
>
>
> No, it's been there since 5.14 ... perldoc -f each:
>
> Starting with Perl 5.14, "each" can take a scalar EXPR, which
> must hold reference to an unblessed hash or array. The argument
> will be dereferenced automatically. This aspect of "each" is
> considered highly experimental. The exact behaviour may change
> in a future version of Perl.
>
>
> >
> > > while(each @arr){say $_ if $arr[$_]}
> >
> > This is only marginally more convenient than
> >
> > for (0 .. $#arr) { say $_ if $arr[$_] }
>
>
> Hardly worth mentioning, but the latter would be a bit slower too.
> ^^^^^^
former
Charles DeRykus
------------------------------
Date: Mon, 9 Mar 2015 21:40:10 -0700 (PDT)
From: "C.DeRykus" <derykus@gmail.com>
Subject: Re: each ARRAY (was: function returning a list of the indices of its true arguments)
Message-Id: <a8311a72-01cf-4ae8-8da9-2b7a0c2d4068@googlegroups.com>
On Monday, March 9, 2015 at 4:56:46 PM UTC-7, Peter J. Holzer wrote:
> On 2015-03-09 00:25, C.DeRykus <derykus@gmail.com> wrote:
> > On Sunday, March 8, 2015 at 4:31:06 AM UTC-7, Peter J. Holzer wrote:
> >> On 2015-03-04 22:30, C.DeRykus <derykus@gmail.com> wrote:
> >> > Too bad it's still experimental (v5.18+), eg:
> >>
> >> Is it? Neither the docs of 5.14 nor those of 5.20 mention this aspect as
> >> experimental (or I can't find it). Are confusing this with autoderef,
> >> which is indeed - as of 5.20 - experimental?
> >
> >
> > No, it's been there since 5.14 ... perldoc -f each:
> >
> > Starting with Perl 5.14, "each" can take a scalar EXPR, which
> > must hold reference to an unblessed hash or array. The argument
> > will be dereferenced automatically. This aspect of "each" is
> > considered highly experimental. The exact behaviour may change
> > in a future version of Perl.
>
> That's the autoderef feature of each I mentioned.
>
> But you weren't using that. You were applying each to an array, not a
> reference to an array. This is not experimental.
>
You're right, I was conflating a new 5.18 feature with the autoderef warning just above it:
"...highly experimental. The exact behaviour may change in a future version of Perl.
while (($key,$value) = each $hashref) { ... }
As of Perl 5.18 you can use a bare "each" in a "while" loop, which will set $_ on every iteration."
--
Charles DeRykus
------------------------------
Date: Tue, 10 Mar 2015 00:56:36 +0100
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: each ARRAY (was: function returning a list of the indices of its true arguments)
Message-Id: <slrnmfscpk.a6p.hjp-usenet3@hrunkner.hjp.at>
On 2015-03-09 00:25, C.DeRykus <derykus@gmail.com> wrote:
> On Sunday, March 8, 2015 at 4:31:06 AM UTC-7, Peter J. Holzer wrote:
>> On 2015-03-04 22:30, C.DeRykus <derykus@gmail.com> wrote:
>> > Too bad it's still experimental (v5.18+), eg:
>>
>> Is it? Neither the docs of 5.14 nor those of 5.20 mention this aspect as
>> experimental (or I can't find it). Are confusing this with autoderef,
>> which is indeed - as of 5.20 - experimental?
>
>
> No, it's been there since 5.14 ... perldoc -f each:
>
> Starting with Perl 5.14, "each" can take a scalar EXPR, which
> must hold reference to an unblessed hash or array. The argument
> will be dereferenced automatically. This aspect of "each" is
> considered highly experimental. The exact behaviour may change
> in a future version of Perl.
That's the autoderef feature of each I mentioned.
But you weren't using that. You were applying each to an array, not a
reference to an array. This is not experimental.
hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | 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: Tue, 10 Mar 2015 18:11:26 +0000 (UTC)
From: "Dave Saville" <No-Spam@deezee.org>
Subject: Re: Setting hash values - Resolved
Message-Id: <fV45K0OBJxbE-pn2-0FohUpc92bwS@paddington.bear.den>
Thanks Guys.
--
Regards
Dave Saville
------------------------------
Date: Tue, 10 Mar 2015 15:54:13 +0000 (UTC)
From: "Dave Saville" <No-Spam@deezee.org>
Subject: Setting hash values
Message-Id: <fV45K0OBJxbE-pn2-W83dMRdfPDbx@paddington.bear.den>
I have a hash that holds some status information. I need to clear/set
all keys to the same value. Is there a better way than:
foreach (keys %hash)
{
$hash{$_} = 1;
}
TIA
--
Regards
Dave Saville
------------------------------
Date: Tue, 10 Mar 2015 16:09:55 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Setting hash values
Message-Id: <87oao0u94c.fsf@doppelsaurus.mobileactivedefense.com>
"Dave Saville" <No-Spam@deezee.org> writes:
> I have a hash that holds some status information. I need to clear/set
> all keys to the same value. Is there a better way than:
>
> foreach (keys %hash)
> {
> $hash{$_} = 1;
> }
@hash{keys(%hash)} = (1) x keys(%hash)
works but I have no idea if you'd consider that 'better'.
------------------------------
Date: Tue, 10 Mar 2015 17:30:49 +0100
From: Peter Makholm <peter@makholm.net>
Subject: Re: Setting hash values
Message-Id: <87fv9cerwm.fsf@vps1.hacking.dk>
"Dave Saville" <No-Spam@deezee.org> writes:
> I have a hash that holds some status information. I need to clear/set
> all keys to the same value. Is there a better way than:
Can you define better?
> foreach (keys %hash)
> {
> $hash{$_} = 1;
> }
I would probably write it as
$hash{$_} = 1 for keys %hash;
Which is the same as yours, just written a bit differently. I would
probably consider each solution equally good depending on the general
perl knowledge of the team having to maintain the code.
Two suggested alternatives could be
%hash = map { $_ => 1 } keys %hash;
@hash{ keys %hash } = (1) x keys %hash;
In your case I would consider my original way better, but for some
variations of the problem a variation of the first alternative could be
my prefered way.
If I found the second alternative during a code review I would probably
think 'show off'. In my opinion it is less readable (and thus
maintainable), but your millage might vary.
//Makholm
------------------------------
Date: Tue, 10 Mar 2015 19:38:40 +0100
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: Setting hash values
Message-Id: <slrnmfuehg.i3r.hjp-usenet3@hrunkner.hjp.at>
On 2015-03-10 16:30, Peter Makholm <peter@makholm.net> wrote:
> "Dave Saville" <No-Spam@deezee.org> writes:
>
>> I have a hash that holds some status information. I need to clear/set
>> all keys to the same value. Is there a better way than:
>
> Can you define better?
>
>> foreach (keys %hash)
>> {
>> $hash{$_} = 1;
>> }
>
> I would probably write it as
>
> $hash{$_} = 1 for keys %hash;
$_ = 1 for values %hash;
I admit that I had to test it - I wasn't sure whether $_ would be an
alias of each value or a copy. So you might consider this "being overly
chummy with the compiler". But I think it is a very clean way to express
the intent.
[Alternatives:
...]
> @hash{ keys %hash } = (1) x keys %hash;
Funnily enough that was the first version I thought of, but I don't like
it:
* it repeats the name of the hash 3 times, where 1 would be sufficient
* it builds 2 potentially large temporary lists for no good reason
So, yes,
> If I found the second alternative during a code review I would probably
> think 'show off'.
that would be my reaction, too. The solution shows the author's
proficiency in Perl, but he isn't using it to make the code cleaner
and/or faster, but instead more obscure and most likely slower.
hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | 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: Tue, 10 Mar 2015 20:57:58 +0200
From: George Mpouras <gravitalsun@hotmail.foo>
Subject: Re: Setting hash values
Message-Id: <mdnerm$19va$1@news.ntua.gr>
On 10/3/2015 5:54 μμ, Dave Saville wrote:
> I have a hash that holds some status information. I need to clear/set
> all keys to the same value. Is there a better way than:
>
> foreach (keys %hash)
> {
> $hash{$_} = 1;
> }
>
> TIA
>
# a method
@hash{keys %hash} = map {'_+_'} keys %hash;
# b method
%hash = map {++$i % 2 ? ($_,'_+_'):()} %hash{keys %hash};
------------------------------
Date: Tue, 10 Mar 2015 19:01:51 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Setting hash values
Message-Id: <87bnk0u15s.fsf@doppelsaurus.mobileactivedefense.com>
"Peter J. Holzer" <hjp-usenet3@hjp.at> writes:
> On 2015-03-10 16:30, Peter Makholm <peter@makholm.net> wrote:
>> "Dave Saville" <No-Spam@deezee.org> writes:
>>
>>> I have a hash that holds some status information. I need to clear/set
>>> all keys to the same value. Is there a better way than:
>>
>> Can you define better?
>>
>>> foreach (keys %hash)
>>> {
>>> $hash{$_} = 1;
>>> }
>>
>> I would probably write it as
>>
>> $hash{$_} = 1 for keys %hash;
>
> $_ = 1 for values %hash;
I looked this up in the documentation but misread the "Note that the
values are not copied" as "Note that the values are copied" ...
[...]
>> @hash{ keys %hash } = (1) x keys %hash;
>
> Funnily enough that was the first version I thought of, but I don't like
> it:
>
> * it repeats the name of the hash 3 times, where 1 would be sufficient
> * it builds 2 potentially large temporary lists for no good reason
>
> So, yes,
>
>> If I found the second alternative during a code review I would probably
>> think 'show off'.
>
> that would be my reaction, too. The solution shows the author's
> proficiency in Perl, but he isn't using it to make the code cleaner
> and/or faster, but instead more obscure and most likely slower.
Hash and array slices have been supported in Perl for a while and that
at least three people immediately thought of using an assignment to a
hash slice in order to do means it cannot be that obscure.
------------------------------
Date: Mon, 09 Mar 2015 13:06:20 +0100
From: "G.B." <bauhaus@futureapps.invalid>
Subject: Re: variable expansion issue
Message-Id: <mdk2ac$m2l$1@dont-email.me>
On 08.03.15 20:32, Rainer Weikusat wrote:
>> How does the solution port to different execution environments
>> (such as those including NFS mounted file systems like VMware)?
>
> I again suggest that you state what you're alluding to/ hinting at.
>
I was referring to this:
> Relying on 'unchangedness' of the filesystem state can
> often be avoided
My understanding of "avoid" was this: We are given a problem
to be solved that has, in its description, a succession of
two operations, either of which involves the filesystem.
It asks to make the first operation establish a necessary
precondition for the second operation to be meaningful,
or even successful. Say, stat in a conditional around another
I/O operation.
(Feasible?)
Now, how can we avoid relying on the filesystem's state not
having changed while also accepting the problem's description?
I don't fully accept the description as it ignores facts:
One filesystem operation cannot reliably secure a second
filesystem operation's success. At least if the filesystem
is typical. Filesystem resources to me are like external shared
variables that cannot be fully controlled by a Perl program,
to create atomic sequences of operations on them, and successfully.
So, while my code typically uses features like yours does,
there just is no solution if I accept the problem description
and do not rely on the filesystem's state not having changed:
If only a stat testing $xyz could ensure the success of
a second operation, then the second operation would be
relying on the first (stat).
------------------------------
Date: Mon, 09 Mar 2015 13:39:30 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: variable expansion issue
Message-Id: <8761aauw6l.fsf@doppelsaurus.mobileactivedefense.com>
"G.B." <bauhaus@futureapps.invalid> writes:
> On 08.03.15 20:32, Rainer Weikusat wrote:
>>> How does the solution port to different execution environments
>>> (such as those including NFS mounted file systems like VMware)?
>>
>> I again suggest that you state what you're alluding to/ hinting at.
>>
>
> I was referring to this:
>
>> Relying on 'unchangedness' of the filesystem state can
>> often be avoided
>
> My understanding of "avoid" was this: We are given a problem
> to be solved that has, in its description, a succession of
> two operations, either of which involves the filesystem.
> It asks to make the first operation establish a necessary
> precondition for the second operation to be meaningful,
> or even successful. Say, stat in a conditional around another
> I/O operation.
Why are you ignoring the example I posted a couple of times? Since it is
impossible to guarantee that the file system doesn't change in between
two operations, the way to avoid 'suprises' caused by such a change is
to make it one operation instead.
------------------------------
Date: Mon, 09 Mar 2015 18:32:14 +0100
From: "G.B." <bauhaus@futureapps.invalid>
Subject: Re: variable expansion issue
Message-Id: <mdklde$8dl$1@dont-email.me>
On 09.03.15 14:39, Rainer Weikusat wrote:
>> I was referring to this:
>>
>>> Relying on 'unchangedness' of the filesystem state can
>>> often be avoided
> Why are you ignoring the example I posted a couple of times? Since it is
> impossible to guarantee that the file system doesn't change in between
> two operations, the way to avoid 'suprises' caused by such a change is
> to make it one operation instead.
Well, I honestly don't see how
unless (mkdir('/tmp/file') || $! == EEXIST) {
die("$!");
}
open($fh, '>', '/tmp/directory');
is one filesystem related operation? I contend that
currently there is no way of turning two I/O operations
into one. All testing like -f ... is really assisting
an optimistic approach based on assumptions. Still,
checking every operation cannot be avoided.
------------------------------
Date: Mon, 09 Mar 2015 17:40:04 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: variable expansion issue
Message-Id: <87fv9edq8b.fsf@doppelsaurus.mobileactivedefense.com>
"G.B." <bauhaus@futureapps.invalid> writes:
> On 09.03.15 14:39, Rainer Weikusat wrote:
>
>>> I was referring to this:
>>>
>>>> Relying on 'unchangedness' of the filesystem state can
>>>> often be avoided
>
>> Why are you ignoring the example I posted a couple of times? Since it is
>> impossible to guarantee that the file system doesn't change in between
>> two operations, the way to avoid 'suprises' caused by such a change is
>> to make it one operation instead.
>
> Well, I honestly don't see how
>
>
> unless (mkdir('/tmp/file') || $! == EEXIST) {
> die("$!");
> }
>
> open($fh, '>', '/tmp/directory');
>
>
> is one filesystem related operation?
That was not the 'example' part and I trust that you're intelligent
enough to know this.
------------------------------
Date: Mon, 09 Mar 2015 17:47:17 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: variable expansion issue
Message-Id: <87bnk2dpwa.fsf@doppelsaurus.mobileactivedefense.com>
Rainer Weikusat <rweikusat@mobileactivedefense.com> writes:
> "G.B." <bauhaus@futureapps.invalid> writes:
>> On 09.03.15 14:39, Rainer Weikusat wrote:
>>
>>>> I was referring to this:
>>>>
>>>>> Relying on 'unchangedness' of the filesystem state can
>>>>> often be avoided
>>
>>> Why are you ignoring the example I posted a couple of times? Since it is
>>> impossible to guarantee that the file system doesn't change in between
>>> two operations, the way to avoid 'suprises' caused by such a change is
>>> to make it one operation instead.
>>
>> Well, I honestly don't see how
>>
>>
>> unless (mkdir('/tmp/file') || $! == EEXIST) {
>> die("$!");
>> }
>>
>> open($fh, '>', '/tmp/directory');
>>
>>
>> is one filesystem related operation?
>
> That was not the 'example' part and I trust that you're intelligent
> enough to know this.
... but it can be turned into one: Similar to
-d($name) and die("$name not a directory!");
chdir($name);
being a bad approach because the return value of the -d communicates
nothing about the state of the filesystem immediately afterwards and
replacing this with just a
chdir($name) or die("That didn't work: $name $!");
one can also envison code a la
-f($dirname) and die("mkdir can't work");
mkdir($dirname);
with all the same problems and the same solution
mkdir($dirname) or die("something went wrong: $dirname $!");
------------------------------
Date: Mon, 09 Mar 2015 19:57:15 +0100
From: "G.B." <bauhaus@futureapps.invalid>
Subject: Re: variable expansion issue
Message-Id: <mdkqcr$u3l$1@dont-email.me>
On 09.03.15 18:47, Rainer Weikusat wrote:
> the same problems and the same solution
>
> mkdir($dirname) or die("something went wrong: $dirname $!");
That's a single file system operation, as opposed to two.
I'll say why I had hoped for something more.
So, first, from a Perl point of view, the above is like a
"solution" that replaces (by way of an exemplifying
triviality)
-f($filename) and -f($filename)
with
-f($filename)
Yes, that solves some "problem", but still, chdir or
mkdir having been successful does not mean the directroy
still exists. They may have gone away "after the ;" just
like you said earlier. I was hoping there might be a way
to have Perl send some code to the OS for carrying out
in a "snapshotting" way. Then, after this code has run,
the filesystem will either be effectively unchanged
if any of the filesystem operation fails. Or, all of the
operations will have been successful.
This way, an atomic sequence of filesystem operations
would have provided for more robust transitions from
one state of the filesystem to another. That helps with
locally consistent, although compound changes of data in
the filesystem.
------------------------------
Date: Mon, 09 Mar 2015 19:05:25 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: variable expansion issue
Message-Id: <871tkydma2.fsf@doppelsaurus.mobileactivedefense.com>
"G.B." <bauhaus@futureapps.invalid> writes:
> On 09.03.15 18:47, Rainer Weikusat wrote:
>> the same problems and the same solution
>>
>> mkdir($dirname) or die("something went wrong: $dirname $!");
>
> That's a single file system operation, as opposed to two.
> I'll say why I had hoped for something more.
>
> So, first, from a Perl point of view, the above is like a
> "solution" that replaces (by way of an exemplifying
> triviality)
>
> -f($filename) and -f($filename)
>
> with
>
> -f($filename)
>
> Yes, that solves some "problem",
No. That's some more nonsense you've just made up.
------------------------------
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 4386
***************************************
