[19427] in Perl-Users-Digest
Perl-Users Digest, Issue: 1622 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Aug 27 00:10:25 2001
Date: Sun, 26 Aug 2001 21:10:08 -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: <998885408-v10-i1622@ruby.oce.orst.edu>
Content-Type: text
Perl-Users Digest Sun, 26 Aug 2001 Volume: 10 Number: 1622
Today's topics:
Re: Perl OO needs the opposite of SUPER:: (John Lin)
Re: pipe STDERR <goldbb2@earthlink.net>
Re: warnings with cgi will crash Win32 perl core (Yves Orton)
Re: warnings with cgi will crash Win32 perl core <godzilla@stomp.stomp.tokyo>
Windows Directory Listing (Steve Klebar)
Re: Yet another regex question (Randal L. Schwartz)
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 26 Aug 2001 20:16:23 -0700
From: johnlin@chttl.com.tw (John Lin)
Subject: Re: Perl OO needs the opposite of SUPER::
Message-Id: <a73bcad1.0108261916.39660c7e@posting.google.com>
Ilmari Karonen wrote
> John Lin wrote:
> >The pre-report and post-report are all different codes for each caller.
> >Thus, only pre_report and post_report are not enough. You need
> >pre_report_in_gen, post_report_in_gen, pre_report_in_save_as_html, ...
> Ah, but this is where you're missing the point. Do it this way instead:
>
> sub gen {
> print "Now we are generating report:\n";
> $self->pre_report, $self->report, $self->post_report;
> print "Done, hope you like it.\n";
> }
Yes, indeed, I missed the point. Ah, this solution is quite interesting.
Thank you.
John Lin
------------------------------
Date: Sun, 26 Aug 2001 23:55:50 -0400
From: Benjamin Goldberg <goldbb2@earthlink.net>
Subject: Re: pipe STDERR
Message-Id: <3B89C4C6.28DCBF0F@earthlink.net>
Philippe PERRIN wrote:
>
> Philippe PERRIN wrote:
> > Using open(F, "command |"); will let me pipe the stdout of
> > "command". But how can I pipe its stderr ? (not using 2>&1, because
> > I'm on a Windows system... I'd like a Perl solution).
>
> OK, I found IPC::Open3 which works fine.
> However, it seems that on Windows systems, stderr is read through a
> buffer :
> - on Solaris (where stderr is NOT read through a buffer), reading the
> stderr of "command" with open3() happens as soon as "command" produces
> the output (line by line, instantly)
> - on Windows2000, I have to wait for "command" to terminate to get its
> stderr, which is very annoying, since I need to parse it as it is
> produced...
>
> Is there any Perl solution to force a FILEHANDLE to be non-bufferized?
You can sort-of disable buffering on your output buffers [well, turning
on autoflush isn't quite the same as turning off buffering, but it's
close], and you can *bypass* buffering by using sysread and syswrite...
But this won't solve your problem.
The reason you have to wait until the command is complete is because
Windows is buffering it, not because of any buffering in perl.
You need to use one of the Win32:: modules to start a process in the way
that you want.
--
I'm not a programmer but I play one on TV...
------------------------------
Date: 26 Aug 2001 18:27:33 -0700
From: demerphq@hotmail.com (Yves Orton)
Subject: Re: warnings with cgi will crash Win32 perl core
Message-Id: <74f348f7.0108261727.1390ff19@posting.google.com>
"Godzilla!" <godzilla@stomp.stomp.tokyo> wrote in message news:<3B893DAD.36A60C24@stomp.stomp.tokyo>...
> Yves Orton wrote:
>
> > Godzilla! wrote:
>
> (snipped)
>
> > > 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.
>
> > You should post some samples.
>
>
> Godzilla!
> --
>
> For this example, $card_one_url through $card_five_url are declared
> as my variables at the beginning of a subroutine and, are immediately
> asssigned values long before this block is initiated. These variables
> are intended to not be visible outside this sub-routine and, are not
> used outside this specific sub-routine, which is nested three levels.
Ok. So WHAT precisely do you mean by 'nested three levels'. Unless
you are using closures this cannot be done. The code you have posted
is simpley *not* sufficient to see what is going on. You have not
provided us with the declarations of anything, nor have you shown what
you mean by this mysterious 'nested three levels'. This is *very*
suggestive of a substantial misunderstanding. If you are worried about
trade secrets or what have you then confabulate an equivelent that
demonstrates the problem.
Anyway a quote from perlref (*** added by me):
Access to lexicals that change over type--like those in the for loop
above--only works with closures, not general subroutines. ***In the
general case, then, named subroutines do not nest properly, although
anonymous ones do.*** 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''***. For example, this won't work***:
sub outer {
my $x = $_[0] + 35;
sub inner { return $x * 19 } # WRONG
return $x + inner();
}
A ***work-around*** is the following:
sub outer {
my $x = $_[0] + 35;
local *inner = sub { return $x * 19 };
return $x + inner();
}
Now inner() can only be called from within outer(), because of the
temporary assignments of the closure (anonymous subroutine). But when
it does, it has normal access to the lexical variable $x from the
scope of outer().
*** This has the interesting effect of creating a function ***local to
another function***, something ***not*** normally supported in
Perl.***
> Warnings generates thousands of false messages like this for a variety
> of sub-routine enclosed my variables within my script.
Well. Post the WHOLE 'nested three levels' (minus non variable
declarations and subroutine declarations). I bet you duped the
*documented* error from above (by which incidentally I have been
bitten before and alluded to in my earlier post)
SNIP CODE FRAGMENT AND ERRORS
> **************
>
>
> Common server generated environmental variables do not need to
> be initialized nor declared.
You are *sure* about this now?
So if you stick the following lines in you code what happens:
die "Doh! \$ENV{REMOTE_HOST} is undefined!" if
!defined($ENV{REMOTE_HOST});
die "Doh! \$ENV{REMOTE_HOST} does not exist!" if
!exists($ENV{REMOTE_HOST});
In fact, better yet, Id be really interested to see what would happen
if you inserted the following as line 25
{ #local block
require Data::Dumper;
our $FILE='>D:\Temp\Dump_Env.pl';
open FILE or die "Cant open $FILE:$!";
print FILE Data::Dumper::Dumper(\%ENV);
close FILE;
}
Could you post that file, or at least the bits that refer to the
keys:REMOTE_HOST, REMOTE_ADDR,HTTP_USER_AGENT?
Anyways, on to your code and errors. (Rearranged for ease of use...]
>
> 24 use Socket;
What else are you using?
> 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.
>
>
>
>
>
> **************
>
> Warnings displays very clear loopy behavior here and the next two examples.
> This looping becomes worse and, generates thousands of lines of warnings
> all referring back to valid specific environmental variables.
>
> Without use of Carp to throttle output, this loopy behavior quickly
> becomes infinite looping in nature; output from warnings repeats these
> types of lines, infinitely.
>
> Two noticable symptoms take place. First is internal linkage to Apache
> for this specific script is lost. No further instances can be initiated.
> RAM memory is slowly consumed until the process is killed. Other processes
> can be run ok, but this process becomes rogue, unaccessable save for a
> kill process command.
>
>
>
> 220 for (@Itihollo)
> 221 {
> 222 if (index ($ENV{REMOTE_ADDR}, $_) > -1)
> 223 { $itikana = "kana"; }
> 224 }
>
>
> [Sun Aug 26 10:37:38 2001] chahta.cgi: Use of uninitialized value in index at chahta.cgi line 222.
So how many elements are there in @Itihollo? Print it out:
print "There are ".scalar(@Itihollo)." elements in \@Itihollo\n";
Do you get EXACTLY the same number of warnings?? I did.
[CHOPPED MORE ERRORS AND UNDEFINED VARS USED IN CODE]
Look, Zilla. All of this stuff is pretty obvious. These arent bugs.
At least not in perl. If a variable has not been *explicitly* given a
value then its value will be undefined. In use strict and use
warnings either fatal errors, or warnings will be generated. When not
in use strict then perl will do its best to DWIM (do what I mean) and
12 times out of 13 *will* do what you wanted, but *not* what you
thought it was doing. Consider your instr() calls. When you arent
using warnings perl will silently convert undef into "". When you are
it will tell you. Same with substr. Try it:
#!perl
my $string;
print "Contains..." if index($string,"String")>-1;
Now what happens if you add the '-w' switch or (my preference) add
'use warnings;' You get a warning. Simple. Indeed some things are
considered so serious that under 'use strict;' the program will just
plain old die:
#!perl
$name = "foo";
$$name = "Hello Kira, You should read perlref\n"; # Sets $foo
print $foo;
{
#use strict;
$$name = "Or you wont understand what perl is doing...\n";
print $foo;
}
__END__
Now if you run the above then you will get:
Hello Kira, You should read perlref
Or you wont understand what perl is doing...
But if you uncomment the #use strict; you get
Variable "$name" is not imported at
D:\Development\Perl\Scratch\test_file.pl line 7.
Variable "$foo" is not imported at
D:\Development\Perl\Scratch\test_file.pl line 8.
Global symbol "$name" requires explicit package name at
D:\Development\Perl\Scratch\test_file.pl line 7.
Global symbol "$foo" requires explicit package name at
D:\Development\Perl\Scratch\test_file.pl line 8.
Execution of D:\Development\Perl\Scratch\test_file.pl aborted due to
compilation errors.
Pretty *huge* difference eh?
Ok so now back to your code, check the things that I have asked and
then post back and tell use that warnings are wrong.
Yves
ps You know there are lots of people that post here that would be
happy to help you out if you just came to the table with a little
humility. You act and talk like you _should_ be the code-jock of the
world, but then you post stuff like this which just demonstrates that
there are basic CS concepts that you dont understand, which is fine
really, except that you can't admit it, and you throw attitude around.
------------------------------
Date: Sun, 26 Aug 2001 19:45:38 -0700
From: "Godzilla!" <godzilla@stomp.stomp.tokyo>
Subject: Re: warnings with cgi will crash Win32 perl core
Message-Id: <3B89B452.303A6B55@stomp.stomp.tokyo>
Yves Orton wrote:
> Godzilla! wrote
> > Yves Orton wrote:
> > > Godzilla! wrote:
(snipped)
> > > > 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.
> > > You should post some samples.
> 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. 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.
Perl core warnings are not abiding by my code structure; other
absolutely F'ed up rules are being applied, when they should not.
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.
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.
> > 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.
Further mule manure of yours. If Remote_Addr is not defined, nothing works.
There must be a remote address available for transaction. You know this, thus you
are spouting mule manure.
Typical cgi environmental variables to not need to be declared nor initialized.
For many, this is impossible. A lot of cgi environmental variables are restricted
to read only status. Any attempt to modify one of these results in a script crash.
Ever try to my scope or modify a read only environmental variable?
Canned Mule Manure!
You Perl 5 Cargo Cultists need to wise up. Perl warnings are FUBAR and for these
circumstances described, crash a script, unlink a webserver and, there is a good
chance an average Win32 system will cop a Blue Screen Of Death.
You geeks are highly irresponsible for not warning people about these serious
problems when you dictate, "You MUST use warnings always." Yeah, right.
Warnings are ok but should be tagged with: "Use of warnings might crash your system."
Godzilla! Queen Of Realitia.
------------------------------
Date: 26 Aug 2001 19:46:45 -0700
From: sjklebar@hotmail.com (Steve Klebar)
Subject: Windows Directory Listing
Message-Id: <1a4e7e5d.0108261846.1e8361b@posting.google.com>
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.
Steve
------------------------------
Date: 26 Aug 2001 20:17:19 -0700
From: merlyn@stonehenge.com (Randal L. Schwartz)
Subject: Re: Yet another regex question
Message-Id: <m1y9o6qji8.fsf@halfdome.holdit.com>
>>>>> "Mark" == Mark Jason Dominus <mjd@plover.com> writes:
>> $str = "foo( a, b1 b2 , c )";
>> my @items = split /\s*,\s*/, ($str =~ /\(\s*(.*?)\s*\)/)[0];
Mark> I think that [0] is unnecessary there---one might as well let the
Mark> match be evaluated in list context.
But (...) won't put it into list context. It'd be scalar context
because of split, and that'll try to split a 1/0 return, not the first
memory, and I want the first memory.
Mark> I only mention this because it's been on my mind a lot lately.
Mark> Recently I needed to write something like:
Mark> perl -nle '($d) = /blah(\d+)blah\.jpg/; $n = sprintf "img%03d.jpg", $d; symlink $_ => $n' `find ....`
Mark> and I realized partway through that I could write this instead:
Mark> perl -nle '$n = sprintf "img%03d.jpg", /blah(\d+)blah\.jpg/; symlink $_ => $n' `find ....`
sprintf *does* provide list context to its args, so that works.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
------------------------------
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 1622
***************************************
