[18908] in Perl-Users-Digest
Perl-Users Digest, Issue: 1076 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Jun 6 14:16:08 2001
Date: Wed, 6 Jun 2001 11:15:32 -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: <991851332-v10-i1076@ruby.oce.orst.edu>
Content-Type: text
Perl-Users Digest Wed, 6 Jun 2001 Volume: 10 Number: 1076
Today's topics:
Re: Process form WITHOUT feedback page PART 2 (Helgi Briem)
Re: Process form WITHOUT feedback page PART 2 <godzilla@stomp.stomp.tokyo>
Re: Process form WITHOUT feedback page PART 2 <godzilla@stomp.stomp.tokyo>
Re: Process form WITHOUT feedback page PART 2 <godzilla@stomp.stomp.tokyo>
Re: Process form WITHOUT feedback page PART 2 nobull@mail.com
Re: Recursing a directory tree (Gary E. Ansok)
Re: Required libraries don't appear to be included nobull@mail.com
Storing fetched data?vvp <vprasad@americasm01.nt.com>
Re: taint + netstat = error <ryantate@OCF.Berkeley.EDU>
Re: The difference between =~ and = <christian.meisl@tugraz.at>
Re: The difference between =~ and = <todd@designsouth.net>
Re: try ... catch nobull@mail.com
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 06 Jun 2001 16:08:16 GMT
From: helgi@NOSPAMdecode.is (Helgi Briem)
Subject: Re: Process form WITHOUT feedback page PART 2
Message-Id: <3b1e54d6.631494151@news.isholf.is>
On 6 Jun 2001 07:36:45 -0700, m-m@lcc.net (GearGirl) wrote:
< SNIP PAGES AND PAGES OF REALLY BAD CODE >
>Is there any other way to just get the script to process the form, log
>the data, and END THERE?
Yes, use the CGI.pm module, which comes with every
standard distribution of Perl and does this stuff much
better, more easily and more securely.
perldoc - X CGI
http://www.perl.org/CGI_MetaFAQ.html
Regards,
Helgi Briem
------------------------------
Date: Wed, 06 Jun 2001 09:19:14 -0700
From: "Godzilla!" <godzilla@stomp.stomp.tokyo>
Subject: Re: Process form WITHOUT feedback page PART 2
Message-Id: <3B1E5802.33037AB4@stomp.stomp.tokyo>
GearGirl wrote:
> Godzilla! wrote:
> > GearGirl wrote:
(snippage)
> First...I must ask....Choctaw???
There is no need for you to ask. You already know
my native tongue is Choctaw. Significantly less than
one-percent of any given peoples would recognize
my words as Choctaw. Within our Native American
culture, less than ten percent would recognize my
words as Choctaw. I speak, read and write Choctaw,
however there are hundreds of Native American dialects
I could not begin to recognize by Tribal variety.
Clearly you know more about me than you are admitting.
> From some of the other posts I've seen, I wasn't sure WHAT kind of
> response I'd get from you (flame or help).
This borders on being insulting. However, I do practice
being unpredictable so your response is somewhat reasonable.
> Seems there is more to Godzilla! than initially meets the eye...
I like to think so.
> > (snipped)
> > > As suggested, I used the "Status: 204 No Response" lines in my Perl
> > > script to try to capture some hidden info on one of my pages WITHOUT
> > > giving the user a feedback page...
> > I have successfully replicated what you are doing. This
> > works perfect with Mozilla 4.7 although I understand your
> > problem is with Microsoft's browser. As you know MSIE does
> > not meet industry standards. Nonetheless, maybe you will
> > spot something in my html code and script code which
> > might be of help.
> [snipped]
> The only significant difference I had was I preceded
> > print "Status: 204 No Response\n\n";
> with print "Content-type: text/plain\n";
Yes, you cannot mix a content type print with a status print.
You can only print one or the other, never both.
> But even after I commented it out, I still got that confounded window
> popping up. It does log the data as requested, but unfortunately it's
> not doing it "behind the scenes" like I wanted it to.
My best guess is, this might be browser specific behavior. You
are testing with MSIE which does not meet industry standards.
Behavior of MSIE is completely unpredictable, as I often am.
I am not sure you will ever remedy this for MSIE browsers.
Your script will work perfect with Mozilla 4.7 after a few
corrections here and there.
> My script receipt.pl (documentation stripped out) follows (my html was
> included in the first post of this string, "test" was the hidden field
> in the form):
Ok, I would like you to test with my html, to eliminate the body
on load part. Shouldn't make a difference but who knows with MSIE?
(snipped code)
Look over my code below my signature. I have made some changes to
assist you in testing, to assist you by making your code shorter,
easier to read and easier to modify as you move along in testing.
This code of mine works perfect with a Mozilla 4.7 browser.
I removed your call to include a read and parse library. In its
place I plugged in a bare bones parsing routine. Format is:
$in{Whatever_Name}
to grab your form action input variables. Later, you can plug your
library call back in. This eliminates any possible error due to a
bad library call or errors within your library routine itself.
Your cookie routine has been reduced to bare essentials for testing.
You really only need to test for a cookie environmental variable.
Removing this, eliminates any possible errors included in your
cookie routine. Leave out your cookie stuff until you are satisfied
this script performs as you expect. Then add your cookie stuff and
discover if all still works right.
Find this line:
# &no_response; <-- This is an error
What happens here, in your else choice, is printing a 204 message
conflicts with your html print, &invalid_viewer; , following.
You cannot return a "no response" then print html. One or the
other but not both. This might be the very source of your problem.
Note I added a content type print to &valid_viewer. This is a must.
I changed your path and file name for your log record for testing
on my machine,
open(LOGIT, ">test.dat"); ## || &ErrorMessage;
You will want to "hard code" a path and file name for this. With
removal of your cookie stuff, a path and name is not set, which
is how it should be for initial testing. Keep it short and sweet.
I commented out &ErrorMessage simply because this sub-routine
does not exist in your code.
Finally, at the end of your script, sub invalid_viewer , has been
rewritten to be short and provide a quick message this sub-routine
was invoked successfully. Again, note my inclusion of a content type.
I will urge you to use both my html page and my test script
precisely and exactly as is. This works perfect with Mozilla.
It will make an excellent comparative test for MSIE. Eliminate
MSIE as a problem or, confirm it as a problem, before you
make changes and move on in your testing. It is critical to
maintain absolute controls for any series of experiments.
Test this exhaustively, then start adding your other stuff
back in, a little at time. I believe you may enjoy success
if you approach this in accordance with Scientific Method.
Godzilla!
--
My HTML:
Change the script name as needed.
Note the NAME and VALUE for my hidden field.
Use $in{Purl_Gurl} to grab this variable or
change these to suit your needs.
________
<html><body>
<FORM ACTION="test1.cgi" METHOD="POST">
<INPUT TYPE="submit" NAME="Button" VALUE="204 Test">
<INPUT TYPE="hidden" NAME="Purl_Gurl" VALUE="purl_gurl">
</FORM>
</body></html>
Test Script:
____________
#!perl
&Akostininchi_Ithana;
sub Akostininchi_Ithana
{
local (*in) = @_ if @_;
local ($i, $key, $value);
read (STDIN, $in, $ENV{'CONTENT_LENGTH'});
@in = split (/&/, $in);
foreach $i (0 .. $#in)
{
$in[$i] =~ s/\+/ /g;
($key, $value) = split (/=/, $in[$i], 2);
($value eq "") && next;
$key =~ s/%(..)/pack ("c",hex($1))/ge;
$value =~ s/%(..)/pack ("c",hex($1))/ge;
$in{$key} .= "\0" if (defined ($in{$key}));
$in{$key} .= $value;
}
return 1;
}
$test = $in{Purl_Gurl};
&logit;
sub logit
{
if ($ENV{'HTTP_COOKIE'})
{
&no_response;
&valid_viewer;
exit;
}
else
{
## &no_response; <-- This is an error
&invalid_viewer;
exit;
}
sub valid_viewer
{
open(LOGIT, ">test.dat"); ## || &ErrorMessage;
print LOGIT "Valid Viewer Used: $test";
close(LOGIT);
}
sub no_response
{
## print "Content-type: text/plain\n"; <-- This is an error
print "Status: 204 No Response\n\n";
}
sub invalid_viewer
{
print "Content-type: text/html\n\n
<HTML></BODY>
<BR>
Sub-Routine Invalid Viewer Used.
</BODY></HTML>";
}
}
------------------------------
Date: Wed, 06 Jun 2001 09:56:37 -0700
From: "Godzilla!" <godzilla@stomp.stomp.tokyo>
Subject: Re: Process form WITHOUT feedback page PART 2
Message-Id: <3B1E60C5.4586C30F@stomp.stomp.tokyo>
Godzilla! wrote:
> GearGirl wrote:
> > Godzilla! wrote:
> > > GearGirl wrote:
Before these anal retentive sissified geeks around here
have a chance to annoyingly nitpick and claim a major
victory of proving Godzilla! as always being wrong,
I will amend a statement I made.
"Yes, you cannot mix a content type print with a status print.
You can only print one or the other, never both."
Yes, you cannot mix a content type print with a status 204 print....
Godzilla!
------------------------------
Date: Wed, 06 Jun 2001 10:08:43 -0700
From: "Godzilla!" <godzilla@stomp.stomp.tokyo>
Subject: Re: Process form WITHOUT feedback page PART 2
Message-Id: <3B1E639B.C2A44915@stomp.stomp.tokyo>
Godzilla! wrote:
> GearGirl wrote:
> > Godzilla! wrote:
> > > GearGirl wrote:
While reviewing my article with a fresh
mind's eye, I caught one other error.
## print "Content-type: text/plain\n"; <-- This is an error
Your content type should be followed by two newlines:
print "Content-type: text/plain\n\n";
You may also accomplish this by simply adding
a blank line after your content type print,
print "Content-type: text/plain
text .. words .. etc.";
Godzilla!
------------------------------
Date: 06 Jun 2001 18:08:20 +0100
From: nobull@mail.com
Subject: Re: Process form WITHOUT feedback page PART 2
Message-Id: <u9elsxzgcb.fsf@wcl-l.bham.ac.uk>
m-m@lcc.net (GearGirl) writes:
> nobull@mail.com wrote in message news:<u94rtu24jf.fsf@wcl-l.bham.ac.uk>...
> > m-m@lcc.net (GearGirl) writes:
> >
> > It was also suggested that this had nothing whatever to do with Perl,
> > and that you should therefore take this matter elsewhere. That you
> > did. Why have you come back?
>
> I have come back because I see NOTHING that indicates that this is not
> Perl related. NOTHING.
I also see NOTHING that indicates that this is not coffee related.
NOTHING. So I recommed that you post in rec.food.drink.coffee. :-)
> My first post was in comp.infosystems.www.authoring.cgi
>
> GET A GRIP.
Sorry, I had confused this question with another one that had been
asked in CLPM and then later in CIWAC.
I unreservedly retract my statement that you had already been told
this was off-topic here.
> And I strongly believe this DOES have something to do with Perl, since
> a Perl script is what I wrote to DO this.
Common falicy. My favoured analogy to illustrate this fallacy is
suppose you wrote a Perl script that simply printed "Go jump in the
lake". Someone runs your script an instead of getting up from their
computer and diving into the nearest inland expanse of standing water
they just sit there. Now, clearly, your Perl script is not producing
the desired outcome. However this does not have anything to do with
Perl.
> That's also why I'm posting to a *.misc section, because it appears
> to be a catch-all.
It is only supposed to catch stuff that's Perl related.
> My question remains, how do I keep from instructing the browser to
> open another window.
Simply find where you are not giving it such an instruction and remove
it. This is almost certainly in the thing that calls your Perl
script, not in your Perl script.
--
\\ ( )
. _\\__[oo
.__/ \\ /\@
. l___\\
# ll l\\
###LL LL\\
------------------------------
Date: 6 Jun 2001 16:34:50 GMT
From: ansok@alumni.caltech.edu (Gary E. Ansok)
Subject: Re: Recursing a directory tree
Message-Id: <9flm3a$ea0@gap.cco.caltech.edu>
In article <3B1DAA34.2C76EF17@earthlink.net>,
Benjamin Goldberg <goldbb2@earthlink.net> wrote:
>Fortunately, solving one solves the other, since unix file systems don't
>allow circularities other than ".", ".." or symbolic links. Except for
>"." and "..", there are not allowed to be *any* hard links to
>directories.
>
>The solution? Replace:
> if (-d "$dir/$file")
>with:
> if (-d "$dir/$file" and !-l _)
Make that
if (! -l "$dir/$file" and -d _)
Be *very* careful using the special _ handle when mixing -l and
other file tests. The _ handle will remember data from the last
stat() or lstat() call, which for your line will be a stat() call
that will look through any symbolic links.
In fact, I get an error message (5.005_01):
% perl -e "print -d q(bar) && -l _"
The stat preceding -l _ wasn't an lstat at -e line 1.
The line as I wrote it happens to work in this case, but there
are many cases where it may be best just to not use the _ handle
instead of trying to figure out where it is and isn't useful.
For example, if there are more tests further down in the code
(e.g., "elsif (-f _)"). If in doubt, just repeat the file path
-- better to have correct code, even if it is slightly slower.
--
Gary Ansok ansok@alumni.caltech.edu
Greetings, my friends. We are all interested in the future, for that is
where you and I are going to spend the rest of our lives. And remember,
my friends, future events such as these will affect you in the future.
------------------------------
Date: 06 Jun 2001 18:14:18 +0100
From: nobull@mail.com
Subject: Re: Required libraries don't appear to be included
Message-Id: <u9bso1zg2d.fsf@wcl-l.bham.ac.uk>
"Sean" <fishgeek@spamcop.net> writes:
> It appears that the required libraries are not being included as many
> variables that are set in those libraries are evaluating to blank when the
> script runs.
If you care about the require failing perhaps it would make sense to
trap and do something about the error rather than trap and ignore it/
> Here is one of the requires:
>
> eval {
>
> ($0 =~ m,(.*)/[^/]+,) && unshift (@INC, "$1"); # Get the script
> location: UNIX / or Windows /
> ($0 =~ m,(.*)\\[^\\]+,) && unshift (@INC, "$1"); # Get the script
> location: Windows \
> require "UltBB.setup";
>
> };
I suggest you look at the FAQ "How do I add the directory my program
lives in to the module/library search path?" as that appears to be
what you are trying to do.
>
> Can someone give me some thoughts on why these files wouldn't be
> included,
Try looking in $@ and $!.
--
\\ ( )
. _\\__[oo
.__/ \\ /\@
. l___\\
# ll l\\
###LL LL\\
------------------------------
Date: Wed, 06 Jun 2001 10:59:33 -0400
From: "Prasad, Victor [FITZ:K500:EXCH]" <vprasad@americasm01.nt.com>
Subject: Storing fetched data?vvp
Message-Id: <3B1E4555.365A4A32@americasm01.nt.com>
Hello,
I have opened a dbi connection and am fetching some data:
<database opened>
my
($cat_sot,$cat_sod,$cat_gid,$cat_1,$cat_d1,$cat_2,$cat_d2,$cat_3,$cat_d3);
while
(($cat_sot,$cat_sod,$cat_gid,$cat_1,$cat_d1,$cat_2,$cat_d2,$cat_3,$cat_d3)
= $sth->fetchrow_array )
{
$cats{$cat_sot} = $cat_num;
print
$cgi->p("$cat_sot,$cat_sod,$cat_gid,$cat_1,$cat_d1,$cat_2,$cat_d2,$cat_3,$cat_d3");
}
err_trap("Error fetching category names") if $DBI::err;
I want to store all the fetched rows in to an array matched by their
cataegory name.
ie. cat_sot(1)="dog"
cat_sod(1)="shepard"
.....cat_d3(1) ="purbred"
cat_sot(2)="chicken"
cat_sod(2)="rooster"
.....cat_d3(2)="mutt"
How would I go about doing this in Perl. Then pass this data to other
subroutines or even back to the main routine.
I have read about the 'hash' but am unsure how to use it in this
context.
Thanks,
V
V
<data based closed properly>
------------------------------
Date: Wed, 6 Jun 2001 16:56:34 +0000 (UTC)
From: Ryan Travis Tate <ryantate@OCF.Berkeley.EDU>
Subject: Re: taint + netstat = error
Message-Id: <9flnc2$111i$1@agate.berkeley.edu>
Joe Schaefer <joe+usenet@sunstarsys.com> wrote:
| Bug confirmed on linux w/ 5.00503 and 5.6.1:
| % perl5.00503 -wTe 'undef %ENV; `true`;`true`'
| % perl5.00503 -wTe 'undef %ENV; `true`,`true`'
| Insecure dependency in `` while running with -T switch at -e line 1.
| % perl5.6.1 -wTe 'undef %ENV; `true`;`true`'
| % perl5.6.1 -wTe 'undef %ENV; `true`,`true`'
| Insecure dependency in `` while running with -T switch at -e line 1.
i reported this bug via perlbug, it is on the web here:
<http://bugs.perl.org/perlbug.cgi?req=bug_id&bug_id=20010604.015&format=H&trim=25&target=perbug>
i received a reply, which is on the web here:
<http://bugs.perl.org/perlbug.cgi?req=bidmids&bidmids=20010604.015&format=h&trim=25>
here is an excerpt of the reply, which accompanied a "patch for bleadperl":
| You're being caught by the effect mentioned somewhat obliquely in perlsec:
|
| Any variable set to a value derived from tainted data will
| itself be tainted, even if it is logically impossible for
| the tainted data to alter the variable.
|
| The reason for this is efficiency, since it's only necessary to do taint
| checks on a whole expression rather that for each operator.
i do not understand this reply, and rather than immediately bother the
p5p folk with my ignorance, it thought i would ask here: how does this
explanation have anything to do with the examples shown by joe above
(and submitted by me in my bug report)? there are *no variables
involved* in these test cases, so how can the bug be related to the
fact that "any variable ... will itself be tainted" because blah blah
blah?
it looks like in the patch the respondent is changing the comments or
documentation from the above "any variable ..." quote to:
+The value of an expression containing tainted data will itself be
+tainted, even if it is logically impossible for the tainted data to
+affect the value.
but i still don't see where joe's test case has *any tainted data*.
any insight is greatly appreciated ...
cheers
r
------------------------------
Date: Wed, 6 Jun 2001 16:45:36 +0200
From: Christian Meisl <christian.meisl@tugraz.at>
Subject: Re: The difference between =~ and =
Message-Id: <2162326.qQXWTLkxdt@famvtpc59.tu-graz.ac.at>
Lou Moran wrote:
> $foo = (AbcDEFGhi) ;
> $foo = tr/A-Z/a-z/ ;
> print $foo ;
>
> you get this:
>
> 0
>
> what does this happen?
From the perlop manpage:
tr/SEARCHLIST/REPLACEMENTLIST/cdsUC
y/SEARCHLIST/REPLACEMENTLIST/cdsUC
Transliterates all occurrences of the characters
found in the search list with the corresponding
character in the replacement list. It returns the
number of characters replaced or deleted. If no
string is specified via the =~ or !~ operator, the
$_ string is transliterated. (The string speci
fied with =~ must be a scalar variable, an array
element, a hash element, or an assignment to one
of those, i.e., an lvalue.)
Which means that $foo = tr/A-Z/a-z/ ist equal to $foo = ($_ =~
tr/A-Z/a-z/). The return value of the tr Operator is the number of items
changed, and if $_ == "", the number is 0, which you got as a result.
Best regards,
Christian
--
Christian Meisl
Department for Chemical Apparatus Design, Particle Technology and Combustion
Graz University of Technology
------------------------------
Date: Wed, 06 Jun 2001 15:36:51 GMT
From: "Todd Smith" <todd@designsouth.net>
Subject: Re: The difference between =~ and =
Message-Id: <n6sT6.118242$I5.27401830@news1.rdc1.tn.home.com>
>
> $foo = (AbcDEFGhi) ;
> $foo = tr/A-Z/a-z/ ;
> print $foo ;
>
without =~ s/// and tr/// operate on $_ and return the number of
matches/substitutions
$_ is nothing, so it returns 0 matches to $foo
-todd
------------------------------
Date: 06 Jun 2001 18:04:51 +0100
From: nobull@mail.com
Subject: Re: try ... catch
Message-Id: <u9g0ddzgi4.fsf@wcl-l.bham.ac.uk>
"Benny Van de Velde" <bvv@get.be> writes:
> Hi all,
>
> Is there also a way to use
> try {
> ......
> } catch {
> ...
> }
>
> in Perl ?
Yes, there is a module on CPAN that provides try and catch but I've
seen indications in this newsgroup that it's a bit buggy.
The builtin Perl equivalent uses eval{} and the $@ special variable.
--
\\ ( )
. _\\__[oo
.__/ \\ /\@
. l___\\
# ll l\\
###LL LL\\
------------------------------
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 1076
***************************************