php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

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 Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: shane dot wright at ecustomeropinions dot com
New email:
PHP Version: OS:

 

 [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

Pull Requests

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 Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Wed May 07 19:01:32 2025 UTC