[CGI] Can't Execute Script on Apache
Hi I’m trying to execute a simple Perl and/or Python script on Apache2.2 from within an HTML document, but with no success. Please advise if this is the incorrect list to address this problem to. I have a simple “Hello, World!” script in Perl that I want to execute from within an HTML page. The script is located in the Apache/cgi-bin/ directory. I can execute the script via my browser by simply entering it’s URL and sure enough the browser window displays “Hello, World!”. However, if I then create a very simple HTML page with an execute in it I only get the HTML page and text displayed. The HTML doc is located in a directory on the C:/ drive and not in the Apache/htdocs/ directory. The method used to execute is: “” I think I have the white-spaces/syntax correct. My Apache conf file has ExecCGI in the Options directive for the Apache/cgi-bin/ directory. I am at a loss as to why the script appears not to be executed – is it being executed and perhaps not doing what I think? At the moment I simply want to be able to prove that I can run a script from within HTML and output text back to the document which is then displayed within the browser. This is not related to forms in anyway. As I said, the script executes fine if I call it direct (as does the printenv.pl/.cgi script), so I’m sure that is okay & has the right header info – I don’t have to compile it or something first do I?! (n.b. the script below is in Python, not Perl, but they are very similar apart from the executable and display exactly the same symptoms.) Any help greatly appreciated! Simon. [HTML] located at: Z:\IRISIndex\test.html CGI Test Test [CGI] located at: Z:\Program Files\Apache Group\Apache2\cgi-bin\test.cgi #!c:\python23\python.exe # -*- coding: iso8859-1 -*- # test -- test CGI program to display a simple message # Required header that tells the browser how to render the text. print "Content-Type: text/plain\n\n" # Print a simple message to the display window. print "Hello, World!\n"
Re: [CGI] Can't Execute Script on Apache
On Monday 18 September 2006 07:18, Simon Wray wrote: > Hi > > > > I'm trying to execute a simple Perl and/or Python script on Apache2.2 > from within an HTML document, but with no success. What does your error_log say? Also, it looks like you are using SSI, so you will need to make sure SSI is set up correctly. Sean
RE: [CGI] Can't Execute Script on Apache
The error log contains no entry pertaining to the loading of the page. Which makes me think the script has been located & executed... I didn't think I needed to set up SSI because I'm using exec and I have ExecCGI configured. I.e. I'm not using Include. Thanks Simon -Original Message- From: Sean Davis [mailto:[EMAIL PROTECTED] Sent: 18 September 2006 12:27 To: modperl@perl.apache.org Cc: Simon Wray Subject: Re: [CGI] Can't Execute Script on Apache On Monday 18 September 2006 07:18, Simon Wray wrote: > Hi > > > > I'm trying to execute a simple Perl and/or Python script on Apache2.2 > from within an HTML document, but with no success. What does your error_log say? Also, it looks like you are using SSI, so you will need to make sure SSI is set up correctly. Sean
Re: [CGI] Can't Execute Script on Apache
On Monday 18 September 2006 07:46, Simon Wray wrote: > The error log contains no entry pertaining to the loading of the page. > Which makes me think the script has been located & executed... > > I didn't think I needed to set up SSI because I'm using exec and I have > ExecCGI configured. I.e. I'm not using Include. Actually, you are trying to. #exec is an SSI directive. I would do a google search for server side includes and CGI for a tutorial on how to go about this, if this is the way you want to go. However, if you are planning on building a dynamic website, using a templating system such as Template Toolkit or HTML::Template is probably the better way to go. Sean
Re: [CGI] Can't Execute Script on Apache
On Mon, Sep 18, 2006 at 12:46:43PM +0100, Simon Wray wrote: > > The error log contains no entry pertaining to the loading of the page. > Which makes me think the script has been located & executed... Really? Not just that it didn't even parse the file for SSI? That's how I'd read it. Change the script, make it exec "touch /tmp/foo" and then hit the page again. If /tmp/foo has been created, your script ran. I suspect, however, that it won't be. > I didn't think I needed to set up SSI because I'm using exec and I have > ExecCGI configured. I.e. I'm not using Include. You said: "" What do you call that, if not a server-side CGI include? Why do you contend that you are not using includes? ExecCGI is an Apache option telling it that it may execute scripts as CGIs in a given location. Whereas is a SSI which executes a CGI script. Doubtless, with appalling performance, but that's not what you were asking about. This isn't in any way a mod_perl question, BTW. Also, you said that the file is being served from outside the Apache htdocs tree -- do you mean you access it with a file:// URL rather than a http:// URL pointing at the apache server? That will certainly prevent you from executing the include correctly! /joel
RE: [CGI] Can't Execute Script on Apache
I'll probably move this to the beginners-cgi list at Sean's suggestion. But just to try and wrap up one specific point... I've been following the information here: http://httpd.apache.org/docs/1.3/howto/cgi.html and also looking at Includes here: http://httpd.apache.org/docs/1.3/howto/ssi.html These indicate that ExecCGI is separate from Includes on the Option's directive. I'll try switching on the Includes Option and using "
Problems with __DATA__ within a module/handler and mod_perl2 (Own handler - NO CGI script) - Bug?
Hello!
I guess I've found a bug in mod_perl2. But I'd like to ask the users
list first, if anyone has an idea what goes wrong.
I've run into troubles accessing the __DATA__ section of my
modules/handlers. A minimal demonstration handler looks like this:
#!/usr/bin/perl
package TestHandler;
sub handler {
warn tell DATA;
warn ;
return 0;
}
1;
__DATA__
foo
bar
baz
(On the first run) It will correctly put this into the server log:
121 at [..]/TestHandler.pm line 5.
foo
bar
baz
But when I preload this module using the Apache directive
PerlRequire /some/preload_script.pl
which contains:
use TestHandler;
The cursor on the DATA filehandle will be wrong:
133 at /usr/local/lib/perl/5.8.7/TestHandler.pm line 5.
Warning: something's wrong at [..]/TestHandler.pm line 6.
In this case the cursor is positioned at the end of the file (which has
a length of 133 bytes). In other, larger modules the cursor sometimes is
positioned somewhere in the middle of the DATA section.
I don't think that this is the intended behaviour.
It works fine when not preloading the module. It also works fine on
Apache1/mod_perl1.
Any ideas?
Thanks!
-Thomas
Re: Problems with __DATA__ within a module/handler and mod_perl2 (Own handler - NO CGI script) - Bug?
Thomas Wittek wrote:
The cursor on the DATA filehandle will be wrong:
133 at /usr/local/lib/perl/5.8.7/TestHandler.pm line 5.
Warning: something's wrong at [..]/TestHandler.pm line 6.
I think you just need to rewind it after reading it. See the docs for
seek() and tell(). Here's an example:
my $data_start = tell(DATA);
while () {
# do something useful
}
seek(DATA, $data_start, 0);
while () {
# ...
}
- Perrin
Re: Problems with __DATA__ within a module/handler and mod_perl2 (Own handler - NO CGI script) - Bug?
Perrin Harkins schrieb:
> Thomas Wittek wrote:
>> The cursor on the DATA filehandle will be wrong:
>
> I think you just need to rewind it after reading it. See the docs for
> seek() and tell(). Here's an example:
No, the position is already wrong before any read. So saving it for
later purposes won't fix it.
The bug (?) even occurs in this minimal handler without any reads:
#!/usr/bin/perl
package TestHandler;
sub handler {
warn tell DATA;
return 0;
}
1;
__DATA__
foobarbaz
Correct result without preloading of the module:
93 at /mnt/data/pro/konstrukt/dev/lib/TestHandler.pm line 4.
Incorrect result when preloading it in a script which is loaded by
Apache's PerlRequire:
103 at /mnt/data/pro/konstrukt/dev/lib/TestHandler.pm line 4.
The cursor is positioned at the end of the file. On some larger files it
is often positioned somewhere in the middle of the DATA section.
BTW: I forgot to post my configuration details:
[EMAIL PROTECTED] dpkg -l | pcregrep '(libapache2-mod-perl2 |apache2 )'
ii apache22.0.55-4.1 [..]
ii libapache2-mod-perl2 2.0.2-2[..]
[EMAIL PROTECTED] uname -a
Linux server.zentrifuge.intra 2.6.17 #1 PREEMPT Tue Jul 11 02:32:04
CEST 2006 i686 GNU/Linux
Best regards
--
Thomas Wittek
http://gedankenkonstrukt.de/
Jabber: [EMAIL PROTECTED]
Apache::Cookie -> Apache2::Cookie API Change?
Hello,
If this isn't the correct place to report this problem, please excuse
the noise and redirect me...
Apache::Cookie->new used to deal gracefully with an undefined -value
argument (like: "...new (-name => 'some_cookie', -value => undef,
...)"), at least when -expire was in the past ("-1D" in my tests). It
would return a new cookie with an empty value which could be saved to
expire the old cookie.
Now, using the same Perl source with Apache2::Cookie->new, an undefined
value is returned instead of the new cookie. At best, this appears to
be an API change and should be documented. At worst it appears to be a
bug in libapreq2 that should be fixed.
The documentation for A2::C->new states that -value should be an
arrayref, hashref, or string, but it seems to me that either the
behavior in response to an undefined -value should be documented or
trapped internally and an error issued via Carp::croak() or whatever.
I discovered this using libapreq2 2.0.7.
Thanks,
Derek
--
Derek R. Price
CVS Solutions Architect
Get CVS support at Ximbiot !
v: +1 248.835.1260
f: +1 248.835.1263
Re: Apache::Cookie -> Apache2::Cookie API Change?
This same problem occurs if I call A2::C->new without any value argument
("...new (-name => 'some_cookie', -expire => '-1D', -path => ...,
-secure => 0)"), though I didn't verify the A:C->new behavior with no
-value at all (only with -value => undef...).
Derek
Derek R. Price wrote:
> Hello,
>
> If this isn't the correct place to report this problem, please excuse
> the noise and redirect me...
>
> Apache::Cookie->new used to deal gracefully with an undefined -value
> argument (like: "...new (-name => 'some_cookie', -value => undef,
> ...)"), at least when -expire was in the past ("-1D" in my tests). It
> would return a new cookie with an empty value which could be saved to
> expire the old cookie.
>
> Now, using the same Perl source with Apache2::Cookie->new, an undefined
> value is returned instead of the new cookie. At best, this appears to
> be an API change and should be documented. At worst it appears to be a
> bug in libapreq2 that should be fixed.
>
> The documentation for A2::C->new states that -value should be an
> arrayref, hashref, or string, but it seems to me that either the
> behavior in response to an undefined -value should be documented or
> trapped internally and an error issued via Carp::croak() or whatever.
>
> I discovered this using libapreq2 2.0.7.
>
> Thanks,
>
> Derek
--
Derek R. Price
CVS Solutions Architect
Get CVS support at Ximbiot !
v: +1 248.835.1260
f: +1 248.835.1263
hmm..testing with mod_perl and lwp
Okey so this is the situation I have right now: 0)mysql based application 1)server with mod_perl 2)client is browser for time being, might be a mobile terminal or "custom client application" in the future 3)testing ( with perl-unit ) 3.1)testing package method functionality separately from the ui 3.2)testing web interface of the entire application with LWP::UserAgent and XML::XPath 4)transformation of XML web interface to XHTML with XSLT. This all works very well. I can test and verify each package method, as well as each XML page that is returned by the server and validate that all elements are there and has correct content. The thing is:I'd like to discuss the issues that might arise as the development goes on further with this way of working. As for now, I am happy with what I am doing, it feels quite good and correct:but=>if anyone has experience working this way I'd like to know what you/they have experienced. Comments and feedback welcome, ( as always ) Thank you Greger -- QxRSSReader v1.2.6a released (30-06-2006) PortScanner v1.2.2 ( 09-08-2006 ) http://www.gregerhaga.net/ There are no stupid questions, but there are stupid answers.
