Re: Still Not sure if I agree with myself.
On Thu, 11 Sep 2003 at 14:13, drieux opined:
[snip]
d: sub should { defined($REQ_PARAMS-{$_[0]}); }
d:
d: sub doDaemon {
d:
d: }
d: sub kickDaemon { $me=shift; $me-doDaemon(@_); }
d: # the synonym trick...
d:
d:Which still gives me a HASH to manage, plus the actual Sub.
true, but you can use the hash for more than just a way to determine if a
called method exists. for an example, take a look at my form checker
tutorial:
http://www.peacecomputers.com/form_checker/
you'll see the %REQ_PARAMS hash lists each parameter it expects to receive
for every action, and also provides some basic criteria that each
parameter must pass to be considered acceptable.
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
allow CGI to write on my HDD
Hi,
My cgi script has been written in order to collect some parameters (with the
POST method) but actually if I want to record them, I can just put them in a
pre-existent file. I am unable to create a new file, even with a 'chmod 777'
on my directory...
I would have a result like this:
#test.cgi##
$name=$$.$var;
if ( ! -f ./$name){
open (OUT,$name);
}
foreach $i (@DATA){
...
print OUT $i\n;
...
}
close OUT;
Does anybody have an idea?
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: allow CGI to write on my HDD
Jean-Baptiste.Claude wrote:
Hi,
My cgi script has been written in order to collect some parameters
(with the POST method) but actually if I want to record them, I can
just put them in a pre-existent file. I am unable to create a new
file, even with a 'chmod 777' on my directory...
I would have a result like this:
#test.cgi##
$name=$$.$var;
if ( ! -f ./$name){
open (OUT,$name);
}
foreach $i (@DATA){
...
print OUT $i\n;
...
}
close OUT;
1. You should not make any assumptions about the current working directory
in a script like this. Always specify a full path to files.
2. You say the file is preexisting, but you're using $$ in the filename,
which is your process ID number. How is the file preexisting?
3. You need to open the file whether or not it exists. If you want to append
to the existing contents, then open in append mode.
4. Always check the return value from open().
5. Where is $var coming from? If it's coming from the client's request, you
need to be careful. Be sure to use taint mode in your script and read the
perldoc perlsec page for issues related to using tainted data.
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Want CGI script to test and start daemon - was Re: CGI problem, please help
On Friday, Sep 12, 2003, at 00:47 US/Pacific, [EMAIL PROTECTED]
wrote:
Sergey,
ah, I see, you are new to the Ungainly Art, of not
only programming, which you are doing well in, but
the more Arcane art of Daemonology. So bear with me
while I try to write some 'back and fill' here.
A part of the problem is that many people see this
same basic 'design pattern' -
if I had a server that could do foo
then all I need to do is test that it is up...
[..]
Here is my 'grown up' server.cgi:
[..]
basically a good piece of code. The problem seems to
a. how to check that the server is running
b. how to get the server to run as a daemon
c. how to tie those two together.
d. once started how does one stop the server?
you basic strategy so far is to try to use
a pid file - which is mostly ok-ish, but has
the problem
what if the pid file exists,
and has a PID in it, Does that
prove that the PID is
a. still alive
b. still our server
This is a classic 'oopsie' almost everyone makes.
They presume that since they can read the PID file
and it is some positive integer, that clearly the
Daemon is alive. What one needs is a
process grovelor - that will check the process table
and see what comes back.
my $line = `ps -p $pid`
eg:
[jeeves: 7:] perl -e 'my $pid = 665; my $server='WebServer'; my $line
= `ps -p $pid` ; print OK\n if $line =~/$server/g; '
OK
[jeeves: 8:]
there really is a mini-web-server running on jeeves as pid 665:
[jeeves: 3:] ps -p 665
PID TT STAT TIME COMMAND
665 p3 S+ 0:01.47 perl -w ./WebServer.plx
[jeeves: 4:]
The second test is to change the $pid value and notice that
it will not work that way:
[jeeves: 8:] perl -e 'my $pid = 660; my $server='WebServer'; my
$line = `ps -p $pid` ; print OK\n if $line =~/$server/g; '
[jeeves: 9:] ps -p 660
PID TT STAT TIME COMMAND
660 p3 S 0:00.06 -csh (csh)
[jeeves: 10:]
I take you on this side because of the fact that the PID_FILE
may have once held a server's pid 660 - but that PID has
been reallocated to a new process
So at best the 'pid file' gambit is a STARTING PLACE! But know what
the limits are.
The second problem is 'detaching your server from the caller'
which is the fun of actually daemonizing a process. The first
trick is to create your server as a Daemon - which means that
it will need to
a. close STDIN,STDOUT,STDERR
b. detach itself from the controlling TTY.
there is the Proc::Daemon project at the CPAN
http://search.cpan.org/author/EHOOD/Proc-Daemon-0.03/Daemon.pm
which will help with this part.
A quick lesson on 'init scripting'. Most system daemons,
and this includes the web server, are started at boot
time with a simple 'init script' of the form
#!/bin/sh
case $1 in
start) the_daemon start_args
;;
stop) the_daemon stop_args
;;
esac
So when building a daemon it is useful to think in
similar terms - this of course normally means having
a command line option pair
'-b' : boot|begin
'-k' : kill|klose
hence 'daemon -b' will start the daemon, and if it
already knows where the pid file is going to be, it
will then check to see if another daemon of it's type
is running, and either defer to the existing one, or
tell it to die, and take over.
the '-k' option will likewise check for the existence
of the pid file and signal the daemon to shutdown
cf:
http://www.wetware.com/drieux/pbl/Sys/daemon1.txt
At which point one crawls back up to the basic question
So I need a piece of CGI code that will start the daemon?
If one put most of the basic common stuff in a perl library,
then you could have say
sub server_running {
#my $obj = shift; # if we plan to OO this
my ($pid, $server) = @_;
my $line = `ps -p $pid` ;
return( ($line =~/$server/g) ? 1:0 );
}
Since the 'daemon will detach itself' you can just
call it directly or call your intermediary 'init script'
unless ( server_running($pid,$daemon) )
{
# your script will block here for the time
# that it takes to fork out the daemon
my $answer = `start_daemon start`;
#
# handle any 'wrong $answer' responses
#
}
#
# now you need to deal with what to do with the initial request
# that needed to talk with the server
#
At which point you have the other sets of problems about
how to get it to stop do you want it to listen on
an additional port for control messages that are out
of band of the usual 'user message traffic flow'
HTH
ciao
drieux
---
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Still Not sure if I agree with myself.
Drieux [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
This discussion goes along with the one you are having with fliptop.
One of my first question is - why the 'closure' eg:
{
package FOO;
}
Or is that simply to make 'clear' that outside of
the Closure it is still package 'main'???
I dont think you can call that a closure yet. You would have to be defining
subroutines that refer to lexical variables outside of the subroutine or
something along those lines:
[EMAIL PROTECTED] trwww]$ perl
{
my $dog = 'spot';
sub dogsName {
my $pooch = $dog;
return(my dog is $pooch);
}
}
print dogsName(), \n;
print Share your dog '$dog' with me\n;
Ctrl-D
my dog is spot
Share your dog '' with me
Only the sub dogsName() knows the value of $dog. NOW the braces are a
closure for the lexical. Before that they just made up a block. The last
line of code above explodes with strict.
So, when you do your:
{
package FOO;
}
And you define lexicals in there, only functions internal to the block have
access to the lexical. If you put each class in its own file, you get the
same behavior because files have thier own scope.
In OO terms, this is called 'private static members'
snip /
Which leads me to my second set of question,
as a general habit I tend to make 'private-ish' methods
with the _ prefix such as
sub _some_private_method { }
is there some 'general access' mechanism by which one can
ask for the LIST of all methods that an 'object' CanDo???
Or should one have a 'register_of_parser_methods' approach
that one can query?
I followed your link ( that I affectionately snipped ), but it was a couple
days ago.
If your hell-bent on writing YA_CGI_AppServer, then check out how the
currently existing ones handle dispatching. CGI::Application is an excellent
example and easy to follow because its simple. There are others, too.
I like to write my own application server components because it is fun to
see one evolve from an empty text file to set of directories worthy of CVS:
http://waveright.homeip.net/~trwww/api.gif
But sometimes its funner to pretend everything is a jigsaw puzzle. Making
CGI::Application, CGI::Session, Class::DBI, and Template::Toolkit work
together transparently has been interesting. Perhaps one day it will be done
=0).
Todd W.
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Still Not sure if I agree with myself.
On Friday, Sep 12, 2003, at 18:54 US/Pacific, Todd W. wrote:
[..]
I dont think you can call that a closure yet. You would have to be
defining
subroutines that refer to lexical variables outside of the subroutine
or
something along those lines:
[EMAIL PROTECTED] trwww]$ perl
{
my $dog = 'spot';
sub dogsName {
my $pooch = $dog;
return(my dog is $pooch);
}
}
[..]
Mea Kulpa! What Was I Thinking? I just did the
perldoc -q closure
but. hum...
{
package Foo::Bar
use base qw/Foo/;
...
}
Would seem to meet the minimum requirement, since
the 'use base' there deals with the @ISA for that
package name space...
But I think the part that scares me is that
my $action = {
doDaemon = sub { . },
...
};
would get us into the same 'space'?
I'm not sure I really want to actually create YA_CGI_AppServer,
although, I fear that I am in dire meandering towards that sort
of 'can one create a general enough solution'
Since, well, uh, one of my doodles is about passing in a
reference to an object, and such things ... Since the basic
'shell' of a CGI script still looks like:
my $request = $ENV{'REQUEST_METHOD'};
my ($page_type,$page) = (text/html);
if( defined($request) $request =~ m/^POST|GET|HEAD$/)
{
my $queryString = ($request eq 'POST' )?
STDIN : $ENV{'QUERY_STRING'};
#
# a. get the query string into a useable manner
# b. verify that the query string has what you need
# and is safe, sane and sober
# c. given some key in that query string select the
#right method for making a response
#
} else {
#
# Deal with being passed an unsupported Request Method
#
}
make_header_and_send($page_type, $page);
so that of course yearns to be in a module, rather than
as something one would cut and paste into each new CGI script...
But looking at your diagramme, I think I can see why you
are pointing towards a YA_CGI_AppServer
ciao
drieux
---
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
