[13887] in Perl-Users-Digest
Perl-Users Digest, Issue: 1297 Volume: 9
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Nov 8 14:33:05 1999
Date: Mon, 8 Nov 1999 11:32:50 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Message-Id: <942089570-v9-i1297@ruby.oce.orst.edu>
Content-Type: text
Perl-Users Digest Mon, 8 Nov 1999 Volume: 9 Number: 1297
Today's topics:
Re: FAQ 7.12: What's a closure? <uri@sysarch.com>
Re: FAQ 7.12: What's a closure? (Ilya Zakharevich)
Re: FAQ 7.12: What's a closure? <skilchen@swissonline.ch>
Re: FAQ 7.12: What's a closure? (Kragen Sitaker)
Re: FAQ 7.12: What's a closure? <rick.delaney@home.com>
Re: FAQ 7.12: What's a closure? (Ilya Zakharevich)
Re: FAQ 7.12: What's a closure? (Kragen Sitaker)
Re: FAQ 7.12: What's a closure? (Ilya Zakharevich)
Re: FAQ 7.12: What's a closure? (Kragen Sitaker)
Re: FAQ 7.12: What's a closure? (Ilya Zakharevich)
Re: FAQ 7.12: What's a closure? <rick.delaney@home.com>
Re: File handle tests with pattern matching to promote <aqumsieh@matrox.com>
Re: File handle tests with pattern matching to promote lee.lindley@bigfoot.com
Re: File handle tests with pattern matching to promote (Alan Curry)
Re: File handle tests with pattern matching to promote lee.lindley@bigfoot.com
File Upload Without Using Modules? <webmaster@mendonet.com>
Re: fork & NT Perl <jweisgram@hotmail.com>
Forum - cookies <mark@mgrocock.freeserve.co.uk>
FTP Slurp util using PERL javabob33@my-deja.com
Re: FTP Slurp util using PERL <gellyfish@gellyfish.com>
ftpserver in perl omida@my-deja.com
Re: ftpserver in perl (Kragen Sitaker)
Digest Administrivia (Last modified: 16 Sep 99) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 05 Nov 1999 12:12:00 -0500
From: Uri Guttman <uri@sysarch.com>
Subject: Re: FAQ 7.12: What's a closure?
Message-Id: <x7g0yk6exr.fsf@home.sysarch.com>
>>>>> "SK" == Samuel Kilchenmann <skilchen@swissonline.ch> writes:
>> sub add_function_generator {
>> return sub { shift + shift };
>> }
SK> I always found that example a little bit strange in a FAQ about
SK> closures. Isn't that a "pathological" case of a closure which
SK> doesn't "close" anything?
it always will return the sum of the values it shifted. so it is a closure.
SK> sub test {
SK> my $closure;
SK> my $value = 1;
SK> $closure = sub { eval '$value'; };
that is not a real closure. a perl closure has to be a my variable or
private value (as above) used in the sub. you have an eval of the name
of the variable. the eval is not executed at the time of the sub
definition, but when the sub is called.
SK> print $closure->();
this executes the eval and $value is 1 in this scope so it works
SK> }
SK> print "outside scope: ";
SK> print $closure->(); # this is line 21
here the eval is executed and $value is undef as it is in the main
scope.
SK> If i change the snippets as follows
SK> Perl:
SK> $closure = sub { eval $variable; };
^^^^^^^^^
did you mean $value there?
that is similar to the shift + shift closure. the eval is meaningless as
the variable's value is just 1 or 2 and that is controlled by the later
assignment to the private $value. the global $variable is not seen in
this case like the eval '$value' was.
well.
uri
--
Uri Guttman --------- uri@sysarch.com ---------- http://www.sysarch.com
SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting
The Perl Books Page ----------- http://www.sysarch.com/cgi-bin/perl_books
The Best Search Engine on the Net ---------- http://www.northernlight.com
------------------------------
Date: 5 Nov 1999 19:33:30 GMT
From: ilya@math.ohio-state.edu (Ilya Zakharevich)
Subject: Re: FAQ 7.12: What's a closure?
Message-Id: <7vvbea$5u3$1@charm.magnus.acs.ohio-state.edu>
[A complimentary Cc of this posting was sent to Uri Guttman
<uri@sysarch.com>],
who wrote in article <x7g0yk6exr.fsf@home.sysarch.com>:
> >> sub add_function_generator {
> >> return sub { shift + shift };
> >> }
>
> SK> I always found that example a little bit strange in a FAQ about
> SK> closures. Isn't that a "pathological" case of a closure which
> SK> doesn't "close" anything?
>
> it always will return the sum of the values it shifted. so it is a closure.
a) First of all, it does not compile, so it is not a closure ;-).
b) Second,
> perl -MDevel::Peek -wle "Dump sub { shift() + shift }"
SV = RV(0x7a404) at 0x3185c
REFCNT = 1
FLAGS = (TEMP,ROK)
RV = 0x40350
SV = PVCV(0x3c1c0) at 0x40350
REFCNT = 2
FLAGS = (PADBUSY,PADMY,ANON)
IV = 0
NV = 0
COMP_STASH = 0x31874 "main"
START = 0x3e240 ===> 2232
ROOT = 0x42ea0
XSUB = 0x0
XSUBANY = 0
GVGV::GV = 0x40338 "main" :: "__ANON__"
FILEGV = 0x31a48 "_<-e"
DEPTH = 0
FLAGS = 0x4
PADLIST = 0x40314
OUTSIDE = 0x31a60 (MAIN)
As one can momentarily see, it is not a closure (CLONE/CLONED flags).
Just an anonymous sub.
Ilya
------------------------------
Date: Fri, 05 Nov 1999 22:40:49 GMT
From: Samuel Kilchenmann <skilchen@swissonline.ch>
Subject: Re: FAQ 7.12: What's a closure?
Message-Id: <7vvmdi$d2e$1@nnrp1.deja.com>
In article <x7g0yk6exr.fsf@home.sysarch.com>,
Uri Guttman <uri@sysarch.com> wrote:
> >>>>> "SK" == Samuel Kilchenmann <skilchen@swissonline.ch> writes:
>
> >> sub add_function_generator {
> >> return sub { shift + shift };
> >> }
>
> SK> I always found that example a little bit strange in a FAQ about
> SK> closures. Isn't that a "pathological" case of a closure which
> SK> doesn't "close" anything?
>
> it always will return the sum of the values it shifted. so it is a >
> closure.
No, the description in perlfaq7 of what the function does is correct.
It returns a ref to a function taking two arguments and returning the
sum of them. It doesn't close anything.
> SK> sub test {
> SK> my $closure;
> SK> my $value = 1;
> SK> $closure = sub { eval '$value'; };
>
> that is not a real closure. a perl closure has to be a my variable or
> private value (as above) used in the sub. you have an eval of the name
> of the variable. the eval is not executed at the time of the sub
> definition, but when the sub is called.
>
Although i indeed missed that point some days ago, i am well aware of
that fact now (thanks to the remainder by Kragen Sitaker). But $closure
indeed "closes" the $value from the enclosing block. If it didn't then
there would be no reason why it should not pick up the value of the
package variable $value, if called outside of the scope in which
$closure was defined. (Btw. thats exactly what happens if you comment
out the "my $variable = 1;" line in my example.) As long as the
closure is called in the enclosing scope, it nows how to get at the
value of $variable eval'ing '$variable'. But outside the scope in which
the closure was defined it still "nows" that it had "closed" the
$variable but it is no longer able to get at its value. If it
hadn't "closed" the nearest $value it would pick up the value of the
package variable $value when evaling '$value'.
>
> SK> print "outside scope: ";
> SK> print $closure->(); # this is line 21
>
> here the eval is executed and $value is undef as it is in the main
> scope.
>
No, there is a $value in the main scope, but strangely enough the
closure "remembers" that "she" is looking for a lexical variable in the
scope where "she" was created but "she" is unable to get at its value.
> SK> If i change the snippets as follows
> SK> Perl:
> SK> $closure = sub { eval $variable; };
> ^^^^^^^^^
> did you mean $value there?
>
Yes, sorry for that confusion.
> that is similar to the shift + shift closure.
> the eval is meaningless as the variable's value
> is just 1 or 2 and that is controlled by the later
> assignment to the private $value.
Although the eval is indeed meaningless here (it would be less
meaningless, if $value's value had been a string representation of a
more sophisticated Perl expression) the situation is nonetheless not
similar to the shift+shift closure. As you correctly mentioned, the
eval is not executed until the closure is called, exactly the same is
true for the shifts. But in my example there is $value which
was "closed", but in the shift+shift closure there is no reference to
any "closed" value.
Anyway: thank you very much for the followup. And sorry, if my blabla
is mostly ununderstandable. This issue is just a little bit too
complicated for my ability to express things in english (and my
understanding of Perl), so i am giving up on this one.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Sat, 06 Nov 1999 22:08:14 GMT
From: kragen@dnaco.net (Kragen Sitaker)
Subject: Re: FAQ 7.12: What's a closure?
Message-Id: <iF1V3.48885$23.1860531@typ11.nn.bcandid.com>
In article <x7g0yk6exr.fsf@home.sysarch.com>,
Uri Guttman <uri@sysarch.com> wrote:
>>>>>> "SK" == Samuel Kilchenmann <skilchen@swissonline.ch> writes:
> >> return sub { shift + shift };
>
> SK> I always found that example a little bit strange in a FAQ about
> SK> closures. Isn't that a "pathological" case of a closure which
> SK> doesn't "close" anything?
>
>it always will return the sum of the values it shifted. so it is a closure.
Right, but it doesn't access anything from the environment it was closed in.
sub afg { return sub { shift + shift } } says (as Ilya pointed out)
Warning: Use of "shift" without parens is ambiguous at - line 1.
Type of arg 1 to shift must be array (not shift) at - line 1, near "shift }"
Execution of - aborted due to compilation errors.
sub afg { return sub { shift() + shift } } my $x=afg(); print $x->(1,1), "\n";
prints
2
> SK> sub test {
> SK> my $closure;
> SK> my $value = 1;
> SK> $closure = sub { eval '$value'; };
>
>that is not a real closure. a perl closure has to be a my variable or
>private value (as above) used in the sub. you have an eval of the name
>of the variable. the eval is not executed at the time of the sub
>definition, but when the sub is called.
Right. So let's try this:
#!/usr/bin/perl -w
use strict;
use vars '$foo';
$foo = 37;
sub test1 { my $foo = 108; return sub { eval '$foo' } }
sub test2 { return sub { eval '$foo' } }
print test1()->(), ' ', test2()->(), "\n";
This outputs:
Use of uninitialized value at - line 7.
37
These should be *identical*! But the first one returns undef, and the
second one works as expected, accessing the package variable.
Here's the other modification Samuel mentioned:
#!/usr/bin/perl -w
use strict;
use vars '$foo';
$foo = 37;
my $string = '$foo';
sub test1 { my $foo = 108; return sub { eval $string } }
sub test2 { return sub { eval $string } }
print test1()->(), ' ', test2()->(), "\n";
This produces identical results. How bad does this get?
#!/usr/bin/perl -w
use strict;
use vars '$foo';
$foo = 37;
sub test1 { my $foo = 108; return sub { eval $_[0] } }
sub test2 { return sub { eval $_[0] } }
print test1()->('$foo'), ' ', test2()->('$foo'), "\n";
This *still* produces identical results.
IMHO, it is reasonable for test1's result to return 108 or 37, but not
undef.
--
<kragen@pobox.com> Kragen Sitaker <http://www.pobox.com/~kragen/>
Tue Nov 02 1999
6 days until the Internet stock bubble bursts on Monday, 1999-11-08.
<URL:http://www.pobox.com/~kragen/bubble.html>
------------------------------
Date: Sun, 07 Nov 1999 19:27:06 GMT
From: Rick Delaney <rick.delaney@home.com>
Subject: Re: FAQ 7.12: What's a closure?
Message-Id: <3825D2A1.CB01A626@home.com>
[posted & mailed]
Kragen Sitaker wrote:
>
> #!/usr/bin/perl -w
> use strict;
> use vars '$foo';
> $foo = 37;
> sub test1 { my $foo = 108; return sub { eval $_[0] } }
> sub test2 { return sub { eval $_[0] } }
> print test1()->('$foo'), ' ', test2()->('$foo'), "\n";
>
> This *still* produces identical results.
>
> IMHO, it is reasonable for test1's result to return 108 or 37, but not
> undef.
IMHO it is reasonable for test1's result to return 37 only. This is
obviously a bug, possibly the same as the one posted by Ala Qumsieh
earlier this week.
--
Rick Delaney
rick.delaney@home.com
------------------------------
Date: 7 Nov 1999 21:21:49 GMT
From: ilya@math.ohio-state.edu (Ilya Zakharevich)
Subject: Re: FAQ 7.12: What's a closure?
Message-Id: <804qhd$ejt$1@charm.magnus.acs.ohio-state.edu>
[A complimentary Cc of this posting was sent to Rick Delaney
<rick.delaney@home.com>],
who wrote in article <3825D2A1.CB01A626@home.com>:
> > #!/usr/bin/perl -w
> > use strict;
> > use vars '$foo';
> > $foo = 37;
> > sub test1 { my $foo = 108; return sub { eval $_[0] } }
> > sub test2 { return sub { eval $_[0] } }
> > print test1()->('$foo'), ' ', test2()->('$foo'), "\n";
> >
> > This *still* produces identical results.
> >
> > IMHO, it is reasonable for test1's result to return 108 or 37, but not
> > undef.
>
> IMHO it is reasonable for test1's result to return 37 only.
Nope. It is reasonable for test1 to return either 108 or undef,
depending on where it was called from. As it does.
I see no bug.
Ilya
P.S. See the *scope* where eval '' is executed? This *scope* has a
lexical $foo inherited from the enclosing lexical scope. Thus
the call test1()->('$foo') will return this lexical $foo.
However, since the "subsubroutine" of test1 is not a closure, it
does not *preserve* the reference to this $foo. Hence the
refcount of $foo decreases when test1 returns, which effectively
makes $foo stale=undefined.
Putting $foo into the subsubroutine will make it a closure, thus
$foo will be 108 during the call.
------------------------------
Date: Sun, 07 Nov 1999 21:48:28 GMT
From: kragen@dnaco.net (Kragen Sitaker)
Subject: Re: FAQ 7.12: What's a closure?
Message-Id: <MsmV3.54370$23.2029388@typ11.nn.bcandid.com>
In article <804qhd$ejt$1@charm.magnus.acs.ohio-state.edu>,
Ilya Zakharevich <ilya@math.ohio-state.edu> wrote:
>P.S. See the *scope* where eval '' is executed? This *scope* has a
> lexical $foo inherited from the enclosing lexical scope. Thus
> the call test1()->('$foo') will return this lexical $foo.
>
> However, since the "subsubroutine" of test1 is not a closure, it
> does not *preserve* the reference to this $foo. Hence the
> refcount of $foo decreases when test1 returns, which effectively
> makes $foo stale=undefined.
>
> Putting $foo into the subsubroutine will make it a closure, thus
> $foo will be 108 during the call.
Thank you for the explanation of what happens. I now understand how it
is that test1's return value returns undef -- someone else had
explained it, but I think your explanation is clearer. I still think
test1 *should* return something different. But that's a topic for p5p.
--
<kragen@pobox.com> Kragen Sitaker <http://www.pobox.com/~kragen/>
Tue Nov 02 1999
6 days until the Internet stock bubble bursts on Monday, 1999-11-08.
<URL:http://www.pobox.com/~kragen/bubble.html>
------------------------------
Date: 7 Nov 1999 22:51:47 GMT
From: ilya@math.ohio-state.edu (Ilya Zakharevich)
Subject: Re: FAQ 7.12: What's a closure?
Message-Id: <804vq3$f84$1@charm.magnus.acs.ohio-state.edu>
[A complimentary Cc of this posting was sent to Kragen Sitaker
<kragen@dnaco.net>],
who wrote in article <MsmV3.54370$23.2029388@typ11.nn.bcandid.com>:
> In article <804qhd$ejt$1@charm.magnus.acs.ohio-state.edu>,
> Ilya Zakharevich <ilya@math.ohio-state.edu> wrote:
$foo = 1; $^W = 1;
sub test1 {my $foo = 2; return sub { eval shift } }
print test1()->('$foo');
> >P.S. See the *scope* where eval '' is executed? This *scope* has a
> > lexical $foo inherited from the enclosing lexical scope. Thus
> > the call test1()->('$foo') will return this lexical $foo.
> >
> > However, since the "subsubroutine" of test1 is not a closure, it
> > does not *preserve* the reference to this $foo. Hence the
> > refcount of $foo decreases when test1 returns, which effectively
> > makes $foo stale=undefined.
> >
> > Putting $foo into the subsubroutine will make it a closure, thus
> > $foo will be 108 during the call.
>
> Thank you for the explanation of what happens. I now understand how it
> is that test1's return value returns undef -- someone else had
> explained it, but I think your explanation is clearer. I still think
> test1 *should* return something different. But that's a topic for p5p.
This cannot be done. But I Cc perlbug:
Here is what *can* be done. When evalling, internal (sub {}) scope
does not contain $foo. So the search for $foo continues up-scope.
Scope of test1 is tested, and $foo is found there.
POSSIBLE ENHANCEMENT: given that the lexical was found inside eval '',
that the compilation of test1 is completed already, and that test1 is
not active any more, give a warning
Access to stale lexical of enclosing scope from eval ''
[Variant: additionally to testing that test1 is not active, test that
"the `active' position inside test1" is in the scope of $foo.]
Ilya
------------------------------
Date: Sun, 07 Nov 1999 23:46:21 GMT
From: kragen@dnaco.net (Kragen Sitaker)
Subject: Re: FAQ 7.12: What's a closure?
Message-Id: <hboV3.54792$23.2048264@typ11.nn.bcandid.com>
In article <804vq3$f84$1@charm.magnus.acs.ohio-state.edu>,
Ilya Zakharevich <ilya@math.ohio-state.edu> wrote:
>Here is what *can* be done. When evalling, internal (sub {}) scope
>does not contain $foo. So the search for $foo continues up-scope.
>Scope of test1 is tested, and $foo is found there.
>
>POSSIBLE ENHANCEMENT: given that the lexical was found inside eval '',
>that the compilation of test1 is completed already, and that test1 is
>not active any more, give a warning
>
> Access to stale lexical of enclosing scope from eval ''
If this is possible, why can't we just continue looking upscope for a
non-stale lexical, or at least look for a package variable? It is
broken for a no-longer-existing binding to hide existing bindings.
--
<kragen@pobox.com> Kragen Sitaker <http://www.pobox.com/~kragen/>
Tue Nov 02 1999
6 days until the Internet stock bubble bursts on Monday, 1999-11-08.
<URL:http://www.pobox.com/~kragen/bubble.html>
------------------------------
Date: 8 Nov 1999 03:40:10 GMT
From: ilya@math.ohio-state.edu (Ilya Zakharevich)
Subject: Re: FAQ 7.12: What's a closure?
Message-Id: <805gmq$pco$1@charm.magnus.acs.ohio-state.edu>
[A complimentary Cc of this posting was sent to Kragen Sitaker
<kragen@dnaco.net>],
who wrote in article <hboV3.54792$23.2048264@typ11.nn.bcandid.com>:
> If this is possible, why can't we just continue looking upscope for a
> non-stale lexical, or at least look for a package variable? It is
> broken for a no-longer-existing binding to hide existing bindings.
Gosh! We are discussing *lexicals* here!
Lexical name resolution should not depend on details of runtime history.
Ilya
------------------------------
Date: Mon, 08 Nov 1999 14:14:07 GMT
From: Rick Delaney <rick.delaney@home.com>
Subject: Re: FAQ 7.12: What's a closure?
Message-Id: <3826DAC5.958C31EF@home.com>
[posted & mailed]
Ilya Zakharevich wrote:
>
> [A complimentary Cc of this posting was sent to Rick Delaney
> <rick.delaney@home.com>],
> who wrote in article <3825D2A1.CB01A626@home.com>:
> > > #!/usr/bin/perl -w
> > > use strict;
> > > use vars '$foo';
> > > $foo = 37;
> > > sub test1 { my $foo = 108; return sub { eval $_[0] } }
> > > sub test2 { return sub { eval $_[0] } }
> > > print test1()->('$foo'), ' ', test2()->('$foo'), "\n";
> > >
> > > This *still* produces identical results.
> > >
> > > IMHO, it is reasonable for test1's result to return 108 or 37, but not
> > > undef.
> >
> > IMHO it is reasonable for test1's result to return 37 only.
>
> Nope. It is reasonable for test1 to return either 108 or undef,
> depending on where it was called from. As it does.
Of course I meant in the code above. I can see the situations where it
would return 108. I'm still wrong though...
> I see no bug.
>
> Ilya
>
> P.S. See the *scope* where eval '' is executed? This *scope* has a
> lexical $foo inherited from the enclosing lexical scope. Thus
> the call test1()->('$foo') will return this lexical $foo.
>
> However, since the "subsubroutine" of test1 is not a closure, it
> does not *preserve* the reference to this $foo. Hence the
> refcount of $foo decreases when test1 returns, which effectively
> makes $foo stale=undefined.
Thank you, this makes it clear. I didn't realize that the lexical $foo
would still have some sort of existance when it had no refcount. But
since it *is* a lexical, I guess it makes more sense for eval to see the
names in its scope, even if there are no longer references with those
names.
Still, I like the idea of a warning when there is an attempt at
accessing this "stale" $foo.
--
Rick Delaney
rick.delaney@home.com
------------------------------
Date: Fri, 5 Nov 1999 11:31:51 -0500
From: Ala Qumsieh <aqumsieh@matrox.com>
Subject: Re: File handle tests with pattern matching to promote early termination of a file read
Message-Id: <x3yhfj0sxvs.fsf@tigre.matrox.com>
lee.lindley@bigfoot.com writes:
> objectively. I will call anybody liar who says that they have
> actually been *burned* by this bug on
>
> while (<>)
>
> The possibility of it occuring has assumed the proportions of an
> urban legend.
I don't have an old enough version of Perl handy, but there is a
possible scenario where you can get burnt because of this. I am able
to reproduce this on 5.004, but only if I change:
while (<>)
to
while ($x = <>)
The reason is that the first does an implicit defined() test on $_.
% perl5.004_04 -wl
local $/ = '0';
while ($x = <DATA>) {
print ">>$x<<\n";
}
__DATA__
0 00000
This prints out:
Value of <HANDLE> construct can be "0"; test with defined() at - line 65535.
On 5.005_03:
% perl -wl
local $/ = '0';
while ($x = <DATA>) {
print ">>$x<<\n";
}
__DATA__
0 00000
prints:
>>0<<
>> 0<<
>>0<<
>>0<<
>>0<<
>>0<<
--Ala
------------------------------
Date: 5 Nov 1999 18:26:47 GMT
From: lee.lindley@bigfoot.com
Subject: Re: File handle tests with pattern matching to promote early termination of a file read
Message-Id: <7vv7h7$mtp$1@rguxd.viasystems.com>
Abigail <abigail@delanet.com> wrote:
:>lee.lindley@bigfoot.com (lee.lindley@bigfoot.com) wrote on MMCCLVII
:>September MCMXCIII in <URL:news:7vtkrd$50v$1@rguxd.viasystems.com>:
[snip]
:>From perlop:
:> Anyway, the following lines are equivalent to each other:
:> while (defined($_ = <STDIN>)) { print; }
:> while ($_ = <STDIN>) { print; }
:> while (<STDIN>) { print; }
:> for (;<STDIN>;) { print; }
:> print while defined($_ = <STDIN>);
:> print while ($_ = <STDIN>);
:> print while <STDIN>;
:> and this also behaves similarly, but avoids the use of $_:
:> while (my $line = <STDIN>) { print $line }
Oops. And now I find references to that behavior in perlsyn too.
I stopped reading too soon.
mea culpa.
:>__
:>__ Nevertheless, I stand by my assertion that this particular rare case
:>__ is one of those things that has wasted far more time by all of the
:>__ people involved than it could possibly merit if you look at it
:>__ objectively. I will call anybody liar who says that they have
:>__ actually been *burned* by this bug on
:>__
:>__ while (<>)
:>__
:>__ The possibility of it occuring has assumed the proportions of an
:>__ urban legend.
:>It has been pointed out recently that in MacOS, there is *no* trailing
:>newline af the last line, and that while perl (or the C library) adds the
:>newline for you - that would not happen if you parse a MacOS generated
:>file on Unix.
Yes, I saw that post. And yet has anyone actually ever been burned
by this?
It is still a hypothetical problem of such low probability...
Now that my eyes have been opened I find the silly concept discussed
in disproportionate detail in both perlop and perlsyn. I apologize
for covering ground that has obviously already been covered many
times before.
--
// Lee.Lindley /// I used to think that being right was everything.
// @bigfoot.com /// Then I matured into the realization that getting
//////////////////// along was more important. Except on usenet.
------------------------------
Date: Fri, 05 Nov 1999 19:19:02 GMT
From: pacman@defiant.cqc.com (Alan Curry)
Subject: Re: File handle tests with pattern matching to promote early termination of a file read
Message-Id: <G4GU3.31618$23.1655368@typ11.nn.bcandid.com>
In article <7vv7h7$mtp$1@rguxd.viasystems.com>,
<lee.lindley@bigfoot.com> wrote:
>Yes, I saw that post. And yet has anyone actually ever been burned
>by this?
>
>It is still a hypothetical problem of such low probability...
The difference between a good programmer and a bad programmer is that a bad
programmer only handles the cases he has personally seen, while the good
programmer handlers the edge cases correctly. To deliberately ignore a
possible error condition because you don't judge it likely enough to be worth
your effort is an unforgivable sin.
I hope I never get stuck using anything you wrote.
--
Alan Curry |Declaration of | _../\. ./\.._ ____. ____.
pacman@cqc.com|bigotries (should| [ | | ] / _> / _>
--------------+save some time): | \__/ \__/ \___: \___:
Linux,vim,trn,GPL,zsh,qmail,^H | "Screw you guys, I'm going home" -- Cartman
------------------------------
Date: 5 Nov 1999 21:36:14 GMT
From: lee.lindley@bigfoot.com
Subject: Re: File handle tests with pattern matching to promote early termination of a file read
Message-Id: <7vvike$q8l$1@rguxd.viasystems.com>
Alan Curry <pacman@defiant.cqc.com> wrote:
:>In article <7vv7h7$mtp$1@rguxd.viasystems.com>,
:> <lee.lindley@bigfoot.com> wrote:
:>>Yes, I saw that post. And yet has anyone actually ever been burned
:>>by this?
:>>
:>>It is still a hypothetical problem of such low probability...
:>The difference between a good programmer and a bad programmer is that a bad
:>programmer only handles the cases he has personally seen, while the good
:>programmer handlers the edge cases correctly. To deliberately ignore a
:>possible error condition because you don't judge it likely enough to be worth
:>your effort is an unforgivable sin.
:>I hope I never get stuck using anything you wrote.
Alan, you have seen the kind of code I write in this very newsgroup.
I am almost always painfully correct in my dealings with error
conditions and the handling of edge cases, and when I am not, I say
so in the comments. The same is true in the code I write for my
employer, who by the way, would prefer that I optimize my efforts to
provide them with the best possible functionality at the most
reasonable cost. Most employers have little interest in spending
money on perfection (though they may run quality programs with
slogans that make you think they do, they don't really; they want a
reasonable level of quality for the cost).
In fact if you look at the very beginning of an earlier thread about
"??", you will find that I tested for eof on the file with
while (<>) {
...
my $second_line = <>;
unless defined($second_line) {
warn "I forget what I warned about.";
last;
}
}
I analyzed the probability of this particular problem occuring and
judged it inconsequential. But, since it is cheap to check for it I
do anyway. If it required more effort, I might judge that it would
be a waste of my employer's resources and not choose to do it. Real
programmers, including yourself, do that all of the time. You apply
the same judgement to the level of error checking you will do as to
the level of functionality you will provide. Cost/benefit analysis
in the rough.
Ilya wants the '??' operator for the very reason we discuss here
(probably amoung many reasons). If you reduce the threshold and make
something easy to check for, the lazy programmer will do it.
I am a lazy programmer. But I think that if you had to take over a
project I had worked on in the last few years, you would not be
cursing me too often.
Now stuff I did 10 years ago, I'm still cursing myself about. :-)
PS
Did I jump your case on something else? Sorry if I was less
than polite.
--
// Lee.Lindley /// I used to think that being right was everything.
// @bigfoot.com /// Then I matured into the realization that getting
//////////////////// along was more important. Except on usenet.
------------------------------
Date: Sun, 07 Nov 1999 18:32:54 -0800
From: Jon Hollcraft <webmaster@mendonet.com>
Subject: File Upload Without Using Modules?
Message-Id: <38263656.4C9D@mendonet.com>
What is the sequence of events necessary to use the input=file option
from a local machine to a server. What I have found thus far using
examples found for modules transfers the file to my server's /tmp
directory, and then promptly deletes it. While this is an interesting
exercise, it does not copy the local file to the proper directory for
future access. TIA Jon
------------------------------
Date: Mon, 08 Nov 1999 07:54:59 -0800
From: Jim Weisgram <jweisgram@hotmail.com>
Subject: Re: fork & NT Perl
Message-Id: <e=AmOEm0uMfL478qP=k6yX5c3bLG@4ax.com>
Wizard of VOBs <hazard@eznetN-O~S'P&A`M.net> wrote:
>We are running an older version of perl5 on many of our machines, and
>fork is not implemented.
>
>Is fork implemented in newer versions of NT perl? If so which version
>to get?
>
Visit www.activestate.com. There is some mention of a future release of
ActiveState Perl, version 5.6, which will include fork. But no mention of when
that I saw.
--
Jim Weisgram
Oregon Department of Transportation
email: jweisgram@hotmail.com
All opinions expressed are mine and not my employers (but they ought to be)
------------------------------
Date: Thu, 4 Nov 1999 19:42:39 -0000
From: "Mark Grocock" <mark@mgrocock.freeserve.co.uk>
Subject: Forum - cookies
Message-Id: <8073cg$etm$3@news8.svr.pol.co.uk>
I have written a forum script in Perl and would like to know how to use
cookies so that the page created by the script only shows messages the user
hasn't already seen. If you want a copy of the script email me and I will
send it to you.
TIA
--
Mark Grocock (mark_g@cyberdude.com)
------------------------------
Date: Sat, 06 Nov 1999 04:20:57 GMT
From: javabob33@my-deja.com
Subject: FTP Slurp util using PERL
Message-Id: <800ab7$qin$1@nnrp1.deja.com>
gots a question.
Are there any scripts out there that act as a FTP slurp?
by this i mean a daemon that will sit and listen for incoming files,
redirect the inbound files to a new machine, and then mail off an
anouncement?
if ne1 has anything remotely close to this, please gimme a hollar.
thanks,
mike
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: 6 Nov 1999 11:31:02 -0000
From: Jonathan Stowe <gellyfish@gellyfish.com>
Subject: Re: FTP Slurp util using PERL
Message-Id: <8013hm$a3k$1@gellyfish.btinternet.com>
On Sat, 06 Nov 1999 04:20:57 GMT javabob33@my-deja.com wrote:
> gots a question.
>
> Are there any scripts out there that act as a FTP slurp?
>
> by this i mean a daemon that will sit and listen for incoming files,
> redirect the inbound files to a new machine, and then mail off an
> anouncement?
>
If you want to write one then you would probably want to investigate
the module Net::FTP and possibly one of the Mail::* modules as described
in perlfaq9. If you simply want to find such a program then they might
have better luck elsewhere.
/J\
--
Jonathan Stowe <jns@gellyfish.com>
<http://www.gellyfish.com>
Hastings: <URL:http://dmoz.org/Regional/UK/England/East_Sussex/Hastings>
------------------------------
Date: Sat, 06 Nov 1999 22:52:47 GMT
From: omida@my-deja.com
Subject: ftpserver in perl
Message-Id: <802bfv$4eh$1@nnrp1.deja.com>
Any information regarding a ftpserver implementation
in perl (on unix) will be greatly appreciated.
Thanks,
Omid Ahmadian
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Sun, 07 Nov 1999 01:52:55 GMT
From: kragen@dnaco.net (Kragen Sitaker)
Subject: Re: ftpserver in perl
Message-Id: <XX4V3.49729$23.1892287@typ11.nn.bcandid.com>
In article <802bfv$4eh$1@nnrp1.deja.com>, <omida@my-deja.com> wrote:
>Any information regarding a ftpserver implementation
>in perl (on unix) will be greatly appreciated.
You should probably read the perlipc man page to learn how to use
sockets and RFCs 959, 1123 (section 4.1), and 2640 to learn about the
FTP protocol. There's a Net::FTP module on CPAN, but it seems to be
client-only.
Good luck!
--
<kragen@pobox.com> Kragen Sitaker <http://www.pobox.com/~kragen/>
Tue Nov 02 1999
6 days until the Internet stock bubble bursts on Monday, 1999-11-08.
<URL:http://www.pobox.com/~kragen/bubble.html>
------------------------------
Date: 16 Sep 99 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 16 Sep 99)
Message-Id: <null>
Administrivia:
The Perl-Users Digest is a retransmission of the USENET newsgroup
comp.lang.perl.misc. For subscription or unsubscription requests, send
the single line:
subscribe perl-users
or:
unsubscribe perl-users
to almanac@ruby.oce.orst.edu.
| NOTE: The mail to news gateway, and thus the ability to submit articles
| through this service to the newsgroup, has been removed. I do not have
| time to individually vet each article to make sure that someone isn't
| abusing the service, and I no longer have any desire to waste my time
| dealing with the campus admins when some fool complains to them about an
| article that has come through the gateway instead of complaining
| to the source.
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.
For other requests pertaining to the digest, send mail to
perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
sending perl questions to the -request address, I don't have time to
answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V9 Issue 1297
**************************************
