On Fri, 27 Jul 2001, Brian White wrote:
> What this sounds like to me is that as well as having a PHP binary, that
> PHP is installed as a module in your web server.
Thanks for the response.
It is installed as module and as a stand alone outside the web tree at least
on the AIX and Freebsd sessions I mention, I can't speak to the mentions
I've seen regarding this problem and HP/UX.
> For whatever reason ( more than likely, the file extension ) the web server
> is NOT executing it as a CGI itself, but passing it to the PHP module to
> deal with. That is just treating the #! line as text and passing it
> out to the browser.
An interesting thought but I don't believe that can be it, the scripts have
the .cgi extension and that is configured in Apache correctly (and works
fine for anything other then php scripts). Module based usaged relys on .php
and that is configured correctly (and works correctly).
I wonder if the command line version and the module version actually require
independent php.ini files? I wouldn't have thought so but its certainly
somehting to look at.
I did find that I had in fact made a mistake in some of the details below,
the #! lines are in fact showing up after header lines (when telneting in I
had neglect to use HTTP/1.0 on the get line, giving that results in the
headers being displayed).
>From my search through the bug db it appears this problem has been discussed
before but apparently no solution decided upon but one has been looked
at. Essentially the parser isn't skipping the #! line as it should. I had
hoped that someone had found a work around.
I need to do a few more experiments with the apache config to see if I can
get it to work outside the doc tree using a handler config for, say, .php4
files, this would negate the need for the #! line, unfortunately it means
you introduce some complexity (all be it minor) if you want to use a
script as both a command line utility and a web based one. I suspect that
may be doable but wouldn't be my prefered direction.
> You need to figure out what is going on and pick one way to do it.
Certainly need to figure out what is going on but it is common practice to
have php installed in two ways (ie module/cgi or module/outside of doc
tree). Actually suprised the install doesn't provide for that as its
required if you want to be able to do some suid or wrapper stuff with php
yet use the module for normal styff. As far as I know there is no way to get
module based php to execute with anything other then the id of the httpd
process.
>
> Brian
>
> At 22:41 25/07/2001 -0400, Darren Henderson wrote:
>
> >If I have php installed as an executable outside the web tree I can't seem
> >to get php scripts, called as a cgi, to work correctly. When run from the
> >command line this script
> >
> >-
> >#!/usr/local/bin/php
> >
> >-
> >
> >Produces
> >
> >-
> >X-Powered-By: PHP/4.0.4pl1
> >Content-type: text/html
> >
> >hello world
> >-
> >
> >Just as expected. However, when called from a browser it ends up getting
> >
> >-
> >#!/usr/local/bin/php
> >hello world
> >-
> >
> >when we view the source with a browser. If we telnet to port 80 and do a get
> >for the url in question we find that the above is all that we get, no
> >headers of any kind.
> >
> >If we add a -q the #! line we get the behavior we expect from the command
> >line, the headers are supresed, but the browser ends up getting "No input
> >file specified." sans headers or any html tags.
> >
> >Why am I seeing this behavior? I would expect the script the produce the
> >exact same output whether it is called via the command line or as a cgi
> >outside the web tree. I had thought that perhaps it was a system dependent
> >bug, however, I am seeing this same behavior on several machines, AIX 4.2
> >running 4.06, FreeBSD 4.3 running 4.0.4.pl1, and I've found similar reports
> >in the bug db for HP/UX etc.
> >
> >So... this leads me to believe I must be missing something somewhere
> >anyone have any thoughts?
> >
> >How do I supress the printing of the #! line? It has to be in col 1 row 1,
> >if it wasn't for that I could manually enter the headers at least and
> >continue on my way, Where did the headers go? if I use the -q option to
> >purposely turn off headers, I could provide my own, but if I have that
> >option it tells me that there is no input file specified if its not invoked
> >from the command line.
> >
> >
> >--
> >PHP General Mailing List (http://www.php.net/)
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
> >To contact the list administrators, e-mail: [EMAIL PROTECTED]
>
> -
> Brian White
> Step Two Designs Pty Ltd - SGML, XML & HTML Consultancy
> Phone: +612-93197901
> Web: http://www.steptwo.com.au/
> Email: [EMAIL PROTECTED]
>
