PHP :: Bug #10062 :: CGI version displays '#!/usr/local/bin/php' line

Bug #10062	CGI version displays '#!/usr/local/bin/php' line
Submitted:	2001-03-29 12:25 UTC	Modified:	2002-02-09 19:51 UTC
From:	shane dot wright at ecustomeropinions dot com	Assigned:
Status:	Closed	Package:	*General Issues
PHP Version:	4.0.4pl1	OS:	RedHat 7
Private report:	No	CVE-ID:	None

View Add Comment Developer Edit

[2001-03-29 12:25 UTC] shane dot wright at ecustomeropinions dot com

Standard configure/make on REdHat 7 (options are: 
--without-apache --with-mysql --with-gd)

Then CGI execution as normal - it reads php.ini fine and 
renders PHP fine - the only problem is the display of the 
first line of the file ('#!/usr/local/bin/php')

I've seen posts elsewhere about someone having a similar 
problem on FreeBSD with an older version that went away 
with a newer version (of PHP that is) so I'm assuming its 
a resurfacing issue.  Apologies if it's just me being lame 
;)

Regards

Shane

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports

[2001-03-29 12:38 UTC] jmoore@php.net

There is no need for #!/usr/local/bin/php if you have your webserver set up to parse PHP files already (IE if you have set up apache as shown in install docs.) if your webserver is executing the files (actually set up as real cgi then please reopen this bug report but this shouldnt happen as the webserver should strip the #!/usr/local/bin/php line out.)

James

[2001-03-29 12:51 UTC] shane dot wright at ecustomeropinions dot com

I'm afraid it really is as a CGI - the reason being that 
my ISP won't install PHP modules and I need gd/t1lib 
support.  This problem is with testing the setup on the 
local server (I want the same setup both ends to avoid any 
extra complications).

I wasn't aware that it was the web server's responsibility 
to strip the #1/usr/local/bin/php line out - I am running 
apache 1.3.14 and I have a feeling there could be an issue 
with that - (although I haven't noticed it in the past 
with C++ CGIs)

[2001-03-29 13:05 UTC] jmoore@php.net

Hmm I might be wrong there.. What webserver is your ISP running?

James

[2001-03-29 13:41 UTC] shane dot wright at ecustomeropinions dot com

They're running 1.3.12 - but that doesn't matter yet as I 
can't even get PHP to compile there (its Debian with 
glibc2.1, PHP 4.0.4pl1, same configure options as I said 
previously, configure runs fine, but make dies half way 
through - can't work out why though - but thats for 
another day...)

Ah.  but if it is an issue with Apache then I'm screwed 
anyway :((

[2001-03-29 13:49 UTC] jmoore@php.net

This isnt an Issue with apache. What are you calling your php file?? .cgi yes? there are some hacks around this but it seems more likley a config problem rather than a bug in PHP.. anu ideas people??

[2001-03-29 13:57 UTC] shane dot wright at ecustomeropinions dot com

I'm glad it's not an Apache issue, makes life easier :))

yup, file is called test.cgi, chmod 755, ExecCGI enabled 
in Apache.

A hack would be fine...   ..so long as it doesn't require 
root access or changes to Apache's config (which I 
wouldn't be able to do on the remote machine)

Are you thinking of a patch to PHP to forcefully stop it 
outputting anything before the first newline?  That would 
be ok - but my CGI's need to use a lot of HTTP headers 
(including HTTP authentication - but that can change if 
necessary)  I was thinking of making them nph-...

Regards
Shane

[2001-06-14 16:45 UTC] sniper@php.net

of #9041

[2002-02-09 19:51 UTC] mfischer@php.net

This bug has been fixed in CVS.

	php.net \| support \| documentation \| report a bug \| advanced search \| search howto \| statistics \| random bug \| login
go to bug id or search bugs for


Copyright © 2001-2024 The PHP Group All rights reserved.	Last updated: Tue Apr 23 14:01:31 2024 UTC