Re: [OT] advice needed.
Where the heck does trying to do the right thing by GPL (or similar), in attempting to return some improved OpenSource code to the community. Or however the license phrases it. Shouldn't these contracts address that issue specifically, especially when the project is _based_ on OpenSource/GPL'd code? Mike D.
Re: Book: guestbook.cgi
Spotted this
sub view_guestbook {
my $show_sign_button = shift;
print start_form,
submit(-name = 'Sign Guestbook'),
end_form if $show_sign_button;
...
changed to
submit(-name = 'action', -value = 'Sign Guestbook'),
And at least the forms behave correctly. Still not sure
if the many logs about subroutine redefines should be happening.
Could someone please confirm if this is the code in their book?
(book == Writing Apache Modules with Perl and C, March 1999 -
first edition.)
Thanks for your patience,
M. Dearman
Newbie: Running script using Apache API
Howdy all,
Trying to run a script from the Eagle Book (ch.4 Example 4-14)
Using the Apache API, so it looks like:
#!/usr/bin/perl -w
# file perl/hello3.pl
use strict:
my $r- = Apache-request;
$r-content_type('text/html');
$r-send_http_header;
return OK unless $r-header_only;
.
.
.
And so on. Like a module.pm in other words.
It doesn't work. The 'perl/' dir is the one set up for other scripts.
The perl.conf for this dir is per book directions.
Location /perl
SetHandler perl-script
PerlHandlerApache::Registry
PerlSendHeader On
Options+ExecCGI
/Location
Using current versions of Apache and mod_perl on Intel.
What the error_log shows is that apparently Registry is trying
to wrap the script in a handler subroutine, as Stas's guide describes -
But there's also the bareword warning first.
hello3.pl:Bareword "OK" not allowed while "strict subs" in use at
/usr/local/apache/perl/hello3.pl line 9.
Undefined subroutine Apache::ROOT::perl::hello3_2epl::handler called at
path to .../Apache/Registry.pm line 135
Just before the example in the book, there is a discussion about
checking the environment variable MOD_PERL or GATEWAY_INTERFACE.
But not clear if this should be done somehow for this script.
Would appreciate any help on what I'm not understanding about this.
Thanks,
M. Dearman
Re: Newbie: Running script using Apache API
Jay J wrote:
- Original Message -
From: "Michael Dearman" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, December 10, 1999 5:35 AM
Subject: Newbie: Running script using Apache API
Howdy all,
Trying to run a script from the Eagle Book (ch.4 Example 4-14)
Using the Apache API, so it looks like:
#!/usr/bin/perl -w
# file perl/hello3.pl
use strict:
my $r- = Apache-request;
$r-content_type('text/html');
$r-send_http_header;
return OK unless $r-header_only;
.
And so on. Like a module.pm in other words.
It doesn't work. The 'perl/' dir is the one set up for other scripts.
The perl.conf for this dir is per book directions.
Location /perl
SetHandler perl-script
PerlHandlerApache::Registry
PerlSendHeader On
Options+ExecCGI
/Location
[snip]
Thanks,
M. Dearman
Hey Michael,
You seem to have missed something along the way. The answer actually lies in
your own explanation of the problem.
For that location, you already have a handler - Apache::Registry, what you
want* is your .pm as the handler for a particular location. I think if you
page back a chapter or two you'll see examples of how httpd.conf or
.htaccess files should be setup.
-Jay J
(omitting all mention [except this] of stacked handlers for this example)
Hi Jay, and all,
Can appreciate that - and have seen this mentioned in the GuestBook
example.
But on page 144 the authors state that you can use scripts in an
Apache::Registry
enabled directory (in may case /perl) that either use the CGI
environment OR scripts
that use the API environment. Heck, they state you can mix the 2 types.
And have been successful in using calls to apache like 'my $r =
Apache-request'
I have refined my problem while writing this.
When I comment out the line ' return OK unless $r-header_only ' it
works.
So apparently I just got to get Apache::Constants to pick up the 'OK'.
Otherwise it sees it as a bareword.
I had tried sticking in a ' use Apache::Constants qw(:common) in the
script.
Below the ' use strict '. Did not work.
And I do have ' use Apache::Constants (); ' in the startup.pl file
Shouldn't that catch the :common variety?
Also tried return 200, return HTTP_OK, in all manner of quote schemes
and
still not working.
Thanks,
M. Dearman
Re: Newbie: Running script using Apache API
Ah... So apparently I just got to get Apache::Constants to pick up the 'OK'. Otherwise it sees it as a bareword. OK, got that 'OK' is an Apache return code. *bow* M. Dearman
Re: Newbie: Running script using Apache API
Prakash Kailasa wrote: Hi Prakash, Well. It's example 4-14, on page 146 I have a march 1999 first edition. You mean there's already a second edition!? It's definitely a 'return OK unless' for mine. Thanks, M. Dearman I just went back and checked again and _again_. I am looking at the same example 4-14 on the same page 146 and I swear it is 'return OK if $r-header_only;' And, mine is a March 1999 First Edition too. Go figure. Most likely, its just a new printing of the same edition with the typos fixed. /prakash That is wierd. Wish we could figure out how else to tell the difference in the printings beside that date. Would help track any other problems. Thanks Prakash, M. Dearman
Re: Name / brand overview version 2
Another Eagle. http://www.inficad.com/~mdearman/ Wife's working on a colored feather. It had one on each wing tip. But one fell out. M. D.
Re: Logo / brand
Victor Zamouline wrote: Talking about "let's do something" topics on the mod_perl list is a waste of time, unfortunately... The motto of this list regarding new things is "think it, implement it and give it"... This is somewhat too straightforward, Stas. Look - I only suggested there should be another name and another logo, and we have already had the "Eagle" proposition from Ged, and the watermarks samples at http://b179a.studby.ntnu.no/mod_perl/watermark/ from Salve. The Eagle idea sounds really strong and symbolic behind ModPerl, and the graphical image of it would be highly customizable, portable, simple and color-independent. Many sites will thus accept to host the logo on the front page, and many books will reveal a mystery behind an appealing eagle image. I sat down and looked at Salve's "Powered by mod_perl" watermarks for some time, trying to imagine "Powered by Eagle"... What about "Eagle Perl"? "Powered by Eagle Perl"? Vic. Got a nice eagle. Wife's going to work on puting apache-colored feathers at the wing tips. Now for the words. Thinking the eagle will be in close proximity to the Apache logo - so a bit much "powered". But what? Mod Perl or Eagle Perl: -Enhanced, -On Board, Turbo-, -Tuned, Soaring with-, Flying with-, ...? M. Dearman Our eigth y/o asked that we tell him if there was a Santa or not, because when he grew up he didn't just want to be sitting around waiting for him to bring his kids some toys if he wasn't going to show up. :)
Re: PerlFreshRestart and %INC
Foolishness alert/Newbie approaches. Hate that this thread died. Was following it to get some insights into the nether regions. I read some doc about DBI or Apache/DBI pinging or doing some kind of trace on the other when a db connection was attempted. I thought it made the point that Apache/DBI was not loaded until a connection was attempted by DBI.pm. Would appreciate a heads up on what doc that was. Can't find it again. *sigh* Thanks, Michael Dearman
Re: mod_perl Programmers demand is going up...
"G.W. Haywood" wrote: On Fri, 3 Dec 1999, Robin Berjon wrote: That takes a strong logo and... possibly a more artistic name for mod_perl? The Eagle book doesn't have it on it's cover though, Well, actually, it does... on the first line, but who cares? so it might be possible if anyone's got some good suggestion How about ``Eagle''? 73 Ged. Exactly what I was just thinking. Apache Stronghold Apache Eagle Logo? Eagle floating over the feather? Or, the feather floating under the Eagle. An Eagle Feather. *Slute* M. Dearman
Re: mod_perl Programmers demand is going up...
Randy Harmon wrote: Um, isn't that animal taken by O'Rielly? The O'Reilly Eagle is a Tawny Eagle. Thar be golden, spotted, bald, imperial, harpy ... well, plenty to go around. Still, it'd be nice to be able to use The Eagle. Logo promotes the book. To honor the first tome of mod_perl. Book promotes logo. How about an oyster? Perhaps not as american-patriotic but just think how sexy it sounds. Well Oysters promote? *wave* M. Dearman
Re: Eagle Book - mod_hello.c, hello.pl :)
Gerd Kortemeyer wrote:
Michael Dearman [EMAIL PROTECTED] wrote:
I've come close to figuring this one out buy following some of the
H1Hello $ENV{REMOTE_HOST}/H1
Stas Bekman wrote:
This is an easy prove that %ENV is set (while not all variables are
present as with mod_cgi, particularly REMOTE_HOST isn't there...)
Yes, there's a 'printenv' script in the cgi-bin dir.
From http://www.apache.org/docs/upgrading_to_1_3.html
REMOTE_HOST CGI variable changed. In Apache 1.2 and earlier, the REMOTE_HOST
environment variable made
available to CGI scripts was set to either the full DNS name of the client, or else
to the client's IP
address if the name was not known. This behaviour differed from that specified by
the CGI specification, which defines this variable as being NULL if the name isn't
known. In Apache 1.3, we
have made this correction. REMOTE_ADDR always contains the client's IP address, but
REMOTE_HOST is only
defined when the server has been able to determine the client's DNS name.
I think that is what you are seeing, rather than any problem with the
environment in general.
- Gerd.
[the 's aren't correct. Tried to reformat to make clearer and properly
acknowledge the help]
Thanks!!
That was it. Specifically - I don't have DNS set up on my home network.
REMOTE_ADDR did the trick.
And thanks for pointing out those resources. Should help with other
problems with examples in the Book.
*Saaalute*
Michael Dearman
Eagle Book - mod_hello.c, hello.pl :)
Greetings list,
Installed fresh downloads of
Apache 1.3.9 and mod_perl 1.21
But using the Perl 5.005003 that was installed with the
SuSE 6.2
mod_hello.c
when 'make', get:
:50:'hello_handlers' undeclared here (not in a function)
:50:initializer element for 'hello_module.handlers is not constant in
http_config.h
When looking at http_config.h at the handler_rec structure, the elements
don't seem to match the way they're used in the example in the book.
Going to the book site, the src's for the examples are NOT available.
*shrug*
--
hello.pl
I've come close to figuring this one out buy following some of the
questions I've seen here. But...
H1Hello $ENV{REMOTE_HOST}/H1
The remote host doesn't show. Printing out the %ENV, it tain't there.
But where does Perl get it. From CGI.pm (which is installed) or where?
Thanks,
Michael Dearman
"I'd give my right arm to be ambidextrous." -- Yogi Berra
Re: Eagle Book - mod_hello.c, hello.pl :)
Ofer Inbar wrote:
Michael Dearman [EMAIL PROTECTED] wrote:
I've come close to figuring this one out buy following some of the
questions I've seen here. But...
H1Hello $ENV{REMOTE_HOST}/H1
-schnip-
normally gets out of the environment. Remember, mod_perl is not CGI
(although with Apache::Registry it can look quite similar to CGI)
-- Cos (Ofer Inbar) -- [EMAIL PROTECTED] [EMAIL PROTECTED]
Thanks Ofer,
And along with the guides advice that the use of ENV is clunky anyway,
I'll
proceed with using the objects. It's just disconcerting when you can't
get
and example from a book to work. Just didn't know if it was something I
didn't
have set up right. But now methinks it might be the example was leading
me astray.
Sure wish the book site had those file listings and any corrections.
*hint-hint*
Thanks again,
Michael Dearman
