From: [EMAIL PROTECTED]
Operating system: Windows 95/ME
PHP version: 4.2.2
PHP Bug Type: Feature/Change Request
Bug description: Why can't I keep php.ini in PHP's directory?
Hi,
I used a Win 95 as test environment for a long time, always successfully.
Now I'm using a Win ME machine, and have problems. I hate Win ME, but this
is someone else's machine so I have to accept this fate for now. I just
moved my entire PHP laboratory to this machine and, when I try to run my
scripts, I get this error:
------------------------ 8< ------------------------
Security Alert! The PHP CGI cannot be accessed directly.
This PHP CGI binary was compiled with force-cgi-redirect enabled. This
means that a page will only be served up if the REDIRECT_STATUS CGI
variable is set, e.g. via an Apache Action directive.
For more information as to why this behaviour exists, see the manual page
for CGI security.
(been there)
For more information about changing this behaviour or re-enabling this
webserver, consult the installation file that came with this distribution,
or visit the manual page.
(been there, got the T-shirt)
------------------------ >8 ------------------------
I am not using Apache, I'm using Omni HTTPD. It worked just fine in my
Win 95. I thought that setting cgi.force_redirect to 0 in php.ini would do
the trick, but it doesn't.
Well, after a lot of struggle, I tried another thing: move my php.ini
file from PHP's directory to the C:\Windows directory. It works! Why?
I want to say that I find it very annoying. I remember once I had a
similar problem, I gave up and moved the php.ini file from PHP's directory
to C:\Windows, but then later I moved the php.ini file back to PHP's
directory and it worked fine (?). I don't see why it refused to work now.
I found a previous bug report in which you suggest setting the environment
variable PHPRC to the desired directory. Setting environment variables in
Windows ME is such a pain! But it works. But it is not intuitive at all.
Not until I saw that previous bug report was I able to look for "PHPRC" in
the manual and find mention of this possibility. I find it very convenient
being able to leave my ini file in PHP's directory and take the whole
directory with me wherever I see fit. I wish you would consider, in the
future, changing this behavior, determined at compile time, so that it
looks for php.ini in PHP's directory first. Then, if it's not found, in
the Windows directory. It sounds a lot more intuitive to me.
Also, remember that I had php.ini in PHP's directory for a long
time in another machine with no knowledge of the PHPRC env var at all.
Considering I've seen it work and fail and not been able to identify any
pattern that would explain why it works now and fails then, I'd like
someone to tell me whether it is a bug, by design and/or if it surprises
you knowing that I have been able to actually keep the php.ini file in
PHP's directory and get away with it in another machine.
Thanks,
Luciano ES
Santos, SP - Brasil
--
Edit bug report at http://bugs.php.net/?id=20835&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=20835&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=20835&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=20835&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=20835&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=20835&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=20835&r=support
Expected behavior: http://bugs.php.net/fix.php?id=20835&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=20835&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=20835&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=20835&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20835&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=20835&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=20835&r=isapi
