PERL Miscellaneous - testing without shell access

Author

testing without shell access

Dan

2004-08-12, 3:58 am

Hi,

A perspective client wants me to develop their website, but wants to use a
particular web hosting service.

The probelm is that the hosting service provides no shell access, so I have
no way to test and debug the Perl scripts once I've uploaded them to the
hosting service.

The service is running Perl 5.6 and apache 1.3.28 under Lynux. My PC is
running Windows 98 Second Edition. The service they want to use will cost
about one third the monthly cost of the hosting service I've used for my
other clients.

Can anyone suggest how I can solve the testing/ debugging problem?

Thanks,
Dan
news.groups@earthlink.net

Gunnar Hjalmarsson

2004-08-12, 3:58 am

Dan wrote:
> The probelm is that the hosting service provides no shell access,
> so I have no way to test and debug the Perl scripts once I've
> uploaded them to the hosting service.
>
> The service is running Perl 5.6 and apache 1.3.28 under Lynux. My
> PC is running Windows 98 Second Edition.

<snip>

> Can anyone suggest how I can solve the testing/ debugging problem?

If you haven't already, install Perl + apache on your PC. The most
convenient way to do so is to install this package:
http://www.indigostar.com/indigoperl.htm

Do the principal testing and debugging locally before uploading.

Then, include this line:

use CGI::Carp 'fatalsToBrowser'

in the beginning of the Perl scripts. It will have fatal errors
printed to the screen.

--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl

Gregory Toomey

2004-08-12, 9:05 am

Dan wrote:

> Hi,
>
> A perspective client wants me to develop their website, but wants to use a
> particular web hosting service.
>
> The probelm is that the hosting service provides no shell access, so I
> have no way to test and debug the Perl scripts once I've uploaded them to
> the hosting service.
>

Ditch the client or hosting service.

Developinmg Perl on unix/linux without shell access is laughable.

gtoomey

Sherm Pendley

2004-08-12, 9:05 am

Dan wrote:

> The probelm is that the hosting service provides no shell access, so I have
> no way to test and debug the Perl scripts once I've uploaded them to the
> hosting service.

Doing development, testing, and debugging on a live production server
isn't a good idea anyway. The scripts should be tested and debugged
before you upload them.

> The service is running Perl 5.6 and apache 1.3.28 under Lynux.

Ouch. Their apache isn't too horribly out of date - but that Perl is
*ancient*. You should ask them if they'll update to something from this
millennium. (That's only a slight exaggeration - 5.6 was released in
March 2000, which *barely* qualifies it as being from this millennium.)

> Can anyone suggest how I can solve the testing/ debugging problem?

Your best bet is to install Linux and apache on your PC, mirroring the
server environment as closely as you can. If you're not up to that, your
second-best bet is to install apache and Perl under Windows.

sherm--

--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org

Two Heads

2004-08-12, 9:05 am

On Thu, 12 Aug 2004 07:04:22 GMT, "Dan" <news.groups@earthlink.net>
wrote:

>Hi,
>
>A perspective client wants me to develop their website, but wants to use a
>particular web hosting service.
>
>The probelm is that the hosting service provides no shell access, so I have
>no way to test and debug the Perl scripts once I've uploaded them to the
>hosting service.
>
>The service is running Perl 5.6 and apache 1.3.28 under Lynux. My PC is
>running Windows 98 Second Edition. The service they want to use will cost
>about one third the monthly cost of the hosting service I've used for my
>other clients.
>
>Can anyone suggest how I can solve the testing/ debugging problem?
>
>Thanks,
>Dan
>news.groups@earthlink.net
>
Hi,

I do a lot of work on shared hosted accounts without shell access and,
as Gunar said if you include some diagnostic commands at the start of
the script it will give some error reporting. I insert the following
code when debugging, after the shebang line. As well as giving a
message in the browser it prints detailed information in the file
scriptErr.txt

# Remove this when errors are resolved
use diagnostics -verbose; #print warning diagnostics
use CGI qw(:standard);
use CGI::Carp qw(fatalsToBrowser);
BEGIN {
print CGI::header();
open (STDERR, '>scriptErr.txt');
}

I also collect test values of variables thoughout the program so I can
see what is going on

$debug.="Client $client<br>";

and then print the values stored in $debug to the browser or write
them to a file.

I have running on windows Open Perl IDE which enables you to run
scripts and gives error output, but of course it can only be used for
limited testing for scripts that do not call on resources store on the
server.

I recently upgraded to the latest version of Indigostar and found that
it did not support the diagnostics module used in the above code, I
haven't solved that problem yet.

Cheers,
Mark

A. Sinan Unur

2004-08-12, 9:05 am

Two Heads <twoheads@NOSPAMtiscali.co.uk> wrote in
news:eqfmh0pb6pfunj5rbe02qns5rveimn5ihl@
4ax.com:

> On Thu, 12 Aug 2004 07:04:22 GMT, "Dan" <news.groups@earthlink.net>

> # Remove this when errors are resolved
> use diagnostics -verbose; #print warning diagnostics

I don't see

use strict;

diagnostics automatically turns on warnings, but lack of strict will
impede you.

> use CGI qw(:standard);
> use CGI::Carp qw(fatalsToBrowser);
> BEGIN {
> print CGI::header();
> open (STDERR, '>scriptErr.txt');
> }
>
....

Just make sure those files are not left floating around in your web
directory.

--
A. Sinan Unur
1usa@llenroc.ude.invalid
(remove '.invalid' and reverse each component for email address)

Tad McClellan

2004-08-12, 4:04 pm

Two Heads <twoheads@NOSPAMtiscali.co.uk> wrote:

> open (STDERR, '>scriptErr.txt');

You should always, yes *always*, check the return value from open():

open (STDERR, '>scriptErr.txt') or die "could not open 'scriptErr.txt' $!";
or
open (STDERR, '>scriptErr.txt') or carp "could not open 'scriptErr.txt' $!";

--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas

Tad McClellan

2004-08-12, 4:04 pm

Sherm Pendley <spamtrap@dot-app.org> wrote:
> Dan wrote:

>
> Your best bet is to install Linux and apache on your PC, mirroring the
> server environment as closely as you can. If you're not up to that, your
> second-best bet is to install apache and Perl under Windows.

And if you must "serve Bill", then be sure to use "ASCII" or "text"
mode when FTPing your programs to the server.

--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas

Chris Mattern

2004-08-13, 3:56 am

Sherm Pendley wrote:
> *ancient*. You should ask them if they'll update to something from this
> millennium. (That's only a slight exaggeration - 5.6 was released in
> March 2000, which *barely* qualifies it as being from this millennium.)
>
Nope. The second millennium ended December 31, 2000, so it is indeed from
the last millennium.
--
Christopher Mattern

"Which one you figure tracked us?"
"The ugly one, sir."
"...Could you be more specific?"

Joe Smith

2004-08-13, 3:57 pm

Tad McClellan wrote:

> You should always, yes *always*, check the return value from open():
> open (STDERR, '>scriptErr.txt') or die "could not open 'scriptErr.txt' $!";

open(STDERR,'>','scriptErr.txt') or die "Since STDERR is not open, you will
never see this message when die() is invoked, so you might as well give up."

or

my $log = 'no_such_directory/log'; # For testing failure mode
open(OLDSTDERR,'>&STDERR') or die "Unable to dup STDERR";
unless(open(STDERR,'>',$log)) {
print OLDSTDERR "Redirecting STDERR to $log failed: $!\n";
exit 1;
}
warn "This goes to the file '$log'\n";

-Joe

Tad McClellan

2004-08-13, 3:57 pm

Joe Smith <Joe.Smith@inwap.com> wrote:
> Tad McClellan wrote:
>
>
> open(STDERR,'>','scriptErr.txt') or die "Since STDERR is not open,

It might be open.

Failing to re-open does not mean that it is not opened at all, just
that it isn't going to go where you wanted it to go.

--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas

Ben Morrow

2004-08-14, 3:58 pm

Quoth Joe Smith <Joe.Smith@inwap.com>:
> Tad McClellan wrote:
>
>
> open(STDERR,'>','scriptErr.txt') or die "Since STDERR is not open, you will
> never see this message when die() is invoked, so you might as well give up."

....except that Perl keeps STDERR open to its old place if the open
fails. AFAICT this only applies to the STD filehandles.

Ben

--
"If a book is worth reading when you are six, * ben@morrow.me.uk
it is worth reading when you are sixty." - C.S.Lewis

Scott W Gifford

2004-08-16, 3:56 am

"Dan" <news.groups@earthlink.net> writes:

[...]

> The probelm is that the hosting service provides no shell access, so I have
> no way to test and debug the Perl scripts once I've uploaded them to the
> hosting service.

I frequently use a small shell script in this situation, which does
something like:

#!/bin/sh -x

printf "Content-type: text/plain\n\n"
exec 2>&1
exec ./myscript.cgi

I would name this script something like "myscript.debug", and if the
script isn't running right or won't compile, I would point my browser
to myscript.debug instead of myscript.cgi to see what errors and
warnings Perl is printing. Sometimes I'll throw an "env" in there so
I can see what environment variables apache is setting.

If you can find where the error log is, you could also write a small
script that displays the last 50-100 lines of the error log, which you
could look at to see what errors your script was producing.

-----ScottG.

Tony Muler

2004-08-16, 3:56 am

Gregory Toomey wrote:

> Dan wrote:
>
>
>
>
> Ditch the client or hosting service.
>
> Developinmg Perl on unix/linux without shell access is laughable.

Why?

To my mind, developing anything on a production environment
is not good. It is not a bad thing to force developers
to develop and debug on a local system and upload when
everything is working fine.

(Just wondering if they upload everything with execution permission.)

I would go for a Linux and apache environment for doing the
development in. Installing the Perl 5.6 in co-existance with
an up-to-date version and simillar for apache would allow
to prevent errors based on different versions in development
and production environment. Give it a go, you will have fun.

T.

Patrice Auffret

2004-08-16, 3:56 am

On Fri, 13 Aug 2004 12:28:38 GMT
Joe Smith <Joe.Smith@inwap.com> wrote:

> Tad McClellan wrote:
>
> 'scriptErr.txt' $!";
>
> open(STDERR,'>','scriptErr.txt') or die "Since STDERR is not open, you
> will
> never see this message when die() is invoked, so you might as well give
> up."
[..]

What is the problem with the first die error message ? Shouldn't it be
better to understand the problem by simply reading `$!' (and not by
trying to guess by hand what the problem may be) ?

Joe Smith

2004-08-28, 8:56 pm

Patrice Auffret wrote:

>
> What is the problem with the first die error message ? Shouldn't it be
> better to understand the problem by simply reading `$!' (and not by
> trying to guess by hand what the problem may be) ?

The point I was trying to make is that die() sends its result to STDERR.
If the open for STDERR failed, and if perl did not reset it back to
its original state, when text written to STDERR would not be seen.

I've been informed that perl does reset STDERR in this case, so
my objection is irrelevant.
-Joe

Sponsored Links