From: kmsluder at optonline dot net
Operating system: Irrelevant
PHP version: 4.3.7
PHP Bug Type: Feature/Change Request
Bug description: parse_ini_file() should look in include_path
Description:
------------
When keeping include files separate from publicly accessible documents,
paths to access files in the includes directory can differ for different
pages in the site. For example, on my setup I keep my site in /var/www;
publicly-accessible pages (including my PHP pages) are in /var/www/pub
(which is Apache's ServerRoot), and the include file is in /var/www/inc.
Also stored in /var/www/inc are ini files my PHP application uses.
/var/www/inc is in my include_path.
In my PHP pages, I use require('include.inc'). Inside include.inc there
are calls to parse_ini_file() to process my ini files. Since my ini files
are stored in the same directory as my include file, I figured at first
that referencing them as simple 'config.ini' etc. would work.
Unfortunately, it doesn't, as it looks in the directory of the
currently-executing script. Wouldn't it be more logical for
parse_ini_file() to look in include_path instead, considering 1) almost
any sane include_path includes ./ anyway, and 2) common sense dictates
that ini files should be kept out of the ServerRoot, and it makes sense to
put them with the other files that should be kept out of the ServerRoot,
your include files?
Reproduce code:
---------------
File: ServerRoot/pub/test.php
=============================
<?php
include('include.inc');
?>
File: ServerRoot/inc/include.inc
================================
<?php
$ini = parse_ini_file('config.ini');
echo $ini['value'];
?>
File: ServerRoot/inc/config.ini
===============================
value=hi
Expected result:
----------------
hi
Actual result:
--------------
Warning: parse_ini_file(): Cannot open 'config.ini' for reading in
ServerRoot/include.inc on line 1
--
Edit bug report at http://bugs.php.net/?id=28819&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28819&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28819&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=28819&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=28819&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=28819&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=28819&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=28819&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=28819&r=support
Expected behavior: http://bugs.php.net/fix.php?id=28819&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=28819&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=28819&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=28819&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28819&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=28819&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=28819&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=28819&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=28819&r=float
