Re: Still Not sure if I agree with myself.

2003-09-11 Thread fliptop
On Mon, 8 Sep 2003 at 15:36, drieux opined:

drieux - since no one has responded, i'll take a stab at some of the 
issues you bring up.

d:One of my first question is - why the 'closure' eg:
d:
d:{
d:  package FOO;
d:  
d:}
d:
d:Or is that simply to make 'clear' that outside of
d:the Closure it is still package 'main'???

from 'programming perl, 3rd edition', page 260:

closure gives us a way to set values used in a subroutine when you define 
it, not just when you call it

so while i can see a reason for using closure like this:

{
  my %REQ_PARAMS = {
action1 = { # some specifications for action1 },
action2 = { # some specifications for action2 },
etc
  };

  sub req_params {
return $REQ_PARAMS{shift-action};
  }
}

i'm not sure what the benefit of putting the whole damn package inside a 
closure is.  perhaps someone else can provide a reason or example of its 
benefits?

d:Which leads me to my second set of question,
d:
d:  as a general habit I tend to make 'private-ish' methods
d:  with the _ prefix such as
d:
d:  sub _some_private_method {  }
d:
d:is there some 'general access' mechanism by which one can
d:ask for the LIST of all methods that an 'object' CanDo???

not that i know of.

d:Or should one have a 'register_of_parser_methods' approach
d:that one can query?

i would guess most people probably list the available (public) methods in
the pod documentation.


-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Still Not sure if I agree with myself.

2003-09-11 Thread drieux
On Thursday, Sep 11, 2003, at 05:51 US/Pacific, fliptop wrote:
[..]
drieux - since no one has responded, i'll take a stab at some of the
issues you bring up.
[..]

Thanks for the feed back.

In the code that I implemented, I did not use the Closure
to 'wrap' my Package - but I think as a 'GP safety' I
probably would, in case I needed to have variables that
belonged in the Package Space as you noted.
The second thing that SMACKED ME upside the head as I
was working out 'what is the ugly here'?
simply because

	$obj-can($do);

does not mean

	$obj-should($do);

The problem I am looking for in my should() method
is a programatic way to solve Which Method to invoke
the correct sub to deal with a query string. I have
a tough enough time keeping my code in line as it is,
I really do not want it to be reading POD when it should
be working and generating HTML 8-)
My traditional trick is of the form
	
	my $qs = make_hash_of_query_string($request);
	my $actions = {}; # the hash of subs
	my $callForm = $qs-{'callForm'} || 'main_display'; # get the callForm 
parameter

my $page = (defined($action-{'callForm'}) ? # is it defined
$action-{'callForm'}-($qs) :
main_display($qs);
Which of course requires me to maintain the Hash of $actions
so that I 'register' by hand, each of the Subs that SHOULD
be used in the cgi code. A problem that I do not escape
if I have to maintain a similar list of which 'callForms'
are legitimate tokens to be returned from the browser.
So while the UNIVERSAL::can is able to check for a
given 'symbol' and return a reference to it I was
sorta wanting something that would return a list of all
of the symbols that would return something in can()...
So that I could keep the list of 'But Not These'...
Which is merely the reverse, and perchance Worse notion
since the maintanance of that DarkUgly has to know all
of the things to exclude... To cite the Immortals
	Run Away!


ciao
drieux
---

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Date to seconds

2003-09-11 Thread Li, Kit-Wing
Hi,

Does anybody know of a quick method in perl to turn a date string into its
equivalent in seconds, include milliseconds if possible?  Ex: 20030910
13:50:25.6 to 1063202644.  Thanks much!



--
This message is intended only for the personal and confidential use of the
designated recipient(s) named above.  If you are not the intended recipient of
this message you are hereby notified that any review, dissemination,
distribution or copying of this message is strictly prohibited.  This
communication is for information purposes only and should not be regarded as
an offer to sell or as a solicitation of an offer to buy any financial
product, an official confirmation of any transaction, or as an official
statement of Lehman Brothers.  Email transmission cannot be guaranteed to be
secure or error-free.  Therefore, we do not represent that this information is
complete or accurate and it should not be relied upon as such.  All
information is subject to change without notice.


-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Still Not sure if I agree with myself.

2003-09-11 Thread fliptop
On Thu, 11 Sep 2003 at 07:55, drieux opined:

d:simply because
d:
d:  $obj-can($do);
d:
d:does not mean
d:
d:  $obj-should($do);
d:
d:The problem I am looking for in my should() method
d:is a programatic way to solve Which Method to invoke
d:the correct sub to deal with a query string. I have
d:a tough enough time keeping my code in line as it is,
d:I really do not want it to be reading POD when it should
d:be working and generating HTML 8-)

the way i do it is to assign an action to each form.  each action has 
associated parameters.  the form sends the action in an input 
type=hidden tag.

d:
d:My traditional trick is of the form
d:  
d:  my $qs = make_hash_of_query_string($request);
d:  my $actions = {}; # the hash of subs
d:  my $callForm = $qs-{'callForm'} || 'main_display'; # get the callForm 
d:parameter
d:
d:  my $page = (defined($action-{'callForm'}) ? # is it defined
d:  $action-{'callForm'}-($qs) :
d:  main_display($qs);
d:
d:Which of course requires me to maintain the Hash of $actions
d:so that I 'register' by hand, each of the Subs that SHOULD
d:be used in the cgi code. A problem that I do not escape
d:if I have to maintain a similar list of which 'callForms'
d:are legitimate tokens to be returned from the browser.

another way is to check the list of acceptable 'actions' in the module
constructor, then if you pass an action method that's not defined, return
an error.  for example:

package Foo;
use Carp;

{
  my %REQ_PARAMS = (
action1 = { # criteria for action 1 },
action2 = { # criteria for action 2 },
etc...
  );

  sub req_params {
return $REQ_PARAMS{shift-action};
  }
}

sub new {
  my ($class, %args) = @_;

  croak missing action arg unless defined $args{action};

  my $self = bless {
_ACTION = $args{action}
  }, $class;

  croak method $args{action} not found unless $self-req_params;

  return $self;
}

sub action { shift-{_ACTION} }


then in your script:

#!/usr/bin/perl -w

use Foo;

my $f1 = Foo-new( action = 'action2' ); # works ok
my $f2 = Foo-new( action = 'action6' ); # shits the bed



-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Date to seconds

2003-09-11 Thread Alexander Blüm
Li, Kit-Wing wrote:
Hi,

Does anybody know of a quick method in perl to turn a date string into its
equivalent in seconds, include milliseconds if possible?  
 Ex: 20030910 13:50:25.6 to 1063202644.  Thanks much!

starting when?
I mean, you 1063202644 seconds, and these are
33years : 37weeks : 01day : 14hours : 04minutes : 04seconds

oooh... since 1970 00:00:00

try print time();

if you want to convert any other date to seconds since 1970, you will 
have to convert the year, month and day seperately to seconds, don't 
forget, the hours and minutes...

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Still Not sure if I agree with myself.

2003-09-11 Thread drieux
On Thursday, Sep 11, 2003, at 12:17 US/Pacific, fliptop wrote:
[..]
the way i do it is to assign an action to each form.  each action has
associated parameters.  the form sends the action in an input
type=hidden tag.
oh yes, in this case the 'trigger' I use in say

	input type=hidden name=callForm value=doDaemon

This way we do not have to have 'one cgi script' per action.
My general strategy is to just pass along the HASH of
the query string and leave them up to the subs to sort out
which they need, which they use, yada-yada.
d:My traditional trick is of the form
d:  
d:  my $qs = make_hash_of_query_string($request);
d:  my $actions = {}; # the hash of subs
oh, sorry, maybe if I broke that out

my $action = {
doDaemon   = \doDameon,
showDaemon = \show_daemon,
kickDaemon = \doDameon,

};
It would be more obvious that my idea is to KNOW that
a given 'callForm' value returned from the browser is
associated with a given method that would deal with
the rest of the pack up some HTML and ship it back.
The 'kickDaemon' variant in there is when I have already
worked out that it would be a possible 'callForm' value
that can be passed to this CGI, from some other piece
of code, and that the difference between what kickDaemon()
and doDaemon() do ultimately was so negligible that I just
put a 'flag foo' into the later and consolidated code...
d:	my $callForm = $qs-{'callForm'} || 'main_display'; # get the 
callForm
d:parameter
d:
d:	my $page = (defined($action-{'callForm'}) ? # is it defined
d:		$action-{'callForm'}-($qs) :
d:		main_display($qs);
d:
d:Which of course requires me to maintain the Hash of $actions
[..]
{
  my %REQ_PARAMS = (
action1 = { # criteria for action 1 },
action2 = { # criteria for action 2 },
etc...
  );
[..]

That was what I was trying to mostly avoid. The idea of
the 'should()' would take me along the line
my $page = ($obj-should($action-{'callForm'})) ?
$obj-${$action-{'callForm'}}($qs) :
$obj-call_form_error($qs);
hence the should look like

my $REQ_PARM = {
doDaemon = 1,

};

sub should { defined($REQ_PARAMS-{$_[0]}); }

sub doDaemon {

}
sub kickDaemon { $me=shift; $me-doDaemon(@_); }
# the synonym trick...
Which still gives me a HASH to manage, plus the actual Sub.

ciao
drieux
---

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Perl/Linux problem.

2003-09-11 Thread Sara
I recently installed RH 9.0 on my machine with pre-configured Apache and Perl.

I made a simple script HELLO WORLD to check the Perl and it gave me a continuous 
error for 500 Internal Server Error and Premature End of Script Headers.

I double checked the perl path, permissions, httpd.conf etc, everything looks fine, 
ran the script in terminal (perl -wc)  and it produced desired output, verified the 
syntax is ok and there is no problem with this 3 line script, but in the browser it 
again failed to run.

I thought another way of testing it, Using LAN (and samba) I copied a simple script 
from my Windows machine to Apache and ran that script and amazingly it ran without any 
problem (both in terminal and mozilla)

So, what I have assumed that there must be some problem with scripts that I am writing 
in the Linux environment. I am using text editor of Linux (gedit) for saving the 
scripts. I am at a loss now as what I am doing wrong. The simple scripts like 'Hello 
world' written in gedit failed to run (in browser only) but a bit complex script 
imported from Windows XP is runing smoothly?

Do I need to change the text editor for Linux, if yes, what are the recommendations?

Thanks for any input.

Sara.




RE: Perl/Linux problem.

2003-09-11 Thread Wiggins d'Anconia


On Thu, 11 Sep 2003 15:37:05 +0500, Sara [EMAIL PROTECTED] wrote:

 I recently installed RH 9.0 on my machine with pre-configured Apache and Perl.
 
 I made a simple script HELLO WORLD to check the Perl and it gave me a continuous 
 error for 500 Internal Server Error and Premature End of Script Headers.
 
 I double checked the perl path, permissions, httpd.conf etc, everything looks fine, 
 ran the script in terminal (perl -wc)  and it produced desired output, verified the 
 syntax is ok and there is no problem with this 3 line script, but in the browser it 
 again failed to run.
 
 I thought another way of testing it, Using LAN (and samba) I copied a simple script 
 from my Windows machine to Apache and ran that script and amazingly it ran without 
 any problem (both in terminal and mozilla)
 
 So, what I have assumed that there must be some problem with scripts that I am 
 writing in the Linux environment. I am using text editor of Linux (gedit) for saving 
 the scripts. I am at a loss now as what I am doing wrong. The simple scripts like 
 'Hello world' written in gedit failed to run (in browser only) but a bit complex 
 script imported from Windows XP is runing smoothly?
 
 Do I need to change the text editor for Linux, if yes, what are the recommendations?
 
 Thanks for any input.
 

What does the Apache error log have in it?  Usually that is the best way to tell 
exactly waht the error is. 

Without that all the claims you make to checking everything are suspect

http://danconia.org

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Perl/Linux problem.

2003-09-11 Thread Sara
Apache Error Log: premature end of script headers


Thanks,

Sara.

- Original Message -
From: Wiggins d'Anconia [EMAIL PROTECTED]
To: Sara [EMAIL PROTECTED]; beginperl [EMAIL PROTECTED]
Sent: Friday, September 12, 2003 3:45 AM
Subject: RE: Perl/Linux problem.


:
: 
: On Thu, 11 Sep 2003 15:37:05 +0500, Sara [EMAIL PROTECTED] wrote:
:
:  I recently installed RH 9.0 on my machine with pre-configured Apache and
Perl.
: 
:  I made a simple script HELLO WORLD to check the Perl and it gave me a
continuous error for 500 Internal Server Error and Premature End of
Script Headers.
: 
:  I double checked the perl path, permissions, httpd.conf etc, everything
looks fine, ran the script in terminal (perl -wc)  and it produced desired
output, verified the syntax is ok and there is no problem with this 3 line
script, but in the browser it again failed to run.
: 
:  I thought another way of testing it, Using LAN (and samba) I copied a
simple script from my Windows machine to Apache and ran that script and
amazingly it ran without any problem (both in terminal and mozilla)
: 
:  So, what I have assumed that there must be some problem with scripts
that I am writing in the Linux environment. I am using text editor of Linux
(gedit) for saving the scripts. I am at a loss now as what I am doing wrong.
The simple scripts like 'Hello world' written in gedit failed to run (in
browser only) but a bit complex script imported from Windows XP is runing
smoothly?
: 
:  Do I need to change the text editor for Linux, if yes, what are the
recommendations?
: 
:  Thanks for any input.
: 
:
: What does the Apache error log have in it?  Usually that is the best way
to tell exactly waht the error is.
:
: Without that all the claims you make to checking everything are
suspect
:
: http://danconia.org


-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Perl/Linux problem.

2003-09-11 Thread Sara
Yep, I did that, tried every single option to remove this premature end of
script headers.

Do you think it has to do something with 'gedit' text editor? because I am
scripting in this editor for the very first time.
The scripts copied from Window XP machine have no problems at all, runing
smoothly, only those are producing error which I am writing in the Linux
machine. Why?

use CGI qw(header);
use CGI::Carp qw(fatalsToBrowser);


print header;
print Hello world;


-

with CGI.pm

$q-print($q-header( type = 'text/html')

--

and simply

print Content-Type: text/html\n;

print Hello World\n;

--


Thanks,



Sara.





- Original Message -
From: drieux [EMAIL PROTECTED]
To: cgi cgi-list [EMAIL PROTECTED]
Sent: Friday, September 12, 2003 4:31 AM
Subject: Re: Perl/Linux problem.


:
: Sara,
:
: Wiggins is right, one of the questions is what exactly
: did the Apache Error Log say was it's chief complaint.
:
: The 'premature end of script headers' suggest that your
: output does not have a content-type or there is
: CRLF separating them.
:
: eg:
: [jeeves: 45:] test_cgi GET simple.cgi
: Content-Type: text/plain
: hello World
: [jeeves: 46:]
:
: which is not a separation from the header and the body:
:
: [jeeves: 47:] test_cgi GET simple.cgi
: Content-Type: text/plain
:
: hello World
: [jeeves: 48:]
:
: The script for that is at the end.
:
: Excuse me while I help adjust Wiggins Hair
:
: On Thursday, Sep 11, 2003, at 15:45 US/Pacific, Wiggins d'Anconia wrote:
: [..]
: 
:  Without that all the claims you make to checking everything are
:  suspect
:
: bad hair day there wiggins?
:
: THWACK! THWACK! THWACK
:
: did that help loosen up the dandruf.
:
: ciao
: drieux
:
: ---
: the simple code:
: ### #!/usr/bin/perl -w
: ### use strict;
: ###
: ### our $CRLF = \015\012;   # \r\n is not portable
: ### my $type = text/plain;
: ### print Content-Type: $type . $CRLF . $CRLF . hello World
:
:
:
: --
: To unsubscribe, e-mail: [EMAIL PROTECTED]
: For additional commands, e-mail: [EMAIL PROTECTED]
:


-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Perl/Linux problem.

2003-09-11 Thread david
Sara wrote:

 Apache Error Log: premature end of script headers
 
 

[snip]

 output, verified the syntax is ok and there is no problem with this 3 line
 script, but in the browser it again failed to run.

since it's only a 3 liner, can you post it?

david
-- 
$_=q,015001450154015401570040016701570162015401440041,,*,=*|=*_,split+local$;
map{~$_1{$,=1,[EMAIL PROTECTED]||3])=~}}0..s~.~~g-1;*_=*#,

goto=print+eval

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Perl/Linux problem.

2003-09-11 Thread drieux
On Thursday, Sep 11, 2003, at 06:05 US/Pacific, Sara wrote:
[..]
and simply

print Content-Type: text/html\n;

print Hello World\n;
that form will NOT have the separator
and I expect you see something like:
[..]
: [jeeves: 45:] test_cgi GET simple.cgi
: Content-Type: text/plain
: hello World
: [jeeves: 46:]
which is NOT a correct message to send back to
the web-server. You will need to have a
'blank line' between the Content-Type
and the 'hello world'.
but the:
#!/usr/bin/perl -w
use strict;
use CGI qw(header);
print header;
print Hello world;
should work since the CGI::header() will put the additional
CRLF in play and separate them...
You do have the #! line with the -w flag set?

ciao
drieux
---

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


RE: Perl/Linux problem.

2003-09-11 Thread Jonathan E. Hogue
A cgi hello world script must have the headers in it.

For example,

#!/usr/bin/perl

print Content-Type: Text/HTML\n\n;
print Hello World;

-Original Message-
From: Sara [mailto:[EMAIL PROTECTED] 
Sent: Thursday, September 11, 2003 5:37 AM
To: beginperl
Subject: Perl/Linux problem.

I recently installed RH 9.0 on my machine with pre-configured Apache and
Perl.

I made a simple script HELLO WORLD to check the Perl and it gave me a
continuous error for 500 Internal Server Error and Premature End of
Script Headers.

I double checked the perl path, permissions, httpd.conf etc, everything
looks fine, ran the script in terminal (perl -wc)  and it produced
desired output, verified the syntax is ok and there is no problem with
this 3 line script, but in the browser it again failed to run.

I thought another way of testing it, Using LAN (and samba) I copied a
simple script from my Windows machine to Apache and ran that script and
amazingly it ran without any problem (both in terminal and mozilla)

So, what I have assumed that there must be some problem with scripts
that I am writing in the Linux environment. I am using text editor of
Linux (gedit) for saving the scripts. I am at a loss now as what I am
doing wrong. The simple scripts like 'Hello world' written in gedit
failed to run (in browser only) but a bit complex script imported from
Windows XP is runing smoothly?

Do I need to change the text editor for Linux, if yes, what are the
recommendations?

Thanks for any input.

Sara.





-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Perl/Linux problem.

2003-09-11 Thread david
Sara wrote:

 Yep, I did that, tried every single option to remove this premature end of
 script headers.
 
 Do you think it has to do something with 'gedit' text editor? because I am
 scripting in this editor for the very first time.
 The scripts copied from Window XP machine have no problems at all, runing
 smoothly, only those are producing error which I am writing in the Linux
 machine. Why?
 
 use CGI qw(header);
 use CGI::Carp qw(fatalsToBrowser);
 
 
 print header;
 print Hello world;

this looks fine. you should lose the '' sign because you are passing @_ to 
header implicitly.

 
 
 -
 
 with CGI.pm
 
 $q-print($q-header( type = 'text/html')

not sure where you declare $q so i am not going to comment on it.

 
 --
 
 and simply
 
 print Content-Type: text/html\n;
 
 print Hello World\n;
 

this is wrong. see Drieux's previous message for reason.

chances are that when you move (you said you copied the script from a 
windows xp machine and then work on it in gedit?) the script from windows 
to linux, your script is carrying over the \r character. gedit won't show 
that to you. try:

[panda]$ head -1 script.cgi | od -c

and see if you see any '\r' character anywhere. if you do, that's probably 
the cause of the problem. remove those characters with:

[panda]$ perl -i -pe 's/\r//' script.cgi

and then run your script again.

david
-- 
$_=q,015001450154015401570040016701570162015401440041,,*,=*|=*_,split+local$;
map{~$_1{$,=1,[EMAIL PROTECTED]||3])=~}}0..s~.~~g-1;*_=*#,

goto=print+eval

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]