[18523] in Perl-Users-Digest
Perl-Users Digest, Issue: 691 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Apr 13 11:06:05 2001
Date: Fri, 13 Apr 2001 08:05: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: <987174309-v10-i691@ruby.oce.orst.edu>
Content-Type: text
Perl-Users Digest Fri, 13 Apr 2001 Volume: 10 Number: 691
Today's topics:
<defunct> problem with perl cgi DBI/mysql/apache <eve74@MailAndNews.com>
Re: A CGI question <camerond@mail.uca.edu>
CGI Problem <kev@kdpsoftware1.nospmrs.demon.co.uk>
Re: CGI Problem <joe+usenet@sunstarsys.com>
Re: CGI Problem <kev@kdpsoftware1.nospmrs.demon.co.uk>
Debugging Perl CGI scripts, was Re: CGI Problem <flavell@mail.cern.ch>
Re: Debugging Perl CGI scripts, was Re: CGI Problem <joe+usenet@sunstarsys.com>
Re: Debugging Perl CGI scripts, was Re: CGI Problem <kev@kdpsoftware1.nospmrs.demon.co.uk>
Re: Help Required <rodion@browncorp.com>
how do i suppress STDOUT <clarke@hyperformix.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 13 Apr 2001 09:16:19 -0400
From: EvE <eve74@MailAndNews.com>
Subject: <defunct> problem with perl cgi DBI/mysql/apache
Message-Id: <3AF356D8@MailAndNews.com>
Hi,
I hope I'm in the right groups, I'm apologize if I'm not.
At this moment my complete web-site is running on
linux/apache/perl/DBI/mysql
and seems to work fine. But when I take a look at the running processes with
top, I see that often cgi scripts become <defunct> for a few seconds
although
the page is appearing fine on my browser.
Even if I try a small example "by the book" this problem occurs:
== e.g. "tst" ================================================
#!/usr/bin/perl
$|=1;
use DBI;
print "Content-type: text/html\n\n";
my $_databasehandle =
DBI->connect("DBI:mysql:database=DBNAME;host=localhost",
"
DBUSER", "DBPWD");
my $_query = "SELECT field1, field2, field3 ";
$_query .= "FROM mytable ";
$_query .= "WHERE field3 IS NOT NULL";
my $sth = $_databasehandle->prepare( $_query ) or die "Couldn't prepare
statement: " . $dbh->errstr;
$sth->execute() or die "Couldn't execute statement: " . $sth->errstr;
while (@data = $sth->fetchrow_array()) {
print "$data[2] $data[1] $data[0] <BR>\n";
}
$sth->finish;
$_databasehandle->disconnect;
exit 0;
==============================================================
== top =======================================================
PID USER PRI NI SIZE RSS SHARE STAT LIB %CPU %MEM TIME COMMAND
24696 httpd 18 0 0 0 0 Z 0 40.3 0.0 0:00 tst
<defunct
24676 f1db 6 0 1052 1052 864 R 0 10.0 0.2 0:00 top
24256 httpd 6 0 10060 9.8M 9084 S 0 2.2 1.9 0:00 httpd
==============================================================
Within a second the defunct proces is gone. Sometimes I also see one of the
httpd process as <defunct> for the same amount of time.
Can anybody tell me what is going on and how to solve this? I have tried
different fetch-methods but that does not seem te be the issue here. I also
tried to find same kind of problems via google.com (old deja) but cannot
find
any solution.
I hope somebody can help me out because I do not know if my curent hoster
likes the behaviour of my current scripts.
Thanks in advance, regards,
EvE
http://www.f1db.com
------------------------------
Date: Fri, 13 Apr 2001 07:31:51 -0500
From: Cameron Dorey <camerond@mail.uca.edu>
Subject: Re: A CGI question
Message-Id: <3AD6F1B7.5212896B@mail.uca.edu>
"Randal L. Schwartz" wrote:
>
> The problem is "those meddling kids"[1] who don't play by the very
> reasonable rules.
>
> CIWAC is completely accepting of Perl questions. I've never seen
> anyone shooed away from there for asking a Perl related CGI question,
> except when they ask a "pure perl" question. And again, there's not
> enough Perl-specific CGI questions asked there to warrant a
> CIWAC.perl.
>
> The problem we have is that most people really can't tell whether it's
> a Perl question, or a CGI question. And CIWAC is slightly harder to
> find than CLPM (apparently), so CLPM seems to take the brunt of the
> mistakes.
True. I was just wondering how the "kids" were finding clpm, and if it
were through some keyword search, they might visit a ciwacp newsgroup
first. To be honest, I haven't been over to ciwac for a while now, so I
don't have any feel for just low low-volume a group it is. Thanks for
your input.
Cameron
--
Cameron Dorey
Associate Professor of Chemistry
University of Central Arkansas
Phone: 501-450-5938
camerond@mail.uca.edu
------------------------------
Date: Fri, 13 Apr 2001 13:32:18 +0100
From: "KevinPassey" <kev@kdpsoftware1.nospmrs.demon.co.uk>
Subject: CGI Problem
Message-Id: <987165401.9789.0.nnrp-01.d4e43253@news.demon.co.uk>
From: "KevinPassey" <kev@kdpsoftware1.nospmrs.demon.co.uk>
Subject: CGI problem
Date: 13 April 2001 13:23
Why do I get this---
[Fri Apr 13 13:10:06 2001] [error] [client 127.0.0.1] Premature end of
script headers: c:/program files/apache group/apache/cgi-bin/sec.pl
[Fri Apr 13 13:10:06 2001] [error] [client 127.0.0.1] Global symbol "$line"
requires explicit package name at c:/program files/apache
group/apache/cgi-bin/sec.pl line 9.
[Fri Apr 13 13:10:06 2001] [error] [client 127.0.0.1] Global symbol "$line"
requires explicit package name at c:/program files/apache
group/apache/cgi-bin/sec.pl line 11.
[Fri Apr 13 13:10:06 2001] [error] [client 127.0.0.1] Global symbol "$line"
requires explicit package name at c:/program files/apache
group/apache/cgi-bin/sec.pl line 12.
[Fri Apr 13 13:10:06 2001] [error] [client 127.0.0.1] Execution of
c:/program files/apache group/apache/cgi-bin/sec.pl aborted due to
compilation errors.
When I try to run this---
#!/usr/bin/perl -w
use CGI qw(:standard);
use strict;
print header;
open(MYFILE, "/data/accesses") || die "opening accesses: $!";
$line=<MYFILE>;
# Actually, any manipulation can be done now.
chomp $line;
print $line;
close(MYFILE);
You guessed it -- I'm new to Perl and Apache.
The apache server is running on my windows 98 pc.
Thanks in advance
KevinPassey
------------------------------
Date: 13 Apr 2001 09:01:31 -0400
From: Joe Schaefer <joe+usenet@sunstarsys.com>
Subject: Re: CGI Problem
Message-Id: <m3ae5l3qdw.fsf@mumonkan.sunstarsys.com>
"KevinPassey" <kev@kdpsoftware1.nospmrs.demon.co.uk> writes:
> [Fri Apr 13 13:10:06 2001] [error] [client 127.0.0.1] Premature end of
> script headers: c:/program files/apache group/apache/cgi-bin/sec.pl
That's a generic apache error message telling you that the script
has bailed out early.
> [Fri Apr 13 13:10:06 2001] [error] [client 127.0.0.1] Global symbol
> "$line" requires explicit package name at c:/program files/apache
> group/apache/cgi-bin/sec.pl line 9.
That's a perl error message that tells you the culprit- line 9 needs
a "my" declaration for $line (or you might need "use vars '$line';"
but usually a "my" is what you want).
[...]
> [Fri Apr 13 13:10:06 2001] [error] [client 127.0.0.1] Execution of
> c:/program files/apache group/apache/cgi-bin/sec.pl aborted due to
> compilation errors.
That's the final perl message telling you the above message was due
to a fatal compilation error. See
% perldoc perldiag
for descriptions of perl's warnings and error messages.
> #!/usr/bin/perl -w
^
T
it's a good idea to use taint checks on CGI scripts (even though
you're not processing any user input here, it's still a good habit).
If the warning messages you are getting aren't verbose enough for
you, try putting a
use diagnostics;
line in your script.
> use CGI qw(:standard);
> use strict;
>
> print header;
>
> open(MYFILE, "/data/accesses") || die "opening accesses: $!";
> $line=<MYFILE>;
^
my
You do realize that only the first line of "/data/access" is being
read into $line, right? (btw- by my count this is line 8- are you
sure you didn't accidentally delete any preceeding lines?)
HTH
--
Joe Schaefer "Whatever you are, be a good one."
-- Abraham Lincoln
------------------------------
Date: Fri, 13 Apr 2001 15:30:54 +0100
From: "KevinPassey" <kev@kdpsoftware1.nospmrs.demon.co.uk>
Subject: Re: CGI Problem
Message-Id: <987172809.21091.0.nnrp-09.d4e43253@news.demon.co.uk>
Joe,
I was only trying to put out one line - I wasn't sure if my apache server
was timing out as the actual file is quite large.
my is exactly what I needed. Sorry this was a dumb question..Once I get into
Perl a bit more hopefully my questions will be a bit more interesting.
Thanks a lot..
Kev..
"Joe Schaefer" <joe+usenet@sunstarsys.com> wrote in message
news:m3ae5l3qdw.fsf@mumonkan.sunstarsys.com...
> "KevinPassey" <kev@kdpsoftware1.nospmrs.demon.co.uk> writes:
>
> > [Fri Apr 13 13:10:06 2001] [error] [client 127.0.0.1] Premature end of
> > script headers: c:/program files/apache group/apache/cgi-bin/sec.pl
>
> That's a generic apache error message telling you that the script
> has bailed out early.
>
> > [Fri Apr 13 13:10:06 2001] [error] [client 127.0.0.1] Global symbol
> > "$line" requires explicit package name at c:/program files/apache
> > group/apache/cgi-bin/sec.pl line 9.
>
> That's a perl error message that tells you the culprit- line 9 needs
> a "my" declaration for $line (or you might need "use vars '$line';"
> but usually a "my" is what you want).
>
> [...]
>
> > [Fri Apr 13 13:10:06 2001] [error] [client 127.0.0.1] Execution of
> > c:/program files/apache group/apache/cgi-bin/sec.pl aborted due to
> > compilation errors.
>
> That's the final perl message telling you the above message was due
> to a fatal compilation error. See
>
> % perldoc perldiag
>
> for descriptions of perl's warnings and error messages.
>
> > #!/usr/bin/perl -w
> ^
> T
> it's a good idea to use taint checks on CGI scripts (even though
> you're not processing any user input here, it's still a good habit).
> If the warning messages you are getting aren't verbose enough for
> you, try putting a
>
> use diagnostics;
>
> line in your script.
>
> > use CGI qw(:standard);
> > use strict;
> >
> > print header;
> >
> > open(MYFILE, "/data/accesses") || die "opening accesses: $!";
> > $line=<MYFILE>;
> ^
> my
>
> You do realize that only the first line of "/data/access" is being
> read into $line, right? (btw- by my count this is line 8- are you
> sure you didn't accidentally delete any preceeding lines?)
>
>
> HTH
> --
> Joe Schaefer "Whatever you are, be a good one."
> -- Abraham Lincoln
------------------------------
Date: Fri, 13 Apr 2001 15:26:15 +0200
From: "Alan J. Flavell" <flavell@mail.cern.ch>
Subject: Debugging Perl CGI scripts, was Re: CGI Problem
Message-Id: <Pine.LNX.4.30.0104131505580.16315-100000@lxplus003.cern.ch>
On 13 Apr 2001, Joe Schaefer wrote:
> That's a perl error message that tells you the culprit- line 9 needs
> a "my" declaration for $line
It would seem that the hon. Usenaut isn't first testing their script
from the command line, but is uploading it, untested, directly to the
server and only then testing it via the CGI interface. This is
sub-optimal IMHO.
CGI.pm supports a convenient command-line debugging style, which can
at least get the major bugs ironed out _before_ resorting to the
server.
While it's true that the hon Usenaut will need to learn to use the
server diagnostics to deal with more-obscure kinds of problem that
might arise, and I'm sure your advice would be helpful in that regard
(although the relevant FAQs on debugging CGIs would arm the hon
usenaut for a wider range of potential problems), I would strongly
recommend eliminating the more gross errors by getting into the habit
of debugging at the command line first.
A good starting point is
http://www.smithrenaud.com/public/CGI_MetaFAQ.html
The "idiot's guide" linked from there can serve as a useful checklist
for the more crass CGI errors.
------------------------------
Date: 13 Apr 2001 10:07:07 -0400
From: Joe Schaefer <joe+usenet@sunstarsys.com>
Subject: Re: Debugging Perl CGI scripts, was Re: CGI Problem
Message-Id: <m33dbc51x0.fsf@mumonkan.sunstarsys.com>
"Alan J. Flavell" <flavell@mail.cern.ch> writes:
> While it's true that the hon Usenaut will need to learn to use the
> server diagnostics to deal with more-obscure kinds of problem that
> might arise, and I'm sure your advice would be helpful in that regard
> (although the relevant FAQs on debugging CGIs would arm the hon
> usenaut for a wider range of potential problems), I would strongly
> recommend eliminating the more gross errors by getting into the habit
> of debugging at the command line first.
>
> A good starting point is
> http://www.smithrenaud.com/public/CGI_MetaFAQ.html
>
> The "idiot's guide" linked from there can serve as a useful checklist
> for the more crass CGI errors.
Point well made/taken. Thanks for the correction.
--
Joe Schaefer "Grief can take care of itself, but to get the full value from
joy you must have someone to divide it with."
--Mark Twain
------------------------------
Date: Fri, 13 Apr 2001 15:36:25 +0100
From: "KevinPassey" <kev@kdpsoftware1.nospmrs.demon.co.uk>
Subject: Re: Debugging Perl CGI scripts, was Re: CGI Problem
Message-Id: <987172810.21091.1.nnrp-09.d4e43253@news.demon.co.uk>
Thanks for that Alan.
Kev
"Alan J. Flavell" <flavell@mail.cern.ch> wrote in message
news:Pine.LNX.4.30.0104131505580.16315-100000@lxplus003.cern.ch...
> On 13 Apr 2001, Joe Schaefer wrote:
>
> > That's a perl error message that tells you the culprit- line 9 needs
> > a "my" declaration for $line
>
> It would seem that the hon. Usenaut isn't first testing their script
> from the command line, but is uploading it, untested, directly to the
> server and only then testing it via the CGI interface. This is
> sub-optimal IMHO.
>
> CGI.pm supports a convenient command-line debugging style, which can
> at least get the major bugs ironed out _before_ resorting to the
> server.
>
> While it's true that the hon Usenaut will need to learn to use the
> server diagnostics to deal with more-obscure kinds of problem that
> might arise, and I'm sure your advice would be helpful in that regard
> (although the relevant FAQs on debugging CGIs would arm the hon
> usenaut for a wider range of potential problems), I would strongly
> recommend eliminating the more gross errors by getting into the habit
> of debugging at the command line first.
>
> A good starting point is
> http://www.smithrenaud.com/public/CGI_MetaFAQ.html
>
> The "idiot's guide" linked from there can serve as a useful checklist
> for the more crass CGI errors.
>
------------------------------
Date: Fri, 13 Apr 2001 10:25:37 -0400
From: "Rodion Serebryakov" <rodion@browncorp.com>
Subject: Re: Help Required
Message-Id: <3ad70bc7@usenet.ugs.com>
Perl has nothing to do with it.
You should be able to change settings in your http server configuration to
set MIME type of files with .pdf extension.
For Apache the directive you want to look up is AddType
AddType application/octet-stream .pdf
There is no guarantee that this will work, since the browser may choose to
ignore the MIME type and make its decision on how to handle the file based
on its extension.
Rodion
"Cameron Dorey" <camerond@mail.uca.edu> wrote in message
news:3AD61235.D3A13C13@mail.uca.edu...
> Umair Bajwa wrote:
> >
> > I would like to provide a link for the users to download the file into
> > their home directory. In the code if I use file name <filename>.etx it
> > works fine. But if I use <filename>.pdf it runs the acrobat reader and
> > open the file right into it.
> > Does any one have any idea instead of opening into the acrobat reader
> > how should i force the perl to pop up the window and ask for the file
> > name. Thanks in advance
> >
> > Umair
>
> Pure and simple, you can't unless you rename the extension. Their
> browser is going to do whatever it wants with the file.
>
> Cameron
>
> --
> Cameron Dorey
> Associate Professor of Chemistry
> University of Central Arkansas
> Phone: 501-450-5938
> camerond@mail.uca.edu
------------------------------
Date: Fri, 13 Apr 2001 08:48:43 -0500
From: "ac" <clarke@hyperformix.com>
Subject: how do i suppress STDOUT
Message-Id: <1sDB6.374$Ra.97585@news.uswest.net>
I have an application which is emitting unwanted "debug like" text to the
console
(OS command line). The problem is that I don't have access to the code (its
probably a Win32 dll thats part of drag-n-drop in Tk).
How can I suppress STDOUT during certain function calls so the users of my
application don't see this stuff?
Allan
------------------------------
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 691
**************************************
