[19429] in Perl-Users-Digest
Perl-Users Digest, Issue: 1625 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Aug 27 06:11:08 2001
Date: Mon, 27 Aug 2001 03:10:09 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Message-Id: <998907009-v10-i1625@ruby.oce.orst.edu>
Content-Type: text
Perl-Users Digest Mon, 27 Aug 2001 Volume: 10 Number: 1625
Today's topics:
Re: warnings with cgi will crash Win32 perl core <goldbb2@earthlink.net>
Re: warnings with cgi will crash Win32 perl core (Yves Orton)
Re: Will Perl report on variables no longer used?? <goldbb2@earthlink.net>
Re: Windows Directory Listing (Tassilo v. Parseval)
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 27 Aug 2001 03:59:30 -0400
From: Benjamin Goldberg <goldbb2@earthlink.net>
Subject: Re: warnings with cgi will crash Win32 perl core
Message-Id: <3B89FDE2.BF936311@earthlink.net>
Godzilla! wrote:
>
> Godzilla! wrote:
>
> > I have been playing around with warnings in the format
> > of -w to discover how many other ways use of warnings
> > screws up a Perl script. They are numerous.
>
> (snipped)
>
> I have attached a simple script which well displays
> how erratic is the behavior of warnings. A quick
> glance at this structure of my test script and, an
> equally quick glance at this warnings generated
> message, discloses significantly erratic behavior
> of perl core warnings.
The word "erratic" means it happens sometimes and not other times, and
whether it does or not is unpredictable. I don't think this is
happening, and I certainly don't see this happening anywhere in your
example.
> On warnings crashing Apache and Windows9.x systems,
You haven't posted any example of having warnings turned on crashing
either Apache or Winblows. Though I wouldn't be surprised at *anything*
crashing winblows...
> this one is hard to analyze and, for my purposes,
> isn't worth a lot of effort; I already know perl
> core warnings are messed up.
It's very easy to analyse. The example you give has the subroutine
Nest_2 use the scalar variable $nest_1. The first time you call Nest_1,
the sub Nest_2 gets created, with a kind of handhold on the lexical
$nest_1 ... if/when Nest_1 gets called a second time, Nest_2 is *not*
made again. It has the $nest_1 value still hanging around from the
first time that Nest_1 was called -- so even if Nest_1 gives it's
$nest_1 a different value, it doesn't matter ... that's a different
lexical $nest_1 than the one which Nest_2 sees.
> My best presumption, based on observed behavior,
> is perl core warnings cannot deal with large and
> complex scripts such as I write.
It has nothing to do with the size or the complexity of your scripts.
You do things which are likely to go wrong, then it will warn you.
> My script under test is a four-thousand line script
> at one-hundred-twenty kilobytes. Only warnings
> messages generated pertain to unitialized values
> of environmental variables and this screwy message
> about "...not stayed shared...." for the first
> nested variable within a sub-routine, within a
> nested loop mechanism and similar devices.
That's because nested subs don't act the way you think they act.
If it gives you a warnings with 'not stay shared' then it's probably
right.
> These messages about unitialized environmental
> variables should only show up when working from
> a command line. Nonetheless, in this complex script,
> those warnings are hooked in. How, I don't know.
Why do you think they should only show up when working with the
commandline? If it's uninitialized, and warnings are turned on, it
prints a warning. Maybe you think that that particular variable *should
be* initialized when not run from the commandline?
> Clearly warnings are FUBAR when it comes to nesting
> my scoped variables; totally FUBAR.
Actually, the warnings are right --- you don't understand what happens
when you nest subroutines.
> For large complex cgi scripts, warnings do in fact
> unlink an Apache web server, become an infinitely
> running process unlinked from the command process
> as a rogue child and, slowly consume RAM memory.
Pfeh. Yeah, right. Show us a script that does that.
> I never use strict nor use warnings, for any reason.
There's two ways to parse this sentence :)
> These problems discovered via testing motivated by
> idle curiosity, well support my notion both strict
> and warnings are not worth a flying hoot's ass.
>
> Ironically, so many Perl 5 Cargo Cultists claim you
> cannot develop scripts over twenty or so lines without
> use of strict and warnings. Nonetheless, I have written
> a four-thousand line script which works perfect, without
> ever using strict nor warnings during development.
>
> Then again, there are those here who claim nobody can
> write more than ten lines of Perl code per day.
>
> There is ironic humor. Running my script with warnings
> only generated false and erratic warning messages; no
> errors were found.
By you. The problems were there, but you didn't see them.
> As to strict, I am certain if I run one of my scripts
> using strict, perl core will suffer critical mass
> attainment, begin melt down and eventually lead to
> events which will devastate half of our known universe.
If you run with strict, and your script is not strict-compliant, it
prints an error message and exits. No melting down, the script just
doesn't run.
> There is a warning about warnings; use warnings at your own risk.
>
> Godzilla!
> --
>
> #!perl -w
>
> &Nest_1;
>
> sub Nest_1
> {
> my ($nest_1) = "nest one";
> print "Nest 1: $nest_1\n";
> my (@Array_1) = qw (nest_one);
> print "@Array_1\n";
>
> &Nest_2;
>
> sub Nest_2
> {
> my ($nest_2) = "nest two";
> print "Nest 2: $nest_1\n";
> my (@Array_2) = qw (nest_two);
> print "@Array_2\n";
>
> &Nest_3;
>
> sub Nest_3
> {
> my ($nest_3) = "nest three";
> print "Nest 3: $nest_3\n";
> my (@Array_3) = qw (nest_three);
> print "@Array_3\n";
> }
> }
> }
>
> exit;
>
> Variable "$nest_1" will not stay shared at test1.pl line 18.
>
> Nest 1: nest one
> nest_one
> Nest 2: nest one
> nest_two
> Nest 3: nest three
> nest_three
But you only show Nest_1 being called once, and you initialize all your
variables to constants. You aren't going to see what the error is if
you do that.
Your code in actual code in *fact* does something like this:
sub Nest_1 {
my $nest_1 = "nest one";
...
&Nest_2;
BEGIN { defined(&Nest_2) or *Nest_2 = sub {
my $nest_2 = "nest two";
# the following line makes this anonymous sub
# into a kind of closure, with $nest_1 permanently
# being whatever it was the very first time &Nest_1
# was called. If this'd been $nest_2 here,
# there'd be no warning, since doing so wouldn't
# closure-ize this anonymous sub.
print "Nest 2: $nest_1\n";
...
&Nest_3;
BEGIN { defined(&Nest_3) or *Nest_3 = sub {
my $nest_3 = ...
} }
} }
}
Do you now see how and when the nested subroutines get defined?
They get made exactly once, and if they are written in a way that
they'll become closures -- that is, if they contain lexicals from the
enclosing scope -- then you get warnings about variables not staying
shared.
How about you try this:
#!/usr/bin/perl -w
sub nest1 {
my $nest1 = shift;
print "1: $nest1\n";
sub nest2 {
my $nest2 = shift;
print "2: $nest1, $nest2\n";
}
&nest2;
}
nest1( "a", "b" );
nest1( "c", "d" );
__END__
This [untested code] should output:
1: a
2: a b
1: c
2: a d
This gives a nice clear demonstration of what "not stay shared" means.
If the behavior you see here is what you want, then maybe you're right
about the warnings being spurious... but considering that the warnings
*are* consistent, you don't have any right to call them erratic.
--
I'm not a programmer but I play one on TV...
------------------------------
Date: 27 Aug 2001 02:42:50 -0700
From: demerphq@hotmail.com (Yves Orton)
Subject: Re: warnings with cgi will crash Win32 perl core
Message-Id: <74f348f7.0108270142.6c68ae56@posting.google.com>
"Godzilla!" <godzilla@stomp.stomp.tokyo> wrote in message news:<3B89B452.303A6B55@stomp.stomp.tokyo>...
> Yves Orton wrote:
>
> > Godzilla! wrote
> > > Yves Orton wrote:
> > > > Godzilla! wrote:
SNIP
> > If you are accustomed to using nested subroutines in other programming
> > languages with their own private variables, you'll have to work at it
> > a bit in Perl. *** The intuitive coding of this type of thing incurs
> > ***mysterious*** ***warnings*** about ***``will not stay shared''***.
>
>
> So, perl core warnings are screwed up just as I have contended
> and documented many times. If I make a variable private via a
> my declaration within a sub-routine, even if a nested sub-routine,
> perl core should not complain.
Wrong. In the case of nested subroutines the variables LOCAL to one
scope are not available TO nested subroutines, except if those
subroutines are anonymous.
#!perl
use warnings;
sub test{
my ($x,$y);
sub test2{$x++};
my $anon=sub {$y++};
}
test;
__END__
Produces:
Variable "$x" will not stay shared at ...\shared.pl line 5.
Notice that ONLY $x will not stay shared. So post your code in proper
detail and it shouldnt be too hard to fix.
> My intent is to make those variables
> strictly private to a sub-routine and, this is obvious in my code
> structure. Nonetheless, perl core warnings complain these private
> variables will not be shared, which is exactly what I intend.
Probably not. Are you doing something like the above? The fact is
Perl comes from the C line of thinking where there is a simple rule:
A variable local to one subroutine is local ONLY to that subroutine
and no other, a variable nonlocal to a subroutine is nonlocal to ALL
subroutines. (This applies within a package). Pascal on the other
hand does NOT say this. (it alows for an arbitrary nesting of
procedures.) Anyway the rule is blurred in perl via the use of
anonymous subroutines (closures) but the rule still applies.
> Perl core warnings are not abiding by my code structure; other
> absolutely F'ed up rules are being applied, when they should not.
Kira, reread your sentence. Does it sound a bit like 'What do you
mean you dont speak english? I speak english, you should respect
that.'? You have already indicated that your 'code structure'
violates documented perl rules so it should be no suprise that you are
getting warnings.
> Due to perl core warnings being absolutely screwed, I question if
> memory is released for out-of-scope my declarations as claimed by
> Perl 5 porters and developers. I suspect, with warnings being tied
> into code structure and scope, this claim of memory being released
> for variables when they leave scope, is very likely bogus.
These are very *very* strong words. You have already demonstrated an
ignorance of how perl works, and now on that basis you doubting how
other things work. This sounds a bit paranoid to me.
If you had begun your perl lifetime with the very simple rule
"Always 'use strict;' always 'use warnings;' and spend the time to
make ALL such warnings go away" then your code would work and you
wouldnt be fighting to convince me or other that 'perl is broken'.
You realize how arrogant you sound: 'Wahhh! Perl must be broken! It
thinks im doing something wrong! How dare it!'
> Clearly, perl core warnings are FUBAR in this aspect and, the final
> result for cgi scripts mounted on selected Win32 boxes, is perl core
> slams itself into an unresolvable loop when -w is used and creates
> myriad other system problems.
Again this is an unsupported claim. Show us the code. Exactly the
code. Show us what values your data structures have etc and then we
can assess what is going on. But sofar from everything you have
posted I (and I suspect given the paucity of responses to your posts
most other people in CLPM) doubt that the problem lies with perl
itself. Much much much more likely to be something subtly wrong with
your code that you *never* realized was a mistake because you have
*never* used warnings or strict.
> > > Common server generated environmental variables do not need to
> > > be initialized nor declared.
>
>
> > > 25 $ENV{REMOTE_HOST} = gethostbyaddr (inet_aton ($ENV{REMOTE_ADDR}), AF_INET);
> > > [Sun Aug 26 10:37:37 2001] chahta.cgi: Use of uninitialized value in subroutine entry at chahta.cgi line 25.
>
> > Suggests to me that $ENV{REMOTE_ADDR} is undefined... What do you get from
> > die if !defined($ENV{REMOTE_ADDR}); I wonder??
>
> > > [Sun Aug 26 10:37:38 2001] chahta.cgi: Use of uninitialized value in scalar assignment at chahta.cgi line 25.
> > Suggests to me that gethostbyaddr is returning an undefined result. I wonder why?
>
> > > [Sun Aug 26 10:37:38 2001] chahta.cgi: Use of uninitialized value in scalar assignment at chahta.cgi line 25.
> > Im not really sure where this one comes from. :-)
>
> > > 26 $ENV{REMOTE_HOST} =~ tr/A-Z/a-z/;
> > > [Sun Aug 26 10:37:38 2001] chahta.cgi: Use of uninitialized value in transliteration (tr///) at chahta.cgi line 26.
>
> > Pretty obvious. $ENV{REMOTE_HOST} is undefined.
>
> > > 27 $ENV{HTTP_USER_AGENT} =~ tr/A-Z/a-z/;
> > > [Sun Aug 26 10:37:38 2001] chahta.cgi: Use of uninitialized value in transliteration (tr///) at chahta.cgi line 27.
>
> > Also obvious. $ENV{HTTP_USER_AGENT} is undefined.
>
>
> Canned Mule Manure.
>
> Only variable which is initially undefined is Remote_Host with this feature
> disabled on my server for efficiency.
>
> Why you are spouting mule manure is quite obvious. Perl core warnings still cop
> false warning messages after the host is defined and, very obvious, Remote_Addr
> and Remote_Agent are well defined.
Really. So send us the dumper output that I asked for. Really. I want
to see a Data::Dumper output of your %ENV. Im not going to reply to
any more of this crap unless you support your outlandish claims with
some evidence. And, frankly note that even though you get on my nerves
Im the *only* one trying to help you out. *Even* though the attitude
really annoys me.
SNIP RANT ABOUT WARNINGS AND THE REST...
Post some proper samples so that others can duplicate the results that
you say are wrong. If we can duplicate them then they should be
handed over to the perl-porters, if not, then well its your code thats
wrong, if you want to bite those that take the time to try to help you
then thats your problem.
Yves
------------------------------
Date: Mon, 27 Aug 2001 05:34:29 -0400
From: Benjamin Goldberg <goldbb2@earthlink.net>
Subject: Re: Will Perl report on variables no longer used??
Message-Id: <3B8A1425.4D5CC9D1@earthlink.net>
Abigail wrote:
>
> Ilya Martynov (ilya@martynov.org) wrote on MMCMVII September MCMXCIII
> in <URL:news:87lmkjsvmw.fsf@abra.ru>:
> ..
> .. CCG> Hi everyone,
> .. CCG> Occasionally I find myself redoing a sub and in the process I
> .. CCG> neglect to remove some my variables that are no longer needed.
> .. CCG> I forget about them and they stay there taking up name space.
> .. CCG> Unwanted and unneeded.
> ..
> .. CCG> Is there some command line switch for Perl or other technique
> .. CCG> that will report on a variable not being used? That will
> .. CCG> return a warning to that effect?
> ..
> .. CCG> In other languages like Delphi the compiler reports on these
> .. CCG> kinds of things so that you can clean up your code of useless
> .. CCG> variables.
> ..
> .. I belive if you run your scripts as 'perl -w' or your script has
> .. 'use warnings' (works in new Perls) it will be reported as warning:
> ..
> .. Name ""%s::%s"" used only once: possible typo
>
> Only on package variables, and Perl is often wrong. Sure, the name
> might appear only once in the program text - that doesn't mean the
> variable is otherwise unused. I might use a symbolic reference for
> instance. It's a package variable after all.
I agree here ... also you might simply assign to it once, and then later
things outside the module, or in the perl internals, will look at it,
like $VERSION, @ISA, etc., but your own code within that file will never
look at it again.
> Furthermore, I quite often use lexical variables that appear only once
> in the program - yet if the compiler would give a warning of being
> used only once, it would be an annoyance as the variable is needed.
> There are after all no anonymous scalars.
>
> sub TIESCALAR {
> my $proto = shift;
> my $class = ref $proto || $proto;
>
> bless \(my $foo = shift) => $class;
> }
I think this is a special case -- it's used once, but a reference to it
is returned to be used elsewhere. Here's Craig Berry's example:
sub foo {
my $bar;
1;
}
Neither $bar nor a reference to it is ever used -- yet perl gives no
warning about it.
--
I'm not a programmer but I play one on TV...
------------------------------
Date: 27 Aug 2001 09:54:56 GMT
From: Tassilo.Parseval@post.rwth-aachen.de (Tassilo v. Parseval)
Subject: Re: Windows Directory Listing
Message-Id: <9md5dg$jh6$1@nets3.rz.RWTH-Aachen.DE>
On 26 Aug 2001 19:46:45 -0700, Steve Klebar <sjklebar@hotmail.com> wrote:
> Is it possible to get directory listing on a Windows client from a
> apache server using a perl/CGI program? The desired directory is
> dynamically identifed based on the value of a file entered by a user
> on an HTML form. If you have an approach that you would like to share,
> it would be appreciated. I am a relatively new perl programmer, so
> adjust your spped accordingly. Thanks in advance for your help.
Certainly not because people in general dislike the idea of a
remote-server sniffing around on one's harddisk and doing fancy things
there.
Why would you want to do that anyway?
Tassilo
--
$a=[(74,116)];$b=[($a->[1]-1,$a->[1]++,0x20)];$c=[(97,110)];$d=[($c->
[1]+1,$b->[1],"her")];for(@{[$a,$b,$c,$d]}){for(@{$_}){$_=~/\d+/?print
(chr($_)):print;}}$c=sub{$l=shift;[(0x20+$l-1,0x50,0x65,0x73-0x01,108
),(0x20,0x68,0x61,)]};print(map{chr($_)}@{($c->(1))});$h={a=>33*3,b=>
10**2+7,c=>"1"."0"."1",d=>0162};@h=sort(keys(%$h));for(@h){print(chr(
ord(chr($h->{$_}))))};
------------------------------
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:
The Perl-Users Digest is a retransmission of the USENET newsgroup
comp.lang.perl.misc. For subscription or unsubscription requests, send
the single line:
subscribe perl-users
or:
unsubscribe perl-users
to almanac@ruby.oce.orst.edu.
To submit articles to comp.lang.perl.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 V10 Issue 1625
***************************************
