Not sure where the problem is
Not sure where the problem is
am 06.09.2007 01:49:10 von Bob Woodward
I'm not sure if I have a problem with the setup of Apache or if it's
somewhere else. I'm trying to add a page counter to my site and I'm getting
some strange stuff returned from the perl script if I use it inside an html
page but if I run the script directly from the browser, it returns data and
functions properly. I've never used SSI's before but I've been learning a
lot from this little exercise. You can see the garbage at www.rkwco.com and
the run the script directly at www.rkwco.com/cgi-bin/counter.cgi.
From the garbage that is showing up, it seems like it's returning a listing
of the directory that is maintaining the counts but here's the REAL funny
part.... It's not the current contents of that directory. It shows an
entry for a "_cgi_bin_test_pl.lock" but that file has been wiped out as well
as the test.pl script that was used to generate it.
I have no idea where this information is coming from as the lock file,
again, is totally gone from the system. I've even done a "find" on the
whole system looking for a possible stragler file but none was found.
The server is a Solaris x86 version 8 and has been rebooted on a regular
basis "just to be sure."
Anyone have a clue? A rock to throw in the pond? A stick to beat the horse
with? I'd really appreciate any help I can get.
Thanks
BobW
Re: Not sure where the problem is
am 06.09.2007 11:38:39 von shimmyshack
On Sep 6, 12:49 am, "Bob Woodward" wrote:
> I'm not sure if I have a problem with the setup of Apache or if it's
> somewhere else. I'm trying to add a page counter to my site and I'm getting
> some strange stuff returned from the perl script if I use it inside an html
> page but if I run the script directly from the browser, it returns data and
> functions properly. I've never used SSI's before but I've been learning a
> lot from this little exercise. You can see the garbage atwww.rkwco.comand
> the run the script directly atwww.rkwco.com/cgi-bin/counter.cgi.
>
> From the garbage that is showing up, it seems like it's returning a listing
> of the directory that is maintaining the counts but here's the REAL funny
> part.... It's not the current contents of that directory. It shows an
> entry for a "_cgi_bin_test_pl.lock" but that file has been wiped out as well
> as the test.pl script that was used to generate it.
>
> I have no idea where this information is coming from as the lock file,
> again, is totally gone from the system. I've even done a "find" on the
> whole system looking for a possible stragler file but none was found.
>
> The server is a Solaris x86 version 8 and has been rebooted on a regular
> basis "just to be sure."
>
> Anyone have a clue? A rock to throw in the pond? A stick to beat the horse
> with? I'd really appreciate any help I can get.
>
> Thanks
> BobW
until we see the code responsible for the output we cant tell why the
output is wrong, perhaps it stores a temp file so that it can add 1 to
it to show the new amount - and this aspect went wrong originally and
is preventing sensible operation of the script.
Also theres a bit of dodgy html there, METHODS for instance shuld be
METHOD
Re: Not sure where the problem is
am 06.09.2007 17:44:21 von shimmyshack
On Sep 6, 10:38 am, shimmyshack wrote:
> On Sep 6, 12:49 am, "Bob Woodward" wrote:
>
>
>
> > I'm not sure if I have a problem with the setup of Apache or if it's
> > somewhere else. I'm trying to add a page counter to my site and I'm getting
> > some strange stuff returned from the perl script if I use it inside an html
> > page but if I run the script directly from the browser, it returns data and
> > functions properly. I've never used SSI's before but I've been learning a
> > lot from this little exercise. You can see the garbage atwww.rkwco.comand
> > the run the script directly atwww.rkwco.com/cgi-bin/counter.cgi.
>
> > From the garbage that is showing up, it seems like it's returning a listing
> > of the directory that is maintaining the counts but here's the REAL funny
> > part.... It's not the current contents of that directory. It shows an
> > entry for a "_cgi_bin_test_pl.lock" but that file has been wiped out as well
> > as the test.pl script that was used to generate it.
>
> > I have no idea where this information is coming from as the lock file,
> > again, is totally gone from the system. I've even done a "find" on the
> > whole system looking for a possible stragler file but none was found.
>
> > The server is a Solaris x86 version 8 and has been rebooted on a regular
> > basis "just to be sure."
>
> > Anyone have a clue? A rock to throw in the pond? A stick to beat the horse
> > with? I'd really appreciate any help I can get.
>
> > Thanks
> > BobW
>
> until we see the code responsible for the output we cant tell why the
> output is wrong, perhaps it stores a temp file so that it can add 1 to
> it to show the new amount - and this aspect went wrong originally and
> is preventing sensible operation of the script.
> Also theres a bit of dodgy html there, METHODS for instance shuld be
> METHOD
according to eric lawrence of fiddler fame, the server is returning
null bytes in the middle of the response. Neither IE, nor Firefox have
a problem displaying the rest of the data including the error message
from your script, but as to why this is happening, suggest you delete
and reinstate the script, and finally check the script encoding in
your editor, and make sure you are following SSI syntax precisely,
post your code for more help
Re: Not sure where the problem is
am 06.09.2007 20:22:33 von Bob Woodward
"shimmyshack" wrote in message
news:1189093461.694531.76580@57g2000hsv.googlegroups.com...
> On Sep 6, 10:38 am, shimmyshack wrote:
> > On Sep 6, 12:49 am, "Bob Woodward" wrote:
> >
> >
> >
> > > I'm not sure if I have a problem with the setup of Apache or if it's
> > > somewhere else. I'm trying to add a page counter to my site and I'm
getting
> > > some strange stuff returned from the perl script if I use it inside an
html
> > > page but if I run the script directly from the browser, it returns
data and
> > > functions properly. I've never used SSI's before but I've been
learning a
> > > lot from this little exercise. You can see the garbage
atwww.rkwco.comand
> > > the run the script directly atwww.rkwco.com/cgi-bin/counter.cgi.
> >
> > > From the garbage that is showing up, it seems like it's returning a
listing
> > > of the directory that is maintaining the counts but here's the REAL
funny
> > > part.... It's not the current contents of that directory. It shows
an
> > > entry for a "_cgi_bin_test_pl.lock" but that file has been wiped out
as well
> > > as the test.pl script that was used to generate it.
> >
> > > I have no idea where this information is coming from as the lock file,
> > > again, is totally gone from the system. I've even done a "find" on
the
> > > whole system looking for a possible stragler file but none was found.
> >
> > > The server is a Solaris x86 version 8 and has been rebooted on a
regular
> > > basis "just to be sure."
> >
> > > Anyone have a clue? A rock to throw in the pond? A stick to beat the
horse
> > > with? I'd really appreciate any help I can get.
> >
> > > Thanks
> > > BobW
> >
> > until we see the code responsible for the output we cant tell why the
> > output is wrong, perhaps it stores a temp file so that it can add 1 to
> > it to show the new amount - and this aspect went wrong originally and
> > is preventing sensible operation of the script.
> > Also theres a bit of dodgy html there, METHODS for instance shuld be
> > METHOD
>
> according to eric lawrence of fiddler fame, the server is returning
> null bytes in the middle of the response. Neither IE, nor Firefox have
> a problem displaying the rest of the data including the error message
> from your script, but as to why this is happening, suggest you delete
> and reinstate the script, and finally check the script encoding in
> your editor, and make sure you are following SSI syntax precisely,
> post your code for more help
>
Here's the line in the html file that calls the script:
As for the script itself, this is it:
#!/usr/bin/perl
############################################################ ################
##
# TextCounter Version 1.2.1
#
# Copyright 1996-98 Matt Wright mattw@scriptarchive.com
#
# Created 3/14/96 Last Modified 6/24/98
#
# Scripts Archive at: http://www.scriptarchive.com/
#
############################################################ ################
##
# COPYRIGHT NOTICE
#
# Copyright 1996-98 Matthew M. Wright All Rights Reserved.
#
#
#
# TextCounter may be used and modified free of charge by anyone so long as
#
# this copyright notice and the comments above remain intact. By using this
#
# code you agree to indemnify Matthew M. Wright from any liability that
#
# might arise from its use.
#
#
#
# Selling the code for this program without prior written consent is
#
# expressly forbidden. In other words, please ask first before you try and
#
# make money off of my program.
#
#
#
# Obtain permission before redistributing this software over the Internet or
#
# in any other medium. In all cases copyright and header must remain
intact.#
############################################################ ################
##
# Define Variables
# Data Dir is the directory on your server that you wish to store the
# count files in. Each page that has the counter on it will have it's own
# file.
$data_dir = "/d2/www/counters/";
# Valid-URI allows you to set up the counter to only work under specific
# directories on your server. Include any of these directories as they
# appear in a URI, into this array. More information on URI's available in
# README.
@valid_uri = ('/');
# Invalid-URI allows the owner of this script to set up the counter so
# that certain portions of the web server that may be included in Valid-URI
# cannot use the program. Leave this commented out if you wish not to
# block out certain parts.
#@invalid_uri = ('.shtml/','.html/');
############################################################ ################
##
# Set Options
# Show Link allows you to add a link around the counter to point to
# either instructions explaining to users how to set this up on the system
# (useful if a system administrator wants to allow anyone to set things up
# themselves). Setting it to 0 will make no link, otherwise put the URL
# you want linked to the count here.
$show_link = "http://www.scriptarchive.com/";
# When Auto-Create is enabled, users will be able to auto-create the
# count on their home pages by simply imbedding the Server Side Includes
# call. Setting auto_create to 1 enables it, 0 will disable it. Only
# users in @valid_uri will be allowed to auto create.
$auto_create = "1";
# Show Date will show the date of when the count began if you set this
# option to 1. It will appear in yor document as [Count] hits since [Date].
# Set this to 0 and it will simply return the [Count].
$show_date = "1";
# Lock Seconds will define the number of seconds the script should sit
# and wait for the lock file to be gone before it will overwrite it if it
# is still there. Every now and then a user will interrupt a page, causing
# the script to halt and leave a lock file in place before the lock file
# could be removed. This defines how long it waits.
$lock_sec = "3";
# Padding Size define how many numbers will be shown as your count. For
# instance, if you want your count to say 00065 and have the zeros padded
# up to five digits, then set $pad_size = "5"; If the number goes higher
# than the pad_size, don't worry, there just won't be any zero's tacked
# onto the front.
$pad_size = "5";
############################################################ ################
##
# Print Content Type Header For Browser
print "Content-type: text/html\n\n";
# Get the page location from the DOCUMENT_URI environment variable.
#$count_page = "$ENV{'DOCUMENT_URI'}";
$count_page = "$ENV{'REQUEST_URI'}";
# Check Valid-URI to make sure user can use this program.
&check_uri;
# Chop off any trailing /'s
if ($count_page =~ /\/$/) {
chop($count_page);
}
# Any characters that are not letters or numbers are turned into an
underscore
$count_page =~ s/[^\w]/_/g;
$lock_file = "$count_page\.lock";
# Check to see if file is locked by program already in use.
&check_lock($lock_sec);
# If the file exists, get the date and count out of it. Otherwise, if
# auto_create is allowed, create a new account. If neither of these are
# true, return an error.
if (-e "$data_dir$count_page") {
open(COUNT,"$data_dir$count_page");
$line = ;
chop($line) if $line =~ /\n$/;
close(COUNT);
($date,$count) = split(/\|\|/,$line);
}
elsif ($auto_create == 1) {
&create;
}
else {
&error('page_not_found');
}
# Increment Count.
$count++;
$print_count = $count;
# Get Count Length for use in padding.
$count_length = length($count);
# Pad the number if it is smaller than $pad_size.
for ($i = $pad_size;$i > $count_length;$i--) {
$print_count = "0$print_count";
}
# Print the Count, Link and Date depending on what user has specified
# they wish to print.
if ($show_date == 1) {
if ($show_link =~ /http:\/\//) {
print " hits since $date";
}
else {
print "$print_count hits since $date";
}
}
else {
if ($show_link =~ /http:\/\//) {
print "";
}
else {
print "$print_count";
}
}
# Open the count file and write the new count that has been incremented.
open(COUNT,">$data_dir$count_page") || &error('could_not_increment');
print COUNT "$date\|\|$count";
close(COUNT);
# Remove Lock File for next time script is run on that HTML page.
&clean_up;
sub check_uri {
$uri_check = "0";
foreach $uri (@valid_uri) {
# if ($ENV{'DOCUMENT_URI'} =~ /$uri/) {
if ($ENV{'REQUEST_URI'} =~ /$uri/) {
$uri_check = "1";
last;
}
}
foreach $uri (@invalid_uri) {
# if ($ENV{'DOCUMENT_URI'} =~ /$uri/) {
if ($ENV{'REQUEST_URI'} =~ /$uri/) {
$uri_check = "0";
last;
}
}
if ($uri_check == 0) {
&error('bad_uri');
}
}
sub create {
($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime(time);
@months = ("January","February","March","April","May","June","July",
"August","September","October","November","December");
$year += 1900;
$date = "$months[$mon] $mday, $year";
$count = "0";
open(COUNT,">$data_dir$count_page") || &error('count_not_created');
print COUNT "$date\|\|$count";
close(COUNT);
}
sub error {
$error = shift(@_);
if ($error eq 'page_not_found') {
print "[TextCounter Fatal Error: This Page Not Found\; Auto-Create
Option Disabled]";
}
elsif ($error eq 'bad_uri') {
print "[TextCounter Fatal Error: This Page Not In Valid URI]";
}
elsif ($error eq 'count_not_created') {
print "[TextCounter Fatal Error: Could Not Write to File
$datadir$count_page]";
}
elsif ($error eq 'could_not_increment') {
print "[TextCounter Fatal Error: Could Not Increment Counter]";
}
exit;
}
sub check_lock {
$time = $_[0];
for ($i = 1;$i <= $time; $i++) {
if (-e "$data_dir$lock_file") {
sleep 1;
}
else {
open(LOCK,">$data_dir$lock_file");
print LOCK "0";
close(LOCK);
last;
}
}
}
sub clean_up {
unlink("$data_dir$lock_file");
}
Re: Not sure where the problem is
am 09.09.2007 03:09:57 von Bob Woodward
So how about a pointer or even where else to ask my question? Anyone?
Re: Not sure where the problem is
am 09.09.2007 04:16:28 von melsonr
In article <13e6hu1mpf1jta5@corp.supernews.com>,
"Bob Woodward" writes:
> So how about a pointer or even where else to ask my question? Anyone?
>
>
This isn't the answer you want, but I'd suggest you post this
to comp.lang.perl.misc - lots of very good perl programmers/scripters
hang out there and you're likely to get more help more quickly
there than here.
Looking over your perl script, I assume your problem occurs
in the block where you define and open COUNT for reading,
read a line and truncate it before further use.
It's been a while since I last did anything serious with perl,
but it seems to me that you'd be better off using the string
concatenation operator (".") in defining your filename:
$foo = $data_dir . $count_page;
or
$foo = $data_dir . "/" . $count_page;
and not slurping in the entire contents of the file with the
$line = (see my comment below) (replace it with a
simple while loop and test each line before continuing).
Something like:
while (!eof())
{
read a line;
if(test line)
{
process line;
close();
break;
}
}
I'd also use "chomp", which, as I recall, is guaranteed to
remove the EOL, so your script would read:
chomp($line);
without needing the following test;
What appears to me to be happening is that your script is
reading beyond the end of the file you define as
$data_dir$count_page - could be because it's not properly
named, could be for any of a number of reasons. You might
want to use perl's debugger to step through the script
under no load.
Check, too, on the syntax of your open statement and be sure
to add a "die" or a "carp" statement following:
open(COUNT,"$foo") or die "couldn't open $foo\n";
Hope this helps, although I think the best advice would be
to go to the comp.lang.perl.misc newsgroup.
Bob Melson
--
Robert G. Melson | Rio Grande MicroSolutions | El Paso, Texas
-----
"People unfit for freedom---who cannot do much with it---are
hungry for power." ---Eric Hoffer
Re: Not sure where the problem is
am 11.09.2007 20:57:10 von Bob Woodward
"Robert Melson" wrote in message
news:13e6lrs2a8uvrcd@corp.supernews.com...
> In article <13e6hu1mpf1jta5@corp.supernews.com>,
> "Bob Woodward" writes:
> > So how about a pointer or even where else to ask my question? Anyone?
> >
> >
> This isn't the answer you want, but I'd suggest you post this
> to comp.lang.perl.misc - lots of very good perl programmers/scripters
> hang out there and you're likely to get more help more quickly
> there than here.
Thanks, Bob, but any suggestions are welcome. The reason I'm in this
newsgroup, though, is that if I use my browser to go to the perl script
directly, I get the results I'm expecting. It's when I try to use the
script in an HTML page that it goes to hell in a hand basket. I'll check
into the comp.lang.perl.misc newsgroup, too. In the mean time I've decided
to try and upgrade the Apache server to the pre-compiled version 2.2.4 for
Solaris 8 but I'm having trouble with the required patch 112439-02 which is
the random service that SSL needs.
If nothing else, this is proving to be one hell of a learning experience!
As for your remaining suggestions, I've printed them out and will look into
how they can affect my script later. I appreciate your suggestions a lot!
Thank you.
> [snip to shorten the message]
Re: Not sure where the problem is
am 11.09.2007 21:49:14 von melsonr
In article <13edp7q8mooat6e@corp.supernews.com>,
"Bob Woodward" writes:
> "Robert Melson" wrote in message
> news:13e6lrs2a8uvrcd@corp.supernews.com...
>> In article <13e6hu1mpf1jta5@corp.supernews.com>,
>> "Bob Woodward" writes:
>> > So how about a pointer or even where else to ask my question? Anyone?
>> >
>> >
>> This isn't the answer you want, but I'd suggest you post this
>> to comp.lang.perl.misc - lots of very good perl programmers/scripters
>> hang out there and you're likely to get more help more quickly
>> there than here.
>
> Thanks, Bob, but any suggestions are welcome. The reason I'm in this
> newsgroup, though, is that if I use my browser to go to the perl script
> directly, I get the results I'm expecting. It's when I try to use the
> script in an HTML page that it goes to hell in a hand basket. I'll check
> into the comp.lang.perl.misc newsgroup, too. In the mean time I've decided
> to try and upgrade the Apache server to the pre-compiled version 2.2.4 for
> Solaris 8 but I'm having trouble with the required patch 112439-02 which is
> the random service that SSL needs.
>
> If nothing else, this is proving to be one hell of a learning experience!
>
> As for your remaining suggestions, I've printed them out and will look into
> how they can affect my script later. I appreciate your suggestions a lot!
> Thank you.
>
>> [snip to shorten the message]
>
>
Bob,
No matter that you're experiencing the problem when trying
to run your script in an HTML page, it appears to me to be
purely a perl problem - and probably what I suggested: that
the script is reading beyond the EOF of your counter file.
That could mean that the file hasn't been closed correctly
in a previous access or some other, more subtle problem.
That's the real reason I suggest you read the file a line
at a time, rather than slurping it in all at once. I'd
go so far as to suggest you write a small script that
does nothing but open the file, read and print each line,
closes the file and exits.
HTH,
Swell Ol' Bob
--
Robert G. Melson | Rio Grande MicroSolutions | El Paso, Texas
-----
"People unfit for freedom---who cannot do much with it---are
hungry for power." ---Eric Hoffer
Re: Not sure where the problem is
am 12.09.2007 15:55:18 von Bob Woodward
"Robert Melson" wrote in message
news:13eds9q3rc0ctf0@corp.supernews.com...
> Bob,
>
> No matter that you're experiencing the problem when trying
> to run your script in an HTML page, it appears to me to be
> purely a perl problem - and probably what I suggested: that
> the script is reading beyond the EOF of your counter file.
> That could mean that the file hasn't been closed correctly
> in a previous access or some other, more subtle problem.
> That's the real reason I suggest you read the file a line
> at a time, rather than slurping it in all at once. I'd
> go so far as to suggest you write a small script that
> does nothing but open the file, read and print each line,
> closes the file and exits.
>
> HTH,
> Swell Ol' Bob
> --
> Robert G. Melson | Rio Grande MicroSolutions | El Paso, Texas
> -----
> "People unfit for freedom---who cannot do much with it---are
> hungry for power." ---Eric Hoffer
>
I don't know how and I don't know why but it came back to the environment
variables that are only available in the Apache environment. Originally the
script used $count_page = "$ENV{'DOCUMENT_URI'}"; but when it wouldn't come
back with anything, and searching on the internet, a number of people were
recommending to use REQUEST_URI instead of DOCUMENT_URI on a Solaris 8
system. I took your suggestion to make a small script that opens a file,
reads and prints each line then close the file and exit. That worked just
fine so I start adding more and more back into the script and it broke again
when I added the REQUEST_URI line(s) back in. I finally tried using the
DOCUMENT_URI variable again and it worked. Full circle back to the original
without a clue of what I did that made it start working.
Thanks for your persistance and willingness to give narrative of what and
why's instead of one line quick answers.
Re: Not sure where the problem is
am 12.09.2007 18:22:38 von melsonr
In article <13efrsv5rftgpbf@corp.supernews.com>,
"Bob Woodward" writes:
> "Robert Melson" wrote in message
> news:13eds9q3rc0ctf0@corp.supernews.com...
> Thanks for your persistance and willingness to give narrative of what and
> why's instead of one line quick answers.
The important thing is that you've gotten the script to
work, tho' I'll agree that it'd be nice to know why. To
my mind, because you were seeing something that clearly
wasn't in the file, you had to be reading beyond EOF, but
just why that was happening I'm unable to say - the maddening
thing about computers is that they do exactly what you tell
them to do, which is often not what you want them to do.
Since you've established that the problem lies in the
environment variables, you might want to do another little
script that will read/print the values in the apache
environment. That should tell you what's being inherited
from apache, what needs to be set in the script.
Ah, well, back to my phone booth!
Super Ol' Bob
--
Robert G. Melson | Rio Grande MicroSolutions | El Paso, Texas
-----
"People unfit for freedom---who cannot do much with it---are
hungry for power." ---Eric Hoffer
Re: Not sure where the problem is
am 12.09.2007 18:25:15 von melsonr
In article <13efrsv5rftgpbf@corp.supernews.com>,
"Bob Woodward" writes:
> "Robert Melson" wrote in message
> news:13eds9q3rc0ctf0@corp.supernews.com...
Oh, 'nother thing. I suggest you find/buy a copy of the
O'Reilly "Perl Cookbook" by Tom Christiansen and Nathan
Torkington. Like most all O'Reilly books, well worth
having.
Studious Ol' Bob
--
Robert G. Melson | Rio Grande MicroSolutions | El Paso, Texas
-----
"People unfit for freedom---who cannot do much with it---are
hungry for power." ---Eric Hoffer