#26206 [Fbk-Opn]: argv and argc not defined
ID: 26206 User updated by: danielc at analysisandsolutions dot com Reported By: danielc at analysisandsolutions dot com -Status: Feedback +Status: Open Bug Type: CGI related Operating System: Windows 2000 PHP Version: 5CVS-2003-11-11 (dev) New Comment: No luck with the new snapshot. Downloaded php5-win32-200312010330.zip, copied php.ini-recommended to php.ini, turned register_argc_argv = On, ran the following... C:\PROGRA~1\php\cliphp -i | grep argv register_argc_argv = On = On C:\PROGRA~1\php\cliphp -r var_dump($_SERVER['argv']); 1 2 3 PHP Notice: Undefined index: argv in Command line code on line 1 NULL Previous Comments: [2003-11-29 00:15:40] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip I can not reproduce this on windows using latest CVS snapshot. [2003-11-27 19:24:09] danielc at analysisandsolutions dot com Your test of ignoring the php.ini file via the -n flag gets it to work as expected. FYI... C:\PROGRA~1\php\cliphp -i | grep argv register_argc_argv = On = On C:\PROGRA~1\php\cliphp -n -i | grep argv register_argc_argv = On = On _SERVER[argv] = Array C:\PROGRA~1\php\cliphp -v PHP 5.0.0b3-dev (cli) (built: Nov 26 2003 04:10:19) [2003-11-27 19:03:46] [EMAIL PROTECTED] Try following: php -n -r var_dump($_SERVER['argv']); 1 2 3 [2003-11-11 12:52:32] danielc at analysisandsolutions dot com Description: $_SERVER['argv'] and $_SERVER['argc'] aren't created. php.ini and phpinfo() show register_argc_argv as being On. Behavior is the same via CLI or CGI binaries. Substituted a known good php.ini file to see ensure the file was getting parsed. Same results. Everything worked fine under 500b2-dev--php5-win32-200310010230 Problem began when upgraded to 500b2-dev--php5-win32-200311040330 Persists in the current CVS snapshot 500b3-dev--php5-win32-20031530 Reproduce code: --- #! c:/progra~1/php/cli/php ?php print_r($_SERVER['argv']); ? now execute test script... ./t.php fjiao Expected result: Array ( [0] = ./t.php [1] = fjiao ) Actual result: -- Notice: Undefined index: argv in d:\t.php on line 3 -- Edit this bug report at http://bugs.php.net/?id=26206edit=1
#26418 [Fbk-Opn]: loading class files crashes
ID: 26418 User updated by: danielc at analysisandsolutions dot com Reported By: danielc at analysisandsolutions dot com -Status: Feedback +Status: Open Bug Type: Zend Engine 2 problem Operating System: Windows 2000 PHP Version: 5CVS-2003-11-26 (dev) New Comment: Same problem with new snapshot: php5-win32-200312010330.zip Previous Comments: [2003-11-28 23:48:43] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2003-11-26 02:24:47] danielc at analysisandsolutions dot com Description: Using the latest snapshot, php5-win32-200311260330.zip, when a script loads up a bunch of class files, a Dr Watson error dialog appears saying PHP has crashed. Note, I'm just including the files, not creating an object via new. I've tried to pin this down to some particular lines of code, but have been unable to find something in particular. While certain combinations of my class files and PEAR::DB create the crash, others don't. This code worked fine until now, so I don't think it's the content. In addition, I've tweaked PEAR.php and DB.php so methods that return by reference are always returning variables. Below is an excerpt from a dump file as examined by WinDbg: (5e4.600): Access violation - code c005 (!!! second chance !!!) eax=00866dfc ebx=00d9ad80 ecx=6e692e67 edx=0063 esi=00d9c5e0 edi=00d9c658 eip=100dcf91 esp=0012fae8 ebp=78001db0 iopl=0 nv up ei pl nz na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs= efl=0202 *** WARNING: Unable to verify checksum for php4ts.dll *** ERROR: Symbol file could not be found. Defaulted to export symbols for php4ts.dll - php4ts!zend_ts_hash_rehash+481: 100dcf91 89510c mov [ecx+0xc],edx ds:0023:6e692e73= -- Edit this bug report at http://bugs.php.net/?id=26418edit=1
#26206 [Fbk-Opn]: argv and argc not defined
ID: 26206 User updated by: danielc at analysisandsolutions dot com Reported By: danielc at analysisandsolutions dot com -Status: Feedback +Status: Open Bug Type: CGI related Operating System: Windows 2000 PHP Version: 5CVS-2003-11-11 (dev) New Comment: Your test of ignoring the php.ini file via the -n flag gets it to work as expected. FYI... C:\PROGRA~1\php\cliphp -i | grep argv register_argc_argv = On = On C:\PROGRA~1\php\cliphp -n -i | grep argv register_argc_argv = On = On _SERVER[argv] = Array C:\PROGRA~1\php\cliphp -v PHP 5.0.0b3-dev (cli) (built: Nov 26 2003 04:10:19) Previous Comments: [2003-11-27 19:03:46] [EMAIL PROTECTED] Try following: php -n -r var_dump($_SERVER['argv']); 1 2 3 [2003-11-11 12:52:32] danielc at analysisandsolutions dot com Description: $_SERVER['argv'] and $_SERVER['argc'] aren't created. php.ini and phpinfo() show register_argc_argv as being On. Behavior is the same via CLI or CGI binaries. Substituted a known good php.ini file to see ensure the file was getting parsed. Same results. Everything worked fine under 500b2-dev--php5-win32-200310010230 Problem began when upgraded to 500b2-dev--php5-win32-200311040330 Persists in the current CVS snapshot 500b3-dev--php5-win32-20031530 Reproduce code: --- #! c:/progra~1/php/cli/php ?php print_r($_SERVER['argv']); ? now execute test script... ./t.php fjiao Expected result: Array ( [0] = ./t.php [1] = fjiao ) Actual result: -- Notice: Undefined index: argv in d:\t.php on line 3 -- Edit this bug report at http://bugs.php.net/?id=26206edit=1
#26418 [NEW]: loading class files crashes
From: danielc at analysisandsolutions dot com Operating system: Windows 2000 PHP version: 5CVS-2003-11-26 (dev) PHP Bug Type: Reproducible crash Bug description: loading class files crashes Description: Using the latest snapshot, php5-win32-200311260330.zip, when a script loads up a bunch of class files, a Dr Watson error dialog appears saying PHP has crashed. Note, I'm just including the files, not creating an object via new. I've tried to pin this down to some particular lines of code, but have been unable to find something in particular. While certain combinations of my class files and PEAR::DB create the crash, others don't. This code worked fine until now, so I don't think it's the content. In addition, I've tweaked PEAR.php and DB.php so methods that return by reference are always returning variables. Below is an excerpt from a dump file as examined by WinDbg: (5e4.600): Access violation - code c005 (!!! second chance !!!) eax=00866dfc ebx=00d9ad80 ecx=6e692e67 edx=0063 esi=00d9c5e0 edi=00d9c658 eip=100dcf91 esp=0012fae8 ebp=78001db0 iopl=0 nv up ei pl nz na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs= efl=0202 *** WARNING: Unable to verify checksum for php4ts.dll *** ERROR: Symbol file could not be found. Defaulted to export symbols for php4ts.dll - php4ts!zend_ts_hash_rehash+481: 100dcf91 89510c mov [ecx+0xc],edx ds:0023:6e692e73= -- Edit bug report at http://bugs.php.net/?id=26418edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26418r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26418r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=26418r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=26418r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=26418r=needtrace Try newer version: http://bugs.php.net/fix.php?id=26418r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=26418r=support Expected behavior: http://bugs.php.net/fix.php?id=26418r=notwrong Not enough info:http://bugs.php.net/fix.php?id=26418r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=26418r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=26418r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26418r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=26418r=dst IIS Stability: http://bugs.php.net/fix.php?id=26418r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=26418r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=26418r=float
#26206 [NEW]: argv and argc not defined
From: danielc at analysisandsolutions dot com Operating system: Windows 2000 PHP version: 5CVS-2003-11-11 (dev) PHP Bug Type: Unknown/Other Function Bug description: argv and argc not defined Description: $_SERVER['argv'] and $_SERVER['argc'] aren't created. php.ini and phpinfo() show register_argc_argv as being On. Behavior is the same via CLI or CGI binaries. Substituted a known good php.ini file to see ensure the file was getting parsed. Same results. Everything worked fine under 500b2-dev--php5-win32-200310010230 Problem began when upgraded to 500b2-dev--php5-win32-200311040330 Persists in the current CVS snapshot 500b3-dev--php5-win32-20031530 Reproduce code: --- #! c:/progra~1/php/cli/php ?php print_r($_SERVER['argv']); ? now execute test script... ./t.php fjiao Expected result: Array ( [0] = ./t.php [1] = fjiao ) Actual result: -- Notice: Undefined index: argv in d:\t.php on line 3 -- Edit bug report at http://bugs.php.net/?id=26206edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26206r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26206r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=26206r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=26206r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=26206r=needtrace Try newer version: http://bugs.php.net/fix.php?id=26206r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=26206r=support Expected behavior: http://bugs.php.net/fix.php?id=26206r=notwrong Not enough info:http://bugs.php.net/fix.php?id=26206r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=26206r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=26206r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26206r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=26206r=dst IIS Stability: http://bugs.php.net/fix.php?id=26206r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=26206r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=26206r=float
#26207 [NEW]: date(): add format parameter for colons in UTC offset
From: danielc at analysisandsolutions dot com
Operating system: irrelevant
PHP version: Irrelevant
PHP Bug Type: Feature/Change Request
Bug description: date(): add format parameter for colons in UTC offset
Description:
date('O') produces the offset in +0200 format. It would be nice to be
able to have a format parameter that
outputs the same information but with a colon in it: +02:00.
--
Edit bug report at http://bugs.php.net/?id=26207edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26207r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26207r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=26207r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=26207r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=26207r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=26207r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=26207r=support
Expected behavior: http://bugs.php.net/fix.php?id=26207r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=26207r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=26207r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=26207r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26207r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=26207r=dst
IIS Stability: http://bugs.php.net/fix.php?id=26207r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=26207r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=26207r=float
#23467 [Com]: Showing incorrect Time Zone
ID: 23467
Comment by: danielc at analysisandsolutions dot com
Reported By: John at JGSystems dot net
Status: Verified
Bug Type: Date/time related
Operating System: win32
PHP Version: 4.3.4-dev, 5.0.0b2-dev
New Comment:
Um, sorry if I'm cluttering the list... This bug is half a year old so
I'm wondering if/when it's going to get fixed.
Y'all probably know what's going on, but allow me to clarify what I've
learned about this bug, perhaps it will help someone.
date('T') doesn't work under Windows during Daylight times and there's
no notation of this in the manual. I'll put a user comment in there.
Here's a test script:
?php
echo 'Local: dT='.date('T') . ' dO='.date('O') . '
sZ='.strftime('%Z');
echo \nbr /;
putenv('TZ=EST5EDT');
echo 'EST5EDT: dT='.date('T') . ' dO='.date('O') . '
sZ='.strftime('%Z');
echo \nbr /;
putenv('TZ=PST8PDT');
echo 'PST8PDT: dT='.date('T') . ' dO='.date('O') . '
sZ='.strftime('%Z');
echo \nbr /;
putenv('TZ=GMT0BST');
echo 'GMT0BST: dT='.date('T') . ' dO='.date('O') . '
sZ='.strftime('%Z');
echo \nbr /;
putenv('TZ=MST-3MDT');
echo 'MST-3MDT: dT='.date('T') . ' dO='.date('O') . '
sZ='.strftime('%Z');
echo \nbr /;
putenv('TZ=GMT');
echo 'GMT: dT='.date('T') . ' dO='.date('O') . '
sZ='.strftime('%Z');
?
OUTPUT DURING EASTERN DAYLIGHT TIME
---
Local: dT=BST dO=-0400 sZ=Eastern Daylight Time
EST5EDT: dT=BST dO=-0400 sZ=EDT
PST8PDT: dT=BST dO=-0700 sZ=PDT
GMT0BST: dT=BST dO=+0100 sZ=BST
MST-3MDT: dT=BST dO=+0400 sZ=MDT
GMT: dT=GMT dO=+ sZ=GMT
OUTPUT DURING EASTERN STANDARD TIME
---
Local: dT=Eastern Standard Time dO=-0500 sZ=Eastern Standard Time
EST5EDT: dT=EST dO=-0500 sZ=EST
PST8PDT: dT=PST dO=-0800 sZ=PST
GMT0BST: dT=GMT dO=+ sZ=GMT
MST-3MDT: dT=MST dO=+0300 sZ=MST
GMT: dT=GMT dO=+ sZ=GMT
Previous Comments:
[2003-08-26 22:59:32] [EMAIL PROTECTED]
This is general win32 problem. No need to post anymore comments here,
we know about it.
[2003-08-20 20:35:39] John at JGSystems dot net
Here ya go:
Commands:
echo date(r),br\n;
echo date(I),br\n; // uppercase i
echo date(T),br\n;
Result:
Wed, 20 Aug 2003 19:33:34 -0600
1
BST
This what you wanted? (I hope)
[2003-08-19 23:12:26] John at JGSystems dot net
The time last modified was pasted in the reply.
This page was last modified:
Monday - May 19, 2003 at 4:22 PM BST.
I'll get the current time pasted in tomorrow...
The results of:
echo date(r),\n;
echo date(I),\n; // uppercase i
Too late tonight...
[2003-08-19 22:48:30] [EMAIL PROTECTED]
I wanted to know the TIME...not the time zone..
[2003-08-19 21:12:06] John at JGSystems dot net
It's a local machine. Win XP. Nothings changed from the items listed
below in this thread or I would have mentioned it.
I downloaded the link, installed it after erasing the last version you
all had me try and the same result. I did tell you that it was
supposed to be -- MDT -- not -- BST --
Thanks...
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/23467
--
Edit this bug report at http://bugs.php.net/?id=23467edit=1
#26090 [NEW]: allow colons in time zone offset to strtotime()
From: danielc at analysisandsolutions dot com
Operating system: n/a
PHP version: 5.0.0b1 (beta1)
PHP Bug Type: Feature/Change Request
Bug description: allow colons in time zone offset to strtotime()
Description:
The strtotime() function doesn't allow time zone offsets to contain colons
: in them. Colons are included in several offset formmating standards.
Reproduce code:
---
$t = '2003-10-28 10:20:30-0800';
echo date('Y-m-d H:i:s T', strtotime($t)) . \nbr /\n;
$t = '2003-10-28 10:20:30-08:00';
echo date('Y-m-d H:i:s T', strtotime($t)) . \n;
Expected result:
2003-10-28 13:20:30 EST
br /
2003-10-28 13:20:30 EST
Actual result:
--
2003-10-28 13:20:30 EST
br /
1969-12-31 18:59:59 EST
On Windows 2000, the attempt with the colons in the offset produces a
negative timestamp, so the beloved Windows does not support dates prior
to midnight warning arises.
--
Edit bug report at http://bugs.php.net/?id=26090edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26090r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26090r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=26090r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=26090r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=26090r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=26090r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=26090r=support
Expected behavior: http://bugs.php.net/fix.php?id=26090r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=26090r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=26090r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=26090r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26090r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=26090r=dst
IIS Stability: http://bugs.php.net/fix.php?id=26090r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=26090r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=26090r=float
#25826 [NEW]: undefined notices via unset()
From: danielc at analysisandsolutions dot com
Operating system: Windows 2000
PHP version: Irrelevant
PHP Bug Type: Zend Engine 2 problem
Bug description: undefined notices via unset()
Description:
unset() acts inconsistently when acting upon array keys that don't exist.
In some cases it throws Notices about Undefined index Undefined
variable and Undefined property.
The behavior varies depending on
a) the dimension of the array trying to be unset
b) whether the array is set
c) if the unset() call is in a class
d) the version of PHP being used
Reproduce code:
---
?php
class test {
var $Array2 = array();
function test() {
unset($this-Nada); // no problem
unset($this-Array1['one:one']);// 4.3.3: Undefined property
// 500b2: no problem
unset($this-Array1['one:two'][1]); // 4.3.3: Undefined property
// 500b2: no problem
unset($this-Array2['two:one']);// no problem
unset($this-Array2['two:two'][1]); // Undefined index
unset($Nada); // no problem
unset($Array3['three:one']);// Undefined variable
unset($Array3['three:two'][1]); // Undefined variable
$Array4 = array();
unset($Array4['four:one']); // no problem
unset($Array4['four:two'][1]); // Undefined index
}
}
$test1 = new test();
unset($Nada); // no problem
unset($Array5['five:one']); // Undefined variable
unset($Array5['five:two'][1]); // Undefined variable
$Array6 = array();
unset($Array6['six:one']); // no problem
unset($Array6['six:two'][1]); // Undefined index
?
Expected result:
No notices at all.
Considering no notice was produced on a non-existant scalar, I expected
the same behavior when trying to unset various arrays, regardless of where
the unset() all is made.
Actual result:
--
PHP 4.3.3
Notice: Undefined property: Array1 in t.php on line 12
Notice: Undefined property: Array1 in t.php on line 13
Notice: Undefined index: two:two in t.php on line 16
Notice: Undefined variable: Array3 in t.php on line 20
Notice: Undefined variable: Array3 in t.php on line 21
Notice: Undefined index: four:two in t.php on line 25
Notice: Undefined variable: Array5 in t.php on line 33
Notice: Undefined variable: Array5 in t.php on line 34
Notice: Undefined index: six:two in t.php on line 38
PHP 500b2-dev 200310010230
Notice: Undefined index: two:two in t.php on line 16
Notice: Undefined variable: Array3 in t.php on line 20
Notice: Undefined variable: Array3 in t.php on line 21
Notice: Undefined index: four:two in t.php on line 25
Notice: Undefined variable: Array5 in t.php on line 33
Notice: Undefined variable: Array5 in t.php on line 34
Notice: Undefined index: six:two in t.php on line 38
--
Edit bug report at http://bugs.php.net/?id=25826edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25826r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25826r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=25826r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=25826r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=25826r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=25826r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=25826r=support
Expected behavior: http://bugs.php.net/fix.php?id=25826r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=25826r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=25826r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=25826r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25826r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=25826r=dst
IIS Stability: http://bugs.php.net/fix.php?id=25826r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=25826r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=25826r=float
#24960 [NEW]: php_domxml.dll in php.ini but not in extensions dir
From: danielc at analysisandsolutions dot com Operating system: Windows PHP version: 5.0.0b1 (beta1) PHP Bug Type: *Configuration Issues Bug description: php_domxml.dll in php.ini but not in extensions dir Description: php_domxml.dll is in the php.ini file but is not in the extensions directory. Please either remove the reference to it from php.ini or add the DLL to the extensions directory. -- Edit bug report at http://bugs.php.net/?id=24960edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=24960r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=24960r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=24960r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=24960r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=24960r=needtrace Try newer version: http://bugs.php.net/fix.php?id=24960r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=24960r=support Expected behavior: http://bugs.php.net/fix.php?id=24960r=notwrong Not enough info:http://bugs.php.net/fix.php?id=24960r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=24960r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=24960r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24960r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=24960r=dst IIS Stability: http://bugs.php.net/fix.php?id=24960r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=24960r=gnused
#24969 [NEW]: multiple DLLs listed in php.ini but not in extensions dir
From: danielc at analysisandsolutions dot com Operating system: Windows PHP version: 5CVS-2003-08-07 (dev) PHP Bug Type: *Configuration Issues Bug description: multiple DLLs listed in php.ini but not in extensions dir Description: In the php5-win32-200308070230.zip snapshot... The php.ini file has several DLLs listed in the Windows Extensions section even though the DLLs in question don't exist in the extensions directory: php_curl.dll php_filepro.dll php_hyperwave.dll php_iisfunc.dll php_java.dll php_ldap.dll php_mbstring.dll php_mssql.dll php_oci8.dll php_openssl.dll php_oracle.dll php_pgsql.dll php_printer.dll php_sockets.dll php_w32api.dll php_xmlrpc.dll php_yaz.dll php_zip.dll -- Edit bug report at http://bugs.php.net/?id=24969edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=24969r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=24969r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=24969r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=24969r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=24969r=needtrace Try newer version: http://bugs.php.net/fix.php?id=24969r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=24969r=support Expected behavior: http://bugs.php.net/fix.php?id=24969r=notwrong Not enough info:http://bugs.php.net/fix.php?id=24969r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=24969r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=24969r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24969r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=24969r=dst IIS Stability: http://bugs.php.net/fix.php?id=24969r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=24969r=gnused
#21783 [NEW]: cli execution doesn't find php.ini
From: [EMAIL PROTECTED]
Operating system: Windows NT 4.0
PHP version: 4.3.0
PHP Bug Type: *Configuration Issues
Bug description: cli execution doesn't find php.ini
Hi:
Please pardon the initial background if it's irrelevant, but I figured it
may come into play somehow...
Been using PHP for years, just fine. It's installed in f:\progra~1\php.
That dir is in my Path, so I keep the php.ini and various dll's there to
make upgrading easy.
Installed latest version, 4.3.0, by moving old version to backup directory
and unzipping binaries into f:\progra~1\php.
Edited php.ini to my tastes.
After running into problems with CLI not finding my php.ini file, I ran
some tests. The test script contains:
echo 'include_path... ' . ini_get('include_path') . \n;
echo 'cfg_file_path... ' . get_cfg_var('cfg_file_path') . \n;
Now I open up command line window and execute:
cd progra~1\php
php ./script
Has the right output:
include_path... .;f:\progra~1\pear
cfg_file_path... F:\PROGRA~1\php\php.ini
But, running the CLI does not:
cli\php ./script
include_path... .;c:\php4\pear
cfg_file_path...
If I copy php.ini to the cli directory, the expected results are
obtained.
One assumes the CLI version would be smart enough to look up one directory
level or in the Path for the php.ini.
Of course, I can specify the config file via the -c flag, but that's
awkward for general use and is counter-intuitive.
I hope the behavior of the CLI executable will be changed accordingly,
please.
Thanks,
--Dan
--
Edit bug report at http://bugs.php.net/?id=21783edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=21783r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=21783r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=21783r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=21783r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=21783r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=21783r=support
Expected behavior: http://bugs.php.net/fix.php?id=21783r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=21783r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=21783r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=21783r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21783r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=21783r=dst
IIS Stability: http://bugs.php.net/fix.php?id=21783r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=21783r=gnused
#21783 [WFx]: cli execution doesn't find php.ini
ID: 21783
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Wont fix
Bug Type: *Configuration Issues
Operating System: Windows NT 4.0
PHP Version: 4.3.0
New Comment:
Okay. Then, can you please change this into a documentation bug? The
features.commandline.php pages should really explain this.
For the clarity of other people reading this, the simple, long-term
solution is creating an environment variable named PHPRC and setting it
to the path of where your php.ini file resides. For example,
c:\progra~1\php
Thanks,
--Dan
Previous Comments:
[2003-01-20 19:05:54] [EMAIL PROTECTED]
This is how cli is designed to work (not to look for php.ini in the
current working directory) and it won't change.
You can achieve the desired behaviour by issuing:
set PHPRC=.
on the command line, or setting this environmental variable elsewhere
in the system.
[2003-01-20 17:29:50] [EMAIL PROTECTED]
Hi:
Please pardon the initial background if it's irrelevant, but I figured
it may come into play somehow...
Been using PHP for years, just fine. It's installed in
f:\progra~1\php. That dir is in my Path, so I keep the php.ini and
various dll's there to make upgrading easy.
Installed latest version, 4.3.0, by moving old version to backup
directory and unzipping binaries into f:\progra~1\php.
Edited php.ini to my tastes.
After running into problems with CLI not finding my php.ini file, I ran
some tests. The test script contains:
echo 'include_path... ' . ini_get('include_path') . \n;
echo 'cfg_file_path... ' . get_cfg_var('cfg_file_path') . \n;
Now I open up command line window and execute:
cd progra~1\php
php ./script
Has the right output:
include_path... .;f:\progra~1\pear
cfg_file_path... F:\PROGRA~1\php\php.ini
But, running the CLI does not:
cli\php ./script
include_path... .;c:\php4\pear
cfg_file_path...
If I copy php.ini to the cli directory, the expected results are
obtained.
One assumes the CLI version would be smart enough to look up one
directory level or in the Path for the php.ini.
Of course, I can specify the config file via the -c flag, but that's
awkward for general use and is counter-intuitive.
I hope the behavior of the CLI executable will be changed accordingly,
please.
Thanks,
--Dan
--
Edit this bug report at http://bugs.php.net/?id=21783edit=1
#21783 [WFx]: cli execution doesn't find php.ini
ID: 21783
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Wont fix
Bug Type: *Configuration Issues
Operating System: Windows NT 4.0
PHP Version: 4.3.0
New Comment:
Thank you for that link. None the less, people reading the
features.commandline.php won't necessarily read the configuration.php
page.
Gee, take me for example! :) I spent a significant amount of time
trying to figure out what was going on. Checked the command line page
in the manual, all of the user comments, the newsgroup archives and the
bug database. All of which turned up nothing, hence my bug report.
So, a simple mention of the situation and a cross reference link to
configuration.php would be helpful.
Heck, I'm fairly PHP literate and a good sleuth, but wound up using
your time anyway. This minor documentation tweak will save everyone
grief in the long run.
Of course, I could add a user comment, but that doesn't have the same
impact.
Thanks for your consideration,
--Dan
Previous Comments:
[2003-01-20 19:51:29] [EMAIL PROTECTED]
PHPRC environmental variable (and other ways of finding it) are
documented at:
http://www.php.net/manual/en/configuration.php#configuration.file
[2003-01-20 19:44:22] [EMAIL PROTECTED]
Okay. Then, can you please change this into a documentation bug? The
features.commandline.php pages should really explain this.
For the clarity of other people reading this, the simple, long-term
solution is creating an environment variable named PHPRC and setting it
to the path of where your php.ini file resides. For example,
c:\progra~1\php
Thanks,
--Dan
[2003-01-20 19:05:54] [EMAIL PROTECTED]
This is how cli is designed to work (not to look for php.ini in the
current working directory) and it won't change.
You can achieve the desired behaviour by issuing:
set PHPRC=.
on the command line, or setting this environmental variable elsewhere
in the system.
[2003-01-20 17:29:50] [EMAIL PROTECTED]
Hi:
Please pardon the initial background if it's irrelevant, but I figured
it may come into play somehow...
Been using PHP for years, just fine. It's installed in
f:\progra~1\php. That dir is in my Path, so I keep the php.ini and
various dll's there to make upgrading easy.
Installed latest version, 4.3.0, by moving old version to backup
directory and unzipping binaries into f:\progra~1\php.
Edited php.ini to my tastes.
After running into problems with CLI not finding my php.ini file, I ran
some tests. The test script contains:
echo 'include_path... ' . ini_get('include_path') . \n;
echo 'cfg_file_path... ' . get_cfg_var('cfg_file_path') . \n;
Now I open up command line window and execute:
cd progra~1\php
php ./script
Has the right output:
include_path... .;f:\progra~1\pear
cfg_file_path... F:\PROGRA~1\php\php.ini
But, running the CLI does not:
cli\php ./script
include_path... .;c:\php4\pear
cfg_file_path...
If I copy php.ini to the cli directory, the expected results are
obtained.
One assumes the CLI version would be smart enough to look up one
directory level or in the Path for the php.ini.
Of course, I can specify the config file via the -c flag, but that's
awkward for general use and is counter-intuitive.
I hope the behavior of the CLI executable will be changed accordingly,
please.
Thanks,
--Dan
--
Edit this bug report at http://bugs.php.net/?id=21783edit=1
