[PHP-BUG] Req #65406 [NEW]: Enchant broker plugins are in the wrong place in windows builds
From: bill at zeroedin dot com Operating system: windows PHP version: 5.4.17 Package: Enchant related Bug Type: Feature/Change Request Bug description:Enchant broker plugins are in the wrong place in windows builds Description: As noted in bug #64593 and bug #64397, libenchant.dll now looks for the included broker plugins libenchant_ispell.dll and libenchant_myspell.dll in php_root/lib/enchant instead of php_root. The windows builds provided at windows.php.net have the broker plugin dlls in the php_root directory. Please change the build process to place the enchant broker plugins in the correct location. -- Edit bug report at https://bugs.php.net/bug.php?id=65406edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=65406r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=65406r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=65406r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=65406r=fixed Fixed in release: https://bugs.php.net/fix.php?id=65406r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=65406r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=65406r=needscript Try newer version: https://bugs.php.net/fix.php?id=65406r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=65406r=support Expected behavior: https://bugs.php.net/fix.php?id=65406r=notwrong Not enough info: https://bugs.php.net/fix.php?id=65406r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=65406r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=65406r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65406r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=65406r=dst IIS Stability: https://bugs.php.net/fix.php?id=65406r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=65406r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=65406r=float No Zend Extensions: https://bugs.php.net/fix.php?id=65406r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=65406r=mysqlcfg
#50788 [NEW]: GD relies on out-of-date libpng
From: Bill dot public at Eccles dot net Operating system: MacOS X 10.6 PHP version: 5.3.1 PHP Bug Type: GD related Bug description: GD relies on out-of-date libpng Description: Attempting to make PHP 5.3.1 using libpng 1.4.0 (which was released 1/3/2010, I think) reveals that GD relies on the deprecated, and now removed in v1.4.0, _png_check_sig in _php_gd_gdImageCreateFromPngCtx in gd_png.o. Reproduce code: --- No code necessary. configure/make/make install libpng 1.4.0, point PHP's configure at the library. Expected result: Successful compile. Actual result: -- Undefined symbols: _png_check_sig, referenced from: _php_gd_gdImageCreateFromPngCtx in gd_png.o -- Edit bug report at http://bugs.php.net/?id=50788edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50788r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50788r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50788r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50788r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50788r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50788r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50788r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50788r=needscript Try newer version: http://bugs.php.net/fix.php?id=50788r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50788r=support Expected behavior: http://bugs.php.net/fix.php?id=50788r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50788r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50788r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50788r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50788r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50788r=dst IIS Stability: http://bugs.php.net/fix.php?id=50788r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50788r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50788r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50788r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50788r=mysqlcfg
#50432 [Opn]: setting for display_errors not being honored
ID: 50432 User updated by: bill dot mcclendon at digiconllc dot com Reported By: bill dot mcclendon at digiconllc dot com Status: Open Bug Type: PHP options/info functions Operating System: win32 only - Windows Server 2008 PHP Version: 5.3.1 New Comment: It may be a Windows installation issue - but the installation was via the install version from the windows.php.net download link. So, it's built into it. Previous Comments: [2009-12-11 22:35:36] j...@php.net Quite likely some installation issue on windows, works fine on *nix. [2009-12-11 20:42:18] bill dot mcclendon at digiconllc dot com Am I sure? You did see the reference to phpinfo() - right? It shows the one and only php.ini file that exists on this server and instance and it's the one I edited. Bill [2009-12-09 20:28:42] paj...@php.net Are you sure the right php.ini is loaded? [2009-12-09 20:11:04] bill dot mcclendon at digiconllc dot com Description: When using 5.3.1 for Windows (VC6 non thread safe) build, the php.ini settings for display_errors=Off is ignored and E_NOTICE messages display in the web page results from PHP. This can also be seen via phpinfo() which shows the setting On. If I run php -i from the command window, the setting correctly shows Off. Windows Server 2008 IIS 7.0 PHP 5.3.1 (binary .msi install from windows.php.net) Reproduce code: --- ? phpinfo();? Expected result: display_errors Off Actual result: -- display_errors On -- Edit this bug report at http://bugs.php.net/?id=50432edit=1
#50432 [Fbk-Opn]: setting for display_errors not being honored
ID: 50432 User updated by: bill dot mcclendon at digiconllc dot com Reported By: bill dot mcclendon at digiconllc dot com -Status: Feedback +Status: Open Bug Type: Scripting Engine problem Operating System: Windows Server 2008 PHP Version: 5.3.1 New Comment: Am I sure? You did see the reference to phpinfo() - right? It shows the one and only php.ini file that exists on this server and instance and it's the one I edited. Bill Previous Comments: [2009-12-09 20:28:42] paj...@php.net Are you sure the right php.ini is loaded? [2009-12-09 20:11:04] bill dot mcclendon at digiconllc dot com Description: When using 5.3.1 for Windows (VC6 non thread safe) build, the php.ini settings for display_errors=Off is ignored and E_NOTICE messages display in the web page results from PHP. This can also be seen via phpinfo() which shows the setting On. If I run php -i from the command window, the setting correctly shows Off. Windows Server 2008 IIS 7.0 PHP 5.3.1 (binary .msi install from windows.php.net) Reproduce code: --- ? phpinfo();? Expected result: display_errors Off Actual result: -- display_errors On -- Edit this bug report at http://bugs.php.net/?id=50432edit=1
#50432 [NEW]: setting for display_errors not being honored
From: bill dot mcclendon at digiconllc dot com Operating system: Windows Server 2008 PHP version: 5.3.1 PHP Bug Type: Scripting Engine problem Bug description: setting for display_errors not being honored Description: When using 5.3.1 for Windows (VC6 non thread safe) build, the php.ini settings for display_errors=Off is ignored and E_NOTICE messages display in the web page results from PHP. This can also be seen via phpinfo() which shows the setting On. If I run php -i from the command window, the setting correctly shows Off. Windows Server 2008 IIS 7.0 PHP 5.3.1 (binary .msi install from windows.php.net) Reproduce code: --- ? phpinfo();? Expected result: display_errors Off Actual result: -- display_errors On -- Edit bug report at http://bugs.php.net/?id=50432edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50432r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50432r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50432r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50432r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50432r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50432r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50432r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50432r=needscript Try newer version: http://bugs.php.net/fix.php?id=50432r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50432r=support Expected behavior: http://bugs.php.net/fix.php?id=50432r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50432r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50432r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50432r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50432r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50432r=dst IIS Stability: http://bugs.php.net/fix.php?id=50432r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50432r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50432r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50432r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50432r=mysqlcfg
#49827 [Bgs]: shell_exec using ls /home fails with Permission denied
ID: 49827 User updated by: bill dot mcclendon at digiconllc dot com Reported By: bill dot mcclendon at digiconllc dot com Status: Bogus Bug Type: Unknown/Other Function Operating System: Linux RH PHP Version: 5.2.11 New Comment: No, the ls program was not executed successfully. Only when the target was /tmp or /usr. Any and all other paths - including sub-directorties under /usr - failed with a permission violation. I found the root cause and solved the issue. You can close this bug report. You may want to add a note/description of this issue so others are not so trapped. The root cause was SELinux. It had been enabled and set to enforced and this prevented anything from running that was not in the vary basic, very SMALL list of commands configured for the default SELinux delivery. The system administrators were unaware of SELinux and had no knowledge of it being configured - or even what it was. Bill Previous Comments: [2009-10-14 17:05:16] sjo...@php.net Thank you for your feedback. The behavior you report is not a bug in PHP. The 'ls' program is executed succesfully and it gives the 'Permission denied' error, not PHP. The home directory may be mounted over NFS or there may be some other reason why there are additional access restrictions. [2009-10-13 18:37:09] bill dot mcclendon at digiconllc dot com PHP bug reporting/support. 1) No ACL's (you think I didn't check this already?) 2) You mean grave accent? Yes - same error (I checked that already too). It's not running in a VM either. Bill [2009-10-10 12:02:17] sjo...@php.net Thank you for your bug report. Does your installation have other access control than UNIX permissions, such as ACL? Can you succesfully execute 'ls /home' from the command line, or using backticks in PHP? [2009-10-09 22:49:50] bill dot mcclendon at digiconllc dot com Corrected email address (your form seems to have a problem) [2009-10-09 22:48:30] bill dot mcclendon at digiconllc dot com Description: Running Apache 2.x and PHP 5.2 safe_mode = off test case - using ?php $cmd = 'ls /home'; shell_exec($cmd); ? produces the error ls: /home Permission denied using ?php $cmd = 'ls /usr'; shell_exec($cmd); ? succeeds (check the Apache error_log for errors) However, both /home and /usr have the EXACT same permission and ownership. and Apache is running with User owner where owner is the owner of the contents of /home. Listing of both paths: 8 drwxr-xr-x 15 root root4096 Jun 24 2005 usr 8 drwxr-xr-x5 root root4096 Jan 8 2007 home Shell is /bin/bash and it looks like: 764 -rwxr-xr-x 1 root root 772760 Dec 6 2004 /bin/bash Any ideas? Reproduce code: --- Test cases: FAIL: ?php $cmd = 'ls /home'; echo pre.shell_exec($cmd)./pre; ? SUCCESS: ?php $cmd = 'ls /usr'; echo pre.shell_exec($cmd)./pre; ? Expected result: Listing of files: SUCCESS result: bin etc games include kerberos lib lib64 libexec local sbin share src tmp X11R6 Actual result: -- For FAIL above (no results). -- Edit this bug report at http://bugs.php.net/?id=49827edit=1
#49827 [Fbk-Opn]: shell_exec using ls /home fails with Permission denied
ID: 49827 User updated by: bill dot mcclendon at digiconllc dot com Reported By: bill dot mcclendon at digiconllc dot com -Status: Feedback +Status: Open Bug Type: Unknown/Other Function Operating System: Linux RH PHP Version: 5.2.11 New Comment: PHP bug reporting/support. 1) No ACL's (you think I didn't check this already?) 2) You mean grave accent? Yes - same error (I checked that already too). It's not running in a VM either. Bill Previous Comments: [2009-10-10 12:02:17] sjo...@php.net Thank you for your bug report. Does your installation have other access control than UNIX permissions, such as ACL? Can you succesfully execute 'ls /home' from the command line, or using backticks in PHP? [2009-10-09 22:49:50] bill dot mcclendon at digiconllc dot com Corrected email address (your form seems to have a problem) [2009-10-09 22:48:30] bill dot mcclendon at digiconllc dot com Description: Running Apache 2.x and PHP 5.2 safe_mode = off test case - using ?php $cmd = 'ls /home'; shell_exec($cmd); ? produces the error ls: /home Permission denied using ?php $cmd = 'ls /usr'; shell_exec($cmd); ? succeeds (check the Apache error_log for errors) However, both /home and /usr have the EXACT same permission and ownership. and Apache is running with User owner where owner is the owner of the contents of /home. Listing of both paths: 8 drwxr-xr-x 15 root root4096 Jun 24 2005 usr 8 drwxr-xr-x5 root root4096 Jan 8 2007 home Shell is /bin/bash and it looks like: 764 -rwxr-xr-x 1 root root 772760 Dec 6 2004 /bin/bash Any ideas? Reproduce code: --- Test cases: FAIL: ?php $cmd = 'ls /home'; echo pre.shell_exec($cmd)./pre; ? SUCCESS: ?php $cmd = 'ls /usr'; echo pre.shell_exec($cmd)./pre; ? Expected result: Listing of files: SUCCESS result: bin etc games include kerberos lib lib64 libexec local sbin share src tmp X11R6 Actual result: -- For FAIL above (no results). -- Edit this bug report at http://bugs.php.net/?id=49827edit=1
#49827 [NEW]: shell_exec using ls /home fails with Permission denied
From: bill dot mcclendon at digiconllc dot com Operating system: Linux RH PHP version: 5.2.11 PHP Bug Type: Unknown/Other Function Bug description: shell_exec using ls /home fails with Permission denied Description: Running Apache 2.x and PHP 5.2 safe_mode = off test case - using ?php $cmd = 'ls /home'; shell_exec($cmd); ? produces the error ls: /home Permission denied using ?php $cmd = 'ls /usr'; shell_exec($cmd); ? succeeds (check the Apache error_log for errors) However, both /home and /usr have the EXACT same permission and ownership. and Apache is running with User owner where owner is the owner of the contents of /home. Listing of both paths: 8 drwxr-xr-x 15 root root4096 Jun 24 2005 usr 8 drwxr-xr-x5 root root4096 Jan 8 2007 home Shell is /bin/bash and it looks like: 764 -rwxr-xr-x 1 root root 772760 Dec 6 2004 /bin/bash Any ideas? Reproduce code: --- Test cases: FAIL: ?php $cmd = 'ls /home'; echo pre.shell_exec($cmd)./pre; ? SUCCESS: ?php $cmd = 'ls /usr'; echo pre.shell_exec($cmd)./pre; ? Expected result: Listing of files: SUCCESS result: bin etc games include kerberos lib lib64 libexec local sbin share src tmp X11R6 Actual result: -- For FAIL above (no results). -- Edit bug report at http://bugs.php.net/?id=49827edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49827r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49827r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49827r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49827r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49827r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49827r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49827r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49827r=needscript Try newer version: http://bugs.php.net/fix.php?id=49827r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49827r=support Expected behavior: http://bugs.php.net/fix.php?id=49827r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49827r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49827r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49827r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49827r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49827r=dst IIS Stability: http://bugs.php.net/fix.php?id=49827r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49827r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49827r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49827r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49827r=mysqlcfg
#49827 [Opn]: shell_exec using ls /home fails with Permission denied
ID: 49827 User updated by: bill dot mcclendon at digiconllc dot com Reported By: bill dot mcclendon at digiconllc dot com Status: Open Bug Type: Unknown/Other Function Operating System: Linux RH PHP Version: 5.2.11 New Comment: Corrected email address (your form seems to have a problem) Previous Comments: [2009-10-09 22:48:30] bill dot mcclendon at digiconllc dot com Description: Running Apache 2.x and PHP 5.2 safe_mode = off test case - using ?php $cmd = 'ls /home'; shell_exec($cmd); ? produces the error ls: /home Permission denied using ?php $cmd = 'ls /usr'; shell_exec($cmd); ? succeeds (check the Apache error_log for errors) However, both /home and /usr have the EXACT same permission and ownership. and Apache is running with User owner where owner is the owner of the contents of /home. Listing of both paths: 8 drwxr-xr-x 15 root root4096 Jun 24 2005 usr 8 drwxr-xr-x5 root root4096 Jan 8 2007 home Shell is /bin/bash and it looks like: 764 -rwxr-xr-x 1 root root 772760 Dec 6 2004 /bin/bash Any ideas? Reproduce code: --- Test cases: FAIL: ?php $cmd = 'ls /home'; echo pre.shell_exec($cmd)./pre; ? SUCCESS: ?php $cmd = 'ls /usr'; echo pre.shell_exec($cmd)./pre; ? Expected result: Listing of files: SUCCESS result: bin etc games include kerberos lib lib64 libexec local sbin share src tmp X11R6 Actual result: -- For FAIL above (no results). -- Edit this bug report at http://bugs.php.net/?id=49827edit=1
#48565 [NoF-Opn]: Transparent session ID occasionally not added
ID: 48565 User updated by: bill at rubgrp dot com Reported By: bill at rubgrp dot com -Status: No Feedback +Status: Open Bug Type: Session related Operating System: Linux (Fedora 11) PHP Version: 5.2.9 New Comment: Sorry for the delay - chaos intervened. The 5.3 snapshot works on Fedora 11. I've also found that the 5.2.9 version works on at least one other platform (Mac), so perhaps it is an issue with something specific Fedora is doing in their version. Previous Comments: [2009-07-02 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2009-06-24 11:22:31] j...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2009-06-15 22:45:57] bill at rubgrp dot com Description: Sometimes when adding a session ID to a URL, it is not added after existing parameters, but rather iafter the closing quote for the URL. For example, an anchor tag of 'a href=xyzzy.php?arg=y' would be rewritten as 'a href=xyzzy.php?arg=y?PHPSESSID=123...' instead of 'a href=xyzzy.php?arg=yPHPSESSID=123...'. This appears to be similar to the issue reported in bug #3411. It appears to be buffer related, since adding or subtracting a few characters from earlier in the page can introduce or eliminate the error. As mentioned in #3411, turning on output buffering eliminates the problem. This seemed to work correctly through 5.2.5, but has not worked since 5.2.6. Reproduce code: --- Since it appears to be dependent on the number of bytes in the buffer, it can't be reproduced in 20 lines. Here is a link to a page that generated the examples: http://www.rubgrp.com/~bill/sample.php Expected result: a href=custmain.php?srch=06PHPSESSID=ho7ev8p2bmc16rotaih4duat8206/a ...snip... a href=custmain.php?srch=07PHPSESSID=ho7ev8p2bmc16rotaih4duat8207/a ..snip... a href=custmain.php?srch=08PHPSESSID=ho7ev8p2bmc16rotaih4duat8208/a/td Actual result: -- a href=custmain.php?srch=06PHPSESSID=ho7ev8p2bmc16rotaih4duat8206/a ...snip... a href=custmain.php?srch=07?PHPSESSID=ho7ev8p2bmc16rotaih4duat8207/a ..snip... a href=custmain.php?srch=08PHPSESSID=ho7ev8p2bmc16rotaih4duat8208/a/td (The first and third are correct; in the second line the session ID is added after the closing quote on the href value.) -- Edit this bug report at http://bugs.php.net/?id=48565edit=1
#48565 [NEW]: Transparent session ID occasionally not added
From: bill at rubgrp dot com Operating system: Linux (Fedora 11) PHP version: 5.2.9 PHP Bug Type: Session related Bug description: Transparent session ID occasionally not added Description: Sometimes when adding a session ID to a URL, it is not added after existing parameters, but rather iafter the closing quote for the URL. For example, an anchor tag of 'a href=xyzzy.php?arg=y' would be rewritten as 'a href=xyzzy.php?arg=y?PHPSESSID=123...' instead of 'a href=xyzzy.php?arg=yPHPSESSID=123...'. This appears to be similar to the issue reported in bug #3411. It appears to be buffer related, since adding or subtracting a few characters from earlier in the page can introduce or eliminate the error. As mentioned in #3411, turning on output buffering eliminates the problem. This seemed to work correctly through 5.2.5, but has not worked since 5.2.6. Reproduce code: --- Since it appears to be dependent on the number of bytes in the buffer, it can't be reproduced in 20 lines. Here is a link to a page that generated the examples: http://www.rubgrp.com/~bill/sample.php Expected result: a href=custmain.php?srch=06PHPSESSID=ho7ev8p2bmc16rotaih4duat8206/a ...snip... a href=custmain.php?srch=07PHPSESSID=ho7ev8p2bmc16rotaih4duat8207/a ..snip... a href=custmain.php?srch=08PHPSESSID=ho7ev8p2bmc16rotaih4duat8208/a/td Actual result: -- a href=custmain.php?srch=06PHPSESSID=ho7ev8p2bmc16rotaih4duat8206/a ...snip... a href=custmain.php?srch=07?PHPSESSID=ho7ev8p2bmc16rotaih4duat8207/a ..snip... a href=custmain.php?srch=08PHPSESSID=ho7ev8p2bmc16rotaih4duat8208/a/td (The first and third are correct; in the second line the session ID is added after the closing quote on the href value.) -- Edit bug report at http://bugs.php.net/?id=48565edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48565r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48565r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48565r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48565r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48565r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48565r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48565r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48565r=needscript Try newer version: http://bugs.php.net/fix.php?id=48565r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48565r=support Expected behavior: http://bugs.php.net/fix.php?id=48565r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48565r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48565r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48565r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48565r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48565r=dst IIS Stability: http://bugs.php.net/fix.php?id=48565r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48565r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48565r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48565r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48565r=mysqlcfg
#44942 [Com]: exec() hangs apache
ID: 44942 Comment by: bill at sammer dot com Reported By: inqualab1985 at gmail dot com Status: No Feedback Bug Type: Program Execution Operating System: Windows 2000 SP4 PHP Version: 5.2.5 New Comment: session_write_close fixes it for me too. Thanks vlabella! Previous Comments: [2008-12-04 04:35:44] dominic dot manley at det dot wa dot edu dot au Big thanks to vlabella who led us to a work-around. This is one VERY frustrating bug to track down! We have an Apache/PHP 5.2.3/Win2003 setup and concurrent calls to a script that exec()-ed the same command-line .exe caused the process to get caught up on the server. Apache wouldn't let go of it and the only way to kill the process and get the site/sometimes whole server back was to restart Apache. I never would have suspected sessions causing this issue... none of our investigations led us close to that direction. However, vlabella got it spot on... Calling session_write_close() before an exec() (or simply never initiating session support to start with using session_start()) works around the issue. [2008-10-21 09:26:44] neododge at free dot fr The same problem happens for me on PHP 5.2.6 / Apache 2.2.9, Apache won't run any PHP after I try an exec/passthru/`` -no matter what command I try. Only way to get PHP back seems to be closing all browser windows that point to my server and waiting for a while before trying to use a PHP page again. [2008-09-15 17:01:02] vlabella at uamail dot albany dot edu We have been having the same issue for a long time on win2003 with php version 5.2.X and apache 5.2.x calling both perl scripts and .exe with the exec fuinction. We found that it mostly happens when php runs exec concurrently on the same process. For example we would have ajax call do an exec on the server to read some data and feed it back to the user every 5 seconds. In addition the user could do an ajax call to do something as well on this page. if the user call came at the same time as the schdeduled call then php would hang and we would have to restart apache. We found it also happens on pages where there are multiple exec() calls. We find that all the scripts and programs we call run fine its just that php hangs when they finish for some reason. We have our max_execution_time set to 30 minutes so its not a timeout issue. We found that calling session_write_close(); before each exec call seemed to resolve this issue. But we are not really sure why and what other effects session_write_close(); may have on other processes. Hope this helps resolve this issue. it is a major headache for us for the past 2 years!! [2008-08-08 18:55:29] jumpbackhack at gmail dot com this is still a bug. this is not an apache issue as I have tested various versions ranging from 2.0.x to 2.2.x I have tested php v5.2.6 and even a late development version. This happens on linux OS as well even with shell_exec() would there be a backtrace on a hang? it appears that the hang happens after a successful script executes, the following time the script runs there is the hang. usually lasts 2-5 minutes before it allows apache to run any php again. note that apache will serve static/html files without issue while any php files are not called. even a restart of apache does not resolve. [2008-07-22 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. 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/44942 -- Edit this bug report at http://bugs.php.net/?id=44942edit=1
#46866 [Bgs]: xml_parse now ignoring html entities in the xml
ID: 46866 User updated by: bill at billjill dot org Reported By: bill at billjill dot org Status: Bogus Bug Type: *XML functions Operating System: Linux PHP Version: 5.2.8 New Comment: My apologies. Many thanks for pointing me toward the correct bug report. Previous Comments: [2008-12-16 14:20:28] rricha...@php.net Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Thank you for your interest in PHP. Dupe of bug #45996 [2008-12-15 03:57:35] bill at billjill dot org Description: Under 5.2.6 and earlier version, the xml parser would correctly read in html entities (such as lt;) in the XML. In 5.2.8, these entities are being ignored Reproduce code: --- You can see the source for a simple test program here: http://outofthebloo.com/test/xmlparsertest.php.txt Expected result: Do a View Source on the result of the xmlparsertest.php program, and you should see this (see the portion toward the bottom near This should be bold) Array ( [0] = Array ( [name] = OVERLAYS [attrs] = Array ( ) [children] = Array ( [0] = Array ( [name] = OVERLAY [attrs] = Array ( ) [children] = Array ( [0] = Array ( [name] = NAME [attrs] = Array ( ) [tagData] = Test ) [1] = Array ( [name] = TYPE [attrs] = Array ( ) [tagData] = template ) [2] = Array ( [name] = SYNTAX [attrs] = Array ( ) [tagData] = div id=quotebThis should be bold/b/div ) ) ) ) ) ) Actual result: -- Here's the actual result. NOTE that the and tag characters are missing near the This should be bold text: Array ( [0] = Array ( [name] = OVERLAYS [attrs] = Array ( ) [children] = Array ( [0] = Array ( [name] = OVERLAY [attrs] = Array ( ) [children] = Array ( [0] = Array ( [name] = NAME [attrs] = Array ( ) [tagData] = Test ) [1] = Array ( [name] = TYPE [attrs] = Array ( ) [tagData] = template ) [2] = Array ( [name] = SYNTAX [attrs] = Array ( ) [tagData
#46866 [NEW]: xml_parse now ignoring html entities in the xml
From: bill at billjill dot org Operating system: Linux PHP version: 5.2.8 PHP Bug Type: XML Reader Bug description: xml_parse now ignoring html entities in the xml Description: Under 5.2.6 and earlier version, the xml parser would correctly read in html entities (such as lt;) in the XML. In 5.2.8, these entities are being ignored Reproduce code: --- You can see the source for a simple test program here: http://outofthebloo.com/test/xmlparsertest.php.txt Expected result: Do a View Source on the result of the xmlparsertest.php program, and you should see this (see the portion toward the bottom near This should be bold) Array ( [0] = Array ( [name] = OVERLAYS [attrs] = Array ( ) [children] = Array ( [0] = Array ( [name] = OVERLAY [attrs] = Array ( ) [children] = Array ( [0] = Array ( [name] = NAME [attrs] = Array ( ) [tagData] = Test ) [1] = Array ( [name] = TYPE [attrs] = Array ( ) [tagData] = template ) [2] = Array ( [name] = SYNTAX [attrs] = Array ( ) [tagData] = div id=quotebThis should be bold/b/div ) ) ) ) ) ) Actual result: -- Here's the actual result. NOTE that the and tag characters are missing near the This should be bold text: Array ( [0] = Array ( [name] = OVERLAYS [attrs] = Array ( ) [children] = Array ( [0] = Array ( [name] = OVERLAY [attrs] = Array ( ) [children] = Array ( [0] = Array ( [name] = NAME [attrs] = Array ( ) [tagData] = Test ) [1] = Array ( [name] = TYPE [attrs] = Array ( ) [tagData] = template ) [2] = Array ( [name] = SYNTAX [attrs] = Array ( ) [tagData] = div id=quotebThis should be bold/b/div ) ) ) ) ) ) -- Edit bug report at http://bugs.php.net/?id=46866edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=46866r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=46866r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=46866r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=46866r=fixedcvs Fixed in CVS and need be documented: http
#45754 [Bgs]: IE loses session variables
ID: 45754 User updated by: bill at grandcentralapartments dot com Reported By: bill at grandcentralapartments dot com Status: Bogus Bug Type: Session related Operating System: Server or client? PHP Version: 5.2.6 New Comment: I don't think you should be calling this report bogus based only on a guess that I'm doing something wrong, and that you've never encountered this problem before. If you have any doubts about it, try googling IE session variables PHP, as I did. You might find some of the hits illuminating. A problem as widespread as this deserves better than a brush-off. I had a hard enough time getting to this location, and was unaware of the forum you mention. Previous Comments: [2008-08-08 18:15:24] [EMAIL PROTECTED] You're doing something wrong and guessing from this is totally useless. Please ask this on the [EMAIL PROTECTED] mailing list. FYI: I have never experienced any problems with any browsers supporting cookies (including IE) in any site where I've used sessions. [2008-08-08 05:41:37] bill at grandcentralapartments dot com Description: It would be really helpful if somebody would post somewhere a comprehensive discussion of the session-related issues pertaining to IE. When I google these issues, I get more than 32K hits, so the problem is not rare. I've read some of the posts and tried the suggestions therein, but none of them have helped me a bit, possibly because they are just random guesses. I don't want debugging help. I'd settle for any professional serious description of what is going on and how I can work around it. I can't imagine that nobody has ever run into these problems before. I'd settle for a semi-professional (but serious) opinion. In case this isn't clear, my problem is that under IE (and only IE), the PHPSESSID cookie is being quietly rejected. For security reasons, I don't want to pass the session id as part of the URL. Would it help (or be harmless) if I were to explicitly save the PHPSESSID under IE? IE seems to have no problem accepting regular cookies from with my code. Is it time zone related, as some have suggested? Is it because I'm executing files in a subfolder under the main site? I just want to know what's going on, so I can change my setup appropriately. -- Edit this bug report at http://bugs.php.net/?id=45754edit=1
#45754 [NEW]: IE loses session variables
From: bill at grandcentralapartments dot com Operating system: Server or client? PHP version: 5.2.6 PHP Bug Type: Session related Bug description: IE loses session variables Description: It would be really helpful if somebody would post somewhere a comprehensive discussion of the session-related issues pertaining to IE. When I google these issues, I get more than 32K hits, so the problem is not rare. I've read some of the posts and tried the suggestions therein, but none of them have helped me a bit, possibly because they are just random guesses. I don't want debugging help. I'd settle for any professional serious description of what is going on and how I can work around it. I can't imagine that nobody has ever run into these problems before. I'd settle for a semi-professional (but serious) opinion. In case this isn't clear, my problem is that under IE (and only IE), the PHPSESSID cookie is being quietly rejected. For security reasons, I don't want to pass the session id as part of the URL. Would it help (or be harmless) if I were to explicitly save the PHPSESSID under IE? IE seems to have no problem accepting regular cookies from with my code. Is it time zone related, as some have suggested? Is it because I'm executing files in a subfolder under the main site? I just want to know what's going on, so I can change my setup appropriately. -- Edit bug report at http://bugs.php.net/?id=45754edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=45754r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=45754r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=45754r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=45754r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=45754r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=45754r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=45754r=needscript Try newer version:http://bugs.php.net/fix.php?id=45754r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=45754r=support Expected behavior:http://bugs.php.net/fix.php?id=45754r=notwrong Not enough info: http://bugs.php.net/fix.php?id=45754r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=45754r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=45754r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45754r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=45754r=dst IIS Stability:http://bugs.php.net/fix.php?id=45754r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=45754r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=45754r=float No Zend Extensions: http://bugs.php.net/fix.php?id=45754r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=45754r=mysqlcfg
#43989 [NEW]: bad php.net link
From: bill at texascrazy dot com Operating system: PHP version: 5.2.5 PHP Bug Type: *General Issues Bug description: bad php.net link Description: The php.net website has a bad link on this page: http://us3.php.net/manual/en/tutorial.firstpage.php See the PHP editor link -- Edit bug report at http://bugs.php.net/?id=43989edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=43989r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=43989r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=43989r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=43989r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=43989r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=43989r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=43989r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=43989r=needscript Try newer version:http://bugs.php.net/fix.php?id=43989r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=43989r=support Expected behavior:http://bugs.php.net/fix.php?id=43989r=notwrong Not enough info: http://bugs.php.net/fix.php?id=43989r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=43989r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=43989r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43989r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=43989r=dst IIS Stability:http://bugs.php.net/fix.php?id=43989r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=43989r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=43989r=float No Zend Extensions: http://bugs.php.net/fix.php?id=43989r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=43989r=mysqlcfg
#39835 [Com]: Configure script fails with expr: syntax error
ID: 39835 Comment by: bill at bt-systems dot com Reported By: cheetah at tanabi dot org Status: No Feedback Bug Type: *Compile Issues Operating System: Solaris 10 PHP Version: 5.2.0 New Comment: I encountered this problem on Solaris 10 x86 as well. My path specified /usr/ucb before /usr/bin. Apparently the version of expr in /usr/ucb is not compatible with PHP's configure script. Simply removing /usr/ucb from my path fixed the problem. Previous Comments: [2007-08-29 19:38:02] jd at cpanel dot net the expr info page suggests the expr tests in configure should be quoted with a leading space to avoid being interpreted as flags and remain as portable as possible: diff -Nur php-5.2.3.orig/acinclude.m4 php-5.2.3/acinclude.m4 --- php-5.2.3.orig/acinclude.m4 2007-05-24 16:40:41.0 -0500 +++ php-5.2.3/acinclude.m4 2007-08-29 14:30:40.0 -0500 @@ -2504,20 +2504,20 @@ done echo '[$]0' \\ $1 - if test `expr -- [$]0 : '.*` = 0; then + if test `expr [$]0 : '.*` = 0; then CONFIGURE_COMMAND=$CONFIGURE_COMMAND '[$]0' else CONFIGURE_COMMAND=$CONFIGURE_COMMAND [$]0 fi for arg in $ac_configure_args; do - if test `expr -- $arg : '.*` = 0; then -if test `expr -- $arg : --.*` = 0; then + if test `expr $arg : '.*` = 0; then +if test `expr $arg : --.*` = 0; then break; fi echo '[$]arg' \\ $1 CONFIGURE_COMMAND=$CONFIGURE_COMMAND '[$]arg' else -if test `expr -- $arg : '--.*` = 0; then +if test `expr $arg : '--.*` = 0; then break; fi echo [$]arg \\ $1 [2007-08-29 19:11:51] jd at cpanel dot net Passing -- to mark the end of flags for expr doesn't work everywhere. # expr --version | head -1 expr (GNU coreutils) 5.2.1 # expr -- hello hello # expr --version | head -1 expr (GNU sh-utils) 2.0 # expr -- hello expr: syntax error [2007-06-12 09:49:56] aklx at ee dot cuhk dot edu dot hk I had similar problem with php5.2.3 and php4.4.7. I was building php for my horde package and the following was observed when running configure(Sun Sparc Solaris 2.9): # ./configure --prefix=/usr/local/php.5.23 --with-apxs=/usr/apache2/bin/apxs \ --with-gettext --with-dom \ --with-iconv --enable-mbstring=all --enable-mbregex \ --with-mysql=/usr/local/mysql creating cache ./config.cache checking for Cygwin environment... no checking for mingw32 environment... no checking for egrep... egrep checking for a sed that does not truncate output... /usr/local/bin/sed expr: syntax error ../configure: test: argument expected I used gnu sed when I had the problem when using the Solairs sed. [2007-03-13 15:23:11] v2 at petrov dot ks dot ua Have same error when try to compile php-4.4.6 # ./configure loading cache ./config.cache checking for egrep... grep -E checking for a sed that does not truncate output... /bin/sed expr: syntax error ./configure: test: =: unary operator expected ... OS Red Hat 7.3 # bash --version GNU bash, version 2.05a.0(1)-release (i686-pc-linux-gnu) Copyright 2001 Free Software Foundation, Inc. # expr --version expr (GNU sh-utils) 2.0.11 Written by Mike Parker. [2006-12-23 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open
#40217 [Com]: Installation problem and file upload using html post not working
ID: 40217 Comment by: bill dot stout at greenborder dot com Reported By: ratneshmaurya at gmail dot com Status: Assigned Bug Type: IIS related Operating System: Windows XP PHP Version: 5.2.0 Assigned To: jmertic New Comment: I'm experiencing the same problem. I've attempted to install RC3 and it does not want to upgrade 5.2.0. Uninstalling 5.2.0 from Control Panel - Add or Remove Programs returns an error: PHP 5.2.0 The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2343. Previous Comments: [2007-01-29 13:17:53] [EMAIL PROTECTED] Could you run it in verbose logging mode and e-mail the log file to [EMAIL PROTECTED] To run in verbose logging mode issue the below command from the command prompt ( from the same directory where the install exists ): msiexec /i php-5.2.1RC3-win32-installer.msi /l*v error.log [2007-01-24 13:17:13] ratneshmaurya at gmail dot com I tried the link. http://downloads.php.net/edink/php-5.2.1RC3-win32-installer.msi It gives error, I think similar to that Iwas getting earliear Error 1722. [2007-01-24 12:33:23] [EMAIL PROTECTED] Please try http://downloads.php.net/edink/php-5.2.1RC3-win32-installer.msi [2007-01-24 08:58:15] ratneshmaurya at gmail dot com Description: While installing (with the installer) in IIS4+CGI Mode (Windows XP, IIS6.0), I get an error message at the end of the installation (There is a problem with this Windows Installer Package please contact...) Every thing in my php scripts works fine except file upload using http post method. I also tried Bug #26185, solution and added through command C:\WINDOWS\system32 iisext.vbs /AddFile C:\Program Files\PHP\php-cgi.exe 1 PHP 1 PHP: Hypertext Processor But it didnt solved the problem. Reproduce code: --- form action = upload.php... input type = file / input type = sumbit../ /form Expected result: the file which i selected must get uploaded to the upload_temp_dir as specified in the file php.ini The same code works for me on a different machine where the php was successfully installed. Actual result: -- no file got uploaded. i tried files with different sizes as low as 1kb. and specified different upload directories for upload. Nothing worked on that machine. -- Edit this bug report at http://bugs.php.net/?id=40217edit=1
#38137 [NEW]: Apache 2.0.55-Openldap 2.3.24-php 5.1.4 causes apache to segfault
From: bill dot macallister at prideindustries dot com Operating system: Debian Sarge with 3.6.8 kernel PHP version: 5.1.4 PHP Bug Type: Reproducible crash Bug description: Apache 2.0.55-Openldap 2.3.24-php 5.1.4 causes apache to segfault Description: On a Debian Sarge system with a 2.6.8 kernel I am building Apache 2.0.55 with PHP 5.1.4 with LDAP support. The build seems to complete just fine, but the server will not start. When I do a 'apache/bin/apachectl configtest' I get a Syntax OK message just before I get the SEGFAULT message. When I remove the PHP module load directive from the httpd.conf file the SEGFAULT disappears. I get the same result if I build PHP 4.4.2. I have finally gotten the server to build by building against OpenLDAP 2.2.27. It looks like PHP is having some problem with OpenLDAP 2.3.x? Reproduce code: --- Here is the configuration line that works: #!/bin/sh ./configure \ --enable-gd-native-ttf \ --enable-mbregex \ --enable-mbstring \ --enable-ssl \ --enable-track-vars \ --with-apxs2=/usr/local/apache-2.0.55/bin/apxs \ --with-gdbm \ --with-imap \ --with-imap-ssl \ --with-kerberos \ --with-mysql=/usr/local/mysql \ --with-unixODBC=/usr/local/easysoft/unixODBC \ --with-pear-dir=/usr/local/lib/php \ --with-mcrypt \ --with-gd \ --with-gettext \ --with-iconv \ --with-openssl \ --with-ttf \ --with-xml \ --with-zlib \ --with-zlib-dir=/usr/lib \ --with-ldap=/usr/local/openldap-2.2.27 Here is the one that fails: #!/bin/sh ./configure \ --enable-gd-native-ttf \ --enable-mbregex \ --enable-mbstring \ --enable-ssl \ --enable-track-vars \ --with-apxs2=/usr/local/apache-2.0.55/bin/apxs \ --with-gdbm \ --with-imap \ --with-imap-ssl \ --with-kerberos \ --with-mysql=/usr/local/mysql \ --with-unixODBC=/usr/local/easysoft/unixODBC \ --with-pear-dir=/usr/local/lib/php \ --with-mcrypt \ --with-gd \ --with-gettext \ --with-iconv \ --with-openssl \ --with-ttf \ --with-xml \ --with-zlib \ --with-zlib-dir=/usr/lib \ --with-ldap=/usr/local/openldap-2.3.24 Expected result: apachectl configtest Syntax OK Actual result: -- apachectl configtest Syntax OK /usr/local/apache/bin/apachectl: line 100: 5039 Segmentation fault $HTTPD -t -- Edit bug report at http://bugs.php.net/?id=38137edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=38137r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=38137r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=38137r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=38137r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=38137r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=38137r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=38137r=needscript Try newer version:http://bugs.php.net/fix.php?id=38137r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=38137r=support Expected behavior:http://bugs.php.net/fix.php?id=38137r=notwrong Not enough info: http://bugs.php.net/fix.php?id=38137r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=38137r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=38137r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38137r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=38137r=dst IIS Stability:http://bugs.php.net/fix.php?id=38137r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=38137r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=38137r=float No Zend Extensions: http://bugs.php.net/fix.php?id=38137r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=38137r=mysqlcfg
#38137 [Fbk-Opn]: Apache 2.0.55-Openldap 2.3.24-php 5.1.4 causes apache to segfault
ID: 38137 User updated by: bill dot macallister at prideindustries dot com Reported By: bill dot macallister at prideindustries dot com -Status: Feedback +Status: Open Bug Type: Reproducible crash Operating System: Debian Sarge with 3.6.8 kernel PHP Version: 5.1.4 New Comment: Here is the back trace you requested: (gdb) bt #0 ldap_free_urllist (ludlist=0x185) at url.c:1464 #1 0x40d14b3b in ldap_parse_vlv_control () from /usr/lib/libldap_r.so.2 #2 0x40cfb15b in ?? () from /usr/lib/libldap_r.so.2 #3 0x40d26000 in ?? () from /usr/lib/libldap_r.so.2 #4 0x40d26734 in ?? () from /usr/lib/libldap_r.so.2 #5 0xbfffd9c8 in ?? () #6 0x40d21376 in _fini () from /usr/lib/libldap_r.so.2 #7 0x40d21376 in _fini () from /usr/lib/libldap_r.so.2 #8 0x4000c5e6 in _dl_init () from /lib/ld-linux.so.2 #9 0x4033c192 in exit () from /lib/tls/libc.so.6 #10 0x080b6793 in destroy_and_exit_process (process=0x185, process_exit_value=389) at main.c:211 #11 0x080b75bf in main (argc=2, argv=0xbfffdbd4) at main.c:545 H, /usr/lib/libldap_r.so. I built ldap and installed it in /usr/local/openldap-2.3.4. So, I am getting the wrong ldap so's? Not sure how to fix that. I think I will try building PHP without specifying the ldap location and let it picture whatever client library is in the standard location and see what happens. I would appreciate a pointer to tell me how to use my copy of the 2.3.4 openldap without replacing the system ldap client libraries. Previous Comments: [2006-07-19 06:47:59] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to Open. Thank you for helping us make PHP better. [2006-07-19 06:22:33] bill dot macallister at prideindustries dot com Description: On a Debian Sarge system with a 2.6.8 kernel I am building Apache 2.0.55 with PHP 5.1.4 with LDAP support. The build seems to complete just fine, but the server will not start. When I do a 'apache/bin/apachectl configtest' I get a Syntax OK message just before I get the SEGFAULT message. When I remove the PHP module load directive from the httpd.conf file the SEGFAULT disappears. I get the same result if I build PHP 4.4.2. I have finally gotten the server to build by building against OpenLDAP 2.2.27. It looks like PHP is having some problem with OpenLDAP 2.3.x? Reproduce code: --- Here is the configuration line that works: #!/bin/sh ./configure \ --enable-gd-native-ttf \ --enable-mbregex \ --enable-mbstring \ --enable-ssl \ --enable-track-vars \ --with-apxs2=/usr/local/apache-2.0.55/bin/apxs \ --with-gdbm \ --with-imap \ --with-imap-ssl \ --with-kerberos \ --with-mysql=/usr/local/mysql \ --with-unixODBC=/usr/local/easysoft/unixODBC \ --with-pear-dir=/usr/local/lib/php \ --with-mcrypt \ --with-gd \ --with-gettext \ --with-iconv \ --with-openssl \ --with-ttf \ --with-xml \ --with-zlib \ --with-zlib-dir=/usr/lib \ --with-ldap=/usr/local/openldap-2.2.27 Here is the one that fails: #!/bin/sh ./configure \ --enable-gd-native-ttf \ --enable-mbregex \ --enable-mbstring \ --enable-ssl \ --enable-track-vars \ --with-apxs2=/usr/local/apache-2.0.55/bin/apxs \ --with-gdbm \ --with-imap \ --with-imap-ssl \ --with-kerberos \ --with-mysql=/usr/local/mysql \ --with-unixODBC=/usr/local/easysoft/unixODBC \ --with-pear-dir=/usr/local/lib/php \ --with-mcrypt \ --with-gd \ --with-gettext \ --with-iconv \ --with-openssl \ --with-ttf \ --with-xml \ --with-zlib \ --with-zlib-dir=/usr/lib \ --with-ldap=/usr/local/openldap-2.3.24 Expected result: apachectl configtest Syntax OK Actual result: -- apachectl configtest Syntax OK /usr/local/apache/bin/apachectl: line 100: 5039 Segmentation fault $HTTPD -t -- Edit this bug report at http://bugs.php.net/?id=38137edit=1
#35337 [NoF-Csd]: prepare update into longtext column broken
ID: 35337
User updated by: bill dot finn at sellingsource dot com
Reported By: bill dot finn at sellingsource dot com
-Status: No Feedback
+Status: Closed
Bug Type: MySQLi related
Operating System: Gentoo 2.6.9
PHP Version: 6CVS-2005-11-19 (snap)
New Comment:
tested with 2005-11-29, works.
Previous Comments:
[2005-11-30 01:00:10] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.
[2005-11-22 22:31:31] [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
[2005-11-22 19:43:44] bill dot finn at sellingsource dot com
Description:
Performing an update into a non-null longtext column using prepare
syntax. Example code works in php 5.0.x. Upgraded to 5.1.x and it
started entering variations of empty strings, 0, or -00-00
depending on how much data I was trying to enter. In a test that
allows null values, it enters null.
(mysql 5.0.13 mysql 5.0.15)
Reproduce code:
---
CREATE TABLE test (col1 longtext not null);
?php
$data = whatever, some string;
$mysqli = new mysqli( HOST, USER, PASS, DB, PORT );
$query = INSERT INTO test SET col1 = ?;
$prepared = $mysqli-prepare( $query );
$prepared-bind_param('s', $data );
$prepared-execute();
$prepared-close();
?
Expected result:
contents of $data inserted into col1 of table.
Actual result:
--
SELECT col1 FROM test
shows one of three things:
-00-00
0
empty string
--
Edit this bug report at http://bugs.php.net/?id=35337edit=1
#35509 [NEW]: string constant as array key has different behavior inside object
From: bill dot finn at sellingsource dot com
Operating system: Gentoo 2.6.9
PHP version: 6CVS-2005-12-01 (CVS)
PHP Bug Type: Arrays related
Bug description: string constant as array key has different behavior inside
object
Description:
When using a constant of '01' as an array key inside of a class, it
converts the key to the integer 1. Outside of a class, it leaves it as
'01'.
Reproduce code:
---
class mytest
{
const classConstant = '01';
private $classArray = array( mytest::classConstant = 'value' );
public function __construct()
{
print_r($this-classArray);
}
}
$classtest = new mytest();
define( normalConstant, '01' );
$normalArray = array( normalConstant = 'value' );
print_r($normalArray);
Expected result:
Array
(
[01] = value
)
Array
(
[01] = value
)
Actual result:
--
Array
(
[1] = value
)
Array
(
[01] = value
)
--
Edit bug report at http://bugs.php.net/?id=35509edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=35509r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=35509r=trysnapshot51
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=35509r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=35509r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=35509r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=35509r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=35509r=needscript
Try newer version:http://bugs.php.net/fix.php?id=35509r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=35509r=support
Expected behavior:http://bugs.php.net/fix.php?id=35509r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=35509r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=35509r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=35509r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35509r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=35509r=dst
IIS Stability:http://bugs.php.net/fix.php?id=35509r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=35509r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=35509r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=35509r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=35509r=mysqlcfg
#35072 [Fbk-Opn]: ftps:// fopen wrapper: FTP server reports 501 wrong number of parameters
ID: 35072 User updated by: bill dot finn at sellingsource dot com Reported By: bill dot finn at sellingsource dot com -Status: Feedback +Status: Open Bug Type: Filesystem function related Operating System: * PHP Version: 5CVS-2005-11-03 (snap) New Comment: It now retrieves the file, but is still generating an error: PHP Warning: file(): SSL: fatal protocol error in /home/wfinn/test/ftps.php on line 21 Warning: file(): SSL: fatal protocol error in /home/wfinn/test/ftps.php on line 21 Previous Comments: [2005-11-28 15:03:35] [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 [2005-11-23 01:18:21] bill dot finn at sellingsource dot com Done. PHP Warning: file(): SSL: fatal protocol error in /home/wfinn/test/ftps.php on line 21 Warning: file(): SSL: fatal protocol error in /home/wfinn/test/ftps.php on line 21 [2005-11-23 00:41:17] [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 [2005-11-02 23:20:02] bill dot finn at sellingsource dot com Done. PHP Warning: file(ftps://...myinfo...): failed to open stream: FTP server reports 501 wrong number of parameters in /home/wfinn/test/ftps.php on line 21 Warning: file(ftps://...myinfo...): failed to open stream: FTP server reports 501 wrong number of parameters in /home/wfinn/test/ftps.php on line 21 [2005-11-02 22:30:30] [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 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/35072 -- Edit this bug report at http://bugs.php.net/?id=35072edit=1
#35337 [NEW]: prepare update into longtext column broken
From: bill dot finn at sellingsource dot com
Operating system: Gentoo 2.6.9
PHP version: 6CVS-2005-11-19 (snap)
PHP Bug Type: MySQLi related
Bug description: prepare update into longtext column broken
Description:
Performing an update into a non-null longtext column using prepare syntax.
Example code works in php 5.0.x. Upgraded to 5.1.x and it started
entering variations of empty strings, 0, or -00-00 depending on how
much data I was trying to enter. In a test that allows null values, it
enters null.
(mysql 5.0.13 mysql 5.0.15)
Reproduce code:
---
CREATE TABLE test (col1 longtext not null);
?php
$data = whatever, some string;
$mysqli = new mysqli( HOST, USER, PASS, DB, PORT );
$query = INSERT INTO test SET col1 = ?;
$prepared = $mysqli-prepare( $query );
$prepared-bind_param('s', $data );
$prepared-execute();
$prepared-close();
?
Expected result:
contents of $data inserted into col1 of table.
Actual result:
--
SELECT col1 FROM test
shows one of three things:
-00-00
0
empty string
--
Edit bug report at http://bugs.php.net/?id=35337edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=35337r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=35337r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=35337r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=35337r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=35337r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=35337r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=35337r=needscript
Try newer version: http://bugs.php.net/fix.php?id=35337r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=35337r=support
Expected behavior: http://bugs.php.net/fix.php?id=35337r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=35337r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=35337r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=35337r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35337r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=35337r=dst
IIS Stability: http://bugs.php.net/fix.php?id=35337r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=35337r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=35337r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=35337r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=35337r=mysqlcfg
#35072 [Fbk-Opn]: ftps:// fopen wrapper: FTP server reports 501 wrong number of parameters
ID: 35072
User updated by: bill dot finn at sellingsource dot com
Reported By: bill dot finn at sellingsource dot com
-Status: Feedback
+Status: Open
Bug Type: Filesystem function related
Operating System: *
PHP Version: 5CVS-2005-11-03 (snap)
New Comment:
Done.
PHP Warning: file(): SSL: fatal protocol error in
/home/wfinn/test/ftps.php on line 21
Warning: file(): SSL: fatal protocol error in /home/wfinn/test/ftps.php
on line 21
Previous Comments:
[2005-11-23 00:41:17] [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
[2005-11-02 23:20:02] bill dot finn at sellingsource dot com
Done.
PHP Warning: file(ftps://...myinfo...): failed to open stream: FTP
server reports 501 wrong number of parameters
in /home/wfinn/test/ftps.php on line 21
Warning: file(ftps://...myinfo...): failed to open stream: FTP server
reports 501 wrong number of parameters
in /home/wfinn/test/ftps.php on line 21
[2005-11-02 22:30:30] [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
[2005-11-02 22:10:52] bill dot finn at sellingsource dot com
Description:
using ftps in some filesystem functions produces ssl error and fails.
Same effect if only using file() without file_exists before it.
Reproduce code:
---
echo
file_exists(ftps://{$user}:[EMAIL PROTECTED]:{$port}/{$path}{$file})
$contents =
file(ftps://{$user}:[EMAIL PROTECTED]:{$port}/{$path}{$file})
Expected result:
$contents should get the contents of the file I'm requesting from the
server.
Actual result:
--
PHP Warning: file(): SSL/TLS already set-up for this stream in
/home/wfinn/test/ftps.php on line 21
Warning: file(): SSL/TLS already set-up for this stream in
/home/wfinn/test/ftps.php on line 21
PHP Warning: file(ftps://...myinfo...): failed to open stream: Unable
to activate SSL mode
FTP server reports 150 Opening BINARY data connection for
/s-fastcash/343923324-20051019.ddl (1084 bytes)
in /home/wfinn/test/ftps.php on line 21
Warning: file(ftps://...myinfo...): failed to open stream: Unable to
activate SSL mode
FTP server reports 150 Opening BINARY data connection for
/s-fastcash/343923324-20051019.ddl (1084 bytes)
in /home/wfinn/test/ftps.php on line 21
--
Edit this bug report at http://bugs.php.net/?id=35072edit=1
#35072 [NEW]: ssl init error
From: bill dot finn at sellingsource dot com
Operating system: Gentoo 2.6.9
PHP version: 5.0.5
PHP Bug Type: Network related
Bug description: ssl init error
Description:
using ftps in some filesystem functions produces ssl error and fails.
Same effect if only using file() without file_exists before it.
Reproduce code:
---
echo file_exists(ftps://{$user}:[EMAIL PROTECTED]:{$port}/{$path}{$file})
$contents = file(ftps://{$user}:[EMAIL PROTECTED]:{$port}/{$path}{$file})
Expected result:
$contents should get the contents of the file I'm requesting from the
server.
Actual result:
--
PHP Warning: file(): SSL/TLS already set-up for this stream in
/home/wfinn/test/ftps.php on line 21
Warning: file(): SSL/TLS already set-up for this stream in
/home/wfinn/test/ftps.php on line 21
PHP Warning: file(ftps://...myinfo...): failed to open stream: Unable to
activate SSL mode
FTP server reports 150 Opening BINARY data connection for
/s-fastcash/343923324-20051019.ddl (1084 bytes)
in /home/wfinn/test/ftps.php on line 21
Warning: file(ftps://...myinfo...): failed to open stream: Unable to
activate SSL mode
FTP server reports 150 Opening BINARY data connection for
/s-fastcash/343923324-20051019.ddl (1084 bytes)
in /home/wfinn/test/ftps.php on line 21
--
Edit bug report at http://bugs.php.net/?id=35072edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=35072r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=35072r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=35072r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=35072r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=35072r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=35072r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=35072r=needscript
Try newer version: http://bugs.php.net/fix.php?id=35072r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=35072r=support
Expected behavior: http://bugs.php.net/fix.php?id=35072r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=35072r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=35072r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=35072r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35072r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=35072r=dst
IIS Stability: http://bugs.php.net/fix.php?id=35072r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=35072r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=35072r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=35072r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=35072r=mysqlcfg
#35072 [Fbk-Opn]: ssl init error
ID: 35072
User updated by: bill dot finn at sellingsource dot com
Reported By: bill dot finn at sellingsource dot com
-Status: Feedback
+Status: Open
Bug Type: Network related
Operating System: Gentoo 2.6.9
PHP Version: 5.0.5
New Comment:
Done.
PHP Warning: file(ftps://...myinfo...): failed to open stream: FTP
server reports 501 wrong number of parameters
in /home/wfinn/test/ftps.php on line 21
Warning: file(ftps://...myinfo...): failed to open stream: FTP server
reports 501 wrong number of parameters
in /home/wfinn/test/ftps.php on line 21
Previous Comments:
[2005-11-02 22:30:30] [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
[2005-11-02 22:10:52] bill dot finn at sellingsource dot com
Description:
using ftps in some filesystem functions produces ssl error and fails.
Same effect if only using file() without file_exists before it.
Reproduce code:
---
echo
file_exists(ftps://{$user}:[EMAIL PROTECTED]:{$port}/{$path}{$file})
$contents =
file(ftps://{$user}:[EMAIL PROTECTED]:{$port}/{$path}{$file})
Expected result:
$contents should get the contents of the file I'm requesting from the
server.
Actual result:
--
PHP Warning: file(): SSL/TLS already set-up for this stream in
/home/wfinn/test/ftps.php on line 21
Warning: file(): SSL/TLS already set-up for this stream in
/home/wfinn/test/ftps.php on line 21
PHP Warning: file(ftps://...myinfo...): failed to open stream: Unable
to activate SSL mode
FTP server reports 150 Opening BINARY data connection for
/s-fastcash/343923324-20051019.ddl (1084 bytes)
in /home/wfinn/test/ftps.php on line 21
Warning: file(ftps://...myinfo...): failed to open stream: Unable to
activate SSL mode
FTP server reports 150 Opening BINARY data connection for
/s-fastcash/343923324-20051019.ddl (1084 bytes)
in /home/wfinn/test/ftps.php on line 21
--
Edit this bug report at http://bugs.php.net/?id=35072edit=1
#28647 [NEW]: session code does not show same behaviour
From: bill dot stevens at hotmail dot com
Operating system: WindowsXP/Debian
PHP version: 4.3.7
PHP Bug Type: Session related
Bug description: session code does not show same behaviour
Description:
using sessions on windows xp/php 4.3.7 and register_globals off does work
fine (code below).
same script on debian-woody/php 4.3.1 and register_globals off does not
read the session data. only register_globals on solves this (same code).
session-related config on both machines is the same or changes had no
effect.
any ideas on config/scripting/stuff welcome :)
Reproduce code:
---
if( $this-useSessions )
{
session_start();
// check, whether register globals is enabled
if( ini_get( register_globals ) )
{
session_register( $this-sessionVar );
if( !isset( $GLOBALS[$this-sessionVar] ) )
$GLOBALS[$this-sessionVar] = array();
$this-sessionData = $GLOBALS[$this-sessionVar];
}
// register globals is off, session_register is useless :-(
else
{
if( isset( $_SESSION ) )
{
if( !isset( $_SESSION[$this-sessionVar] ) )
$_SESSION[$this-sessionVar]= array();
$this-sessionData =
$_SESSION[$this-sessionVar];
}
else
{
if( !isset( $GLOBALS[HTTP_SESSION_VARS][$this-sessionVar] )
)
$GLOBALS[HTTP_SESSION_VARS][$this-sessionVar]
= array();
$this-sessionData =
$GLOBALS[HTTP_SESSION_VARS][$this-sessionVar];
}
}
}
Expected result:
register session vars. works on windows, does not on debian.
Actual result:
--
no session on debian.
--
Edit bug report at http://bugs.php.net/?id=28647edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28647r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28647r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=28647r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=28647r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=28647r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=28647r=needscript
Try newer version: http://bugs.php.net/fix.php?id=28647r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=28647r=support
Expected behavior: http://bugs.php.net/fix.php?id=28647r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=28647r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=28647r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=28647r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28647r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=28647r=dst
IIS Stability: http://bugs.php.net/fix.php?id=28647r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=28647r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=28647r=float
#25575 [NoF-Opn]: stream_set_blocking with STDIN doesnt block
ID: 25575 User updated by: bill at baghead dot co dot uk Reported By: bill at baghead dot co dot uk -Status: No Feedback +Status: Open Bug Type: Sockets related Operating System: Redhat 9 PHP Version: 4CVS-2003-09-17 (stable) Assigned To: wez New Comment: Using the latest snapshop, it still shows the same problem.. Cheers - Bill. Previous Comments: [2003-12-04 02:23:57] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to Open. Thank you. [2003-11-28 17:46:54] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip Just committed a probable fix; please try the next snapshot. [2003-09-24 21:41:12] robert at interjinn dot com I've been directed here from bug #25616 with the indication that this is the same bug. I read this bug before I posted bug #25616 and the issues seems different. This one describes an issue with blocking mode, my bug describes an issue whith the script exitting successfully while in an infinite loop, which is contrary to the expected functionality of a while( 1 ) loop. I'm not sure why I was pointed here. Albeit my bug seemed to come into existence with the use of stream_set_blocking( $stdin, FALSE ) [2003-09-18 04:15:44] bill at baghead dot co dot uk The case is with the original code stated, the code loops, and does not block on the fread - ie, it keeps returning instantly (even with nothing), which seems to me to be non blocking eventhough I'd told it to block.. If I remove the stream_set_blocking(STDIN,TRUE); altogether, fread appears to block - but instead of returning after receiving a block of data, it blocks until the buffer is filled up (in this case being 128 bytes) - *then* it returns.. [2003-09-17 18:37:38] [EMAIL PROTECTED] What you have just described is blocking IO, and that is precisely what I'd expect to happen when reading from STDIN. Now, when reading from a socket, you would expect the call to return at the end of a packet, but php doesn't yet have any idea that stdin is a socket, and that sounds like the cause of your problems. Can you confirm that this is the case, as your more recent comments don't seem to match up to your original report? 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/25575 -- Edit this bug report at http://bugs.php.net/?id=25575edit=1
#25575 [Fbk-Opn]: stream_set_blocking with STDIN doesnt block
ID: 25575 User updated by: [EMAIL PROTECTED] Reported By: bill at baghead dot co dot uk -Status: Feedback +Status: Open Bug Type: Sockets related Operating System: Redhat 9 PHP Version: 4CVS-2003-09-17 (stable) New Comment: The case is with the original code stated, the code loops, and does not block on the fread - ie, it keeps returning instantly (even with nothing), which seems to me to be non blocking eventhough I'd told it to block.. If I remove the stream_set_blocking(STDIN,TRUE); altogether, fread appears to block - but instead of returning after receiving a block of data, it blocks until the buffer is filled up (in this case being 128 bytes) - *then* it returns.. Previous Comments: [2003-09-17 18:37:38] [EMAIL PROTECTED] What you have just described is blocking IO, and that is precisely what I'd expect to happen when reading from STDIN. Now, when reading from a socket, you would expect the call to return at the end of a packet, but php doesn't yet have any idea that stdin is a socket, and that sounds like the cause of your problems. Can you confirm that this is the case, as your more recent comments don't seem to match up to your original report? [2003-09-17 18:35:41] [EMAIL PROTECTED] Comment sent from user by mail; please don't mail people directly; keep all info related to the bug in the database unless requested to do otherwise. -- What exactly was the workaround? I did try removing the statement, and it kept reading the STDIN with the fread until the amount, in this case being 128 bytes is filled, rather than taking it to the end of the packet... [2003-09-17 13:14:14] [EMAIL PROTECTED] Will you please try the workaround I suggested? I'm not saying it isn't a bug, I'm just suggesting something that might help get your script working in the time it takes for this bug to get fixed. [2003-09-17 12:49:37] bill at baghead dot co dot uk Surely it wouldnt matter if xinetd opened the socket blocking or non-blocking, as the script opens STDIN which needs to be blocking as php is talking to stdin, *not* the socket directly.. [2003-09-17 11:57:45] [EMAIL PROTECTED] The default mode for streams is blocking mode, so you shouldn't need to call this function at all. Is xinetd setting it to non-blocking before the script starts? It does sound like you have a bug there, I just thought you might like to try a workaround until it gets fixed. 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/25575 -- Edit this bug report at http://bugs.php.net/?id=25575edit=1
#25575 [NEW]: stream_set_blocking with STDIN doesnt block
From: bill at baghead dot co dot uk
Operating system: Redhat 9
PHP version: 4CVS-2003-09-17 (stable)
PHP Bug Type: Sockets related
Bug description: stream_set_blocking with STDIN doesnt block
Description:
Hi,
When using xinetd with a php script - then using php to read from the
socket with STDIN / STDOUT, as thats how xinetd translates sockets. I
find that setting blocking on the socket like the code below, I find the
while loops and uses all my cpu time - whereas the fread should block, and
wait till it gets something..
If I uncomment the sleep line - it drops down the cpu usage, but I would
rather have the blocking working.
The process function processes the data, and is irrelevant here.
PHP Was compiled with:
./configure --enable-cli --with-sockets --with-openssl --with-curl
--enable-pcntl --enable-sigchild --with-mysql --enable-sockets
Made with:
C_INCLUDE_PATH=/usr/kerberos/include make
Version:
PHP 4.3.4-dev (cli) (built: Sep 17 2003 16:04:24)
Reproduce code:
---
?php
set_time_limit (0);
ob_implicit_flush ();
stream_set_blocking(STDIN,TRUE);
$read = array(STDIN);
while (true) {
$buf = fread(STDIN,128);
//if ($buf == ) { sleep(1); }
process($buf);
unset($buf);
}
?
Expected result:
For the fread to block and wait for input, rather than return immediately.
Actual result:
--
The fread returns (even with no data), and loops.
--
Edit bug report at http://bugs.php.net/?id=25575edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25575r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25575r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=25575r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=25575r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=25575r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=25575r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=25575r=support
Expected behavior: http://bugs.php.net/fix.php?id=25575r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=25575r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=25575r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=25575r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25575r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=25575r=dst
IIS Stability: http://bugs.php.net/fix.php?id=25575r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=25575r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=25575r=float
#25575 [Fbk-Opn]: stream_set_blocking with STDIN doesnt block
ID: 25575
User updated by: [EMAIL PROTECTED]
Reported By: bill at baghead dot co dot uk
-Status: Feedback
+Status: Open
Bug Type: Sockets related
Operating System: Redhat 9
PHP Version: 4CVS-2003-09-17 (stable)
New Comment:
Surely it wouldnt matter if xinetd opened the socket blocking or
non-blocking, as the script opens STDIN which needs to be blocking
as php is talking to stdin, *not* the socket directly..
Previous Comments:
[2003-09-17 11:57:45] [EMAIL PROTECTED]
The default mode for streams is blocking mode, so you shouldn't need to
call this function at all.
Is xinetd setting it to non-blocking before the script starts?
It does sound like you have a bug there, I just thought you might like
to try a workaround until it gets fixed.
[2003-09-17 11:13:43] bill at baghead dot co dot uk
Description:
Hi,
When using xinetd with a php script - then using php to read from the
socket with STDIN / STDOUT, as thats how xinetd translates sockets. I
find that setting blocking on the socket like the code below, I find
the while loops and uses all my cpu time - whereas the fread should
block, and wait till it gets something..
If I uncomment the sleep line - it drops down the cpu usage, but I
would rather have the blocking working.
The process function processes the data, and is irrelevant here.
PHP Was compiled with:
./configure --enable-cli --with-sockets --with-openssl --with-curl
--enable-pcntl --enable-sigchild --with-mysql --enable-sockets
Made with:
C_INCLUDE_PATH=/usr/kerberos/include make
Version:
PHP 4.3.4-dev (cli) (built: Sep 17 2003 16:04:24)
Reproduce code:
---
?php
set_time_limit (0);
ob_implicit_flush ();
stream_set_blocking(STDIN,TRUE);
$read = array(STDIN);
while (true) {
$buf = fread(STDIN,128);
//if ($buf == ) { sleep(1); }
process($buf);
unset($buf);
}
?
Expected result:
For the fread to block and wait for input, rather than return
immediately.
Actual result:
--
The fread returns (even with no data), and loops.
--
Edit this bug report at http://bugs.php.net/?id=25575edit=1
#11153 [Com]: imap_check() returns wrong date
ID: 11153
Comment by: bill dot mccoy at pictureiq dot com
Reported By: tp at dexel dot dk
Status: No Feedback
Bug Type: IMAP related
Operating System: linux 2.2.17
PHP Version: 4.0.4pl1
New Comment:
I'm not a PHP.net developer so I can't change the bug status but it
repros on 4.3.1 on multiple platforms (Windows XP and Linux) and
against multiple IMAP servers.
Previous Comments:
[2002-02-17 00:00:01] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.
[2002-02-13 12:16:04] php at firstnetimpressions dot com
FYI ... This issue remains in PHP version 4.1.1
PHP_FUNCTION(imap_check) is calling rfc822_date(date) in php_imap.c
[2002-01-16 07:23:25] [EMAIL PROTECTED]
Does this error still occur with the lastest (CVS) version?
[2001-05-28 07:17:42] tp at dexel dot dk
The Date field of the object returned by imap_check should contain the
date of the last change of the selected mailbox, but it always return
the date and time on which the function is called, at least on my
system.
I use c-client version 4.1 or more precisely
imap-2001.BETA.SNAP-0104262058
I use courier-imap-1.3.6 imap server
Script to reproduce error:
$servercon = imap_open({mail.domain.com:143}INBOX, someone,
secret);
$mailboxStatus = imap_mailboxmsginfo($servercon);
echo $mailboxStatus-Date;
imap_close($servercon);
I have tried the above script on an older server with php 4.0.2, and
older c-client library. I have also tried connecting to some older
sendmail based mailserver with the same results.
--
Edit this bug report at http://bugs.php.net/?id=11153edit=1
#20816 [NEW]: imagecopyresampled turn white into yellow
From: [EMAIL PROTECTED] Operating system: WinXP PHP version: 4CVS-2002-12-04 (dev) PHP Bug Type: GD related Bug description: imagecopyresampled turn white into yellow The function imagecopyresampled() takes a white area (255,255,255) and turns it yellow (255,255,2). This does not happen with imagecopyresize(). I think the problem is in the GD library, because the problem disappears when I use the php_gd2.dll from PHP4.2.3 instead of the one that came bundled with 4.4.0-dev. What phpinfo() says: 4.4.0-dev (both broken and working cases) GD 2.0 (bundled) BROKEN case GD 2.0 or higher WORKING case -- Edit bug report at http://bugs.php.net/?id=20816edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20816r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20816r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20816r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20816r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20816r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20816r=support Expected behavior: http://bugs.php.net/fix.php?id=20816r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20816r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20816r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20816r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20816r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20816r=dst IIS Stability: http://bugs.php.net/fix.php?id=20816r=isapi
#20753 [Fbk-Bgs]: php.ini not read
ID: 20753 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Bogus Bug Type: PHP options/info functions Operating System: WinXP PHP Version: 4.2.3 New Comment: This *is* bug (for MS), but also a support issue (for PHP). Turns out that WinXP refuses to display the final .ini extension, even in the properties display, the file-rename box, or the details list; my file had actually been named php.ini.ini, and all I could ever see at all in any GUI was php.ini (except when I finally used the command line prompt). Sorry for taking your time, but this is an extremely subtle problem: perhaps the documentation could mention that the renaming and name-checking must happen in the command prompt (DOS), because otherwise there will be no error that the file wasn't found. Take care! Previous Comments: [2002-12-01 23:12:43] [EMAIL PROTECTED] OK, finally got it working: here's the top of phpinfo(): PHP Version 4.4.0-dev System Windows NT localhost 5.1 build 2600 Build Date Dec 2 2002 04:12:18 Server API Apache Virtual Directory Support enabled Configuration File (php.ini) Path C:\WINDOWS PHP API 20020918 Right below, it shows: Directive Local Value Master Value allow_call_time_pass_reference On On allow_url_fopen On On The file c:\windows\php.ini still has these entries: allow_call_time_pass_reference = Off allow_url_fopen = Off So it looks like even the CVS snapshot is ignoring the php.ini file it expects to see. Glad it doesn't want c:\winnt any more; that's an improvement. But the bug (or support issue) remains... [2002-12-01 22:07:30] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-12-01 21:55:37] [EMAIL PROTECTED] I assume you mean what phpinfo() prints out in the table at the top (I've clipped it here): System Windows NT 5.1 build 2600 Build Date Sep 6 2002 10:38:51 Server API Apache Virtual Directory Support enabled Configuration File (php.ini) Path c:\winnt Debug Build no Thread Safety enabled I'd be happy to try changing c:\winnt to some other directory, but I have no idea how to, or where that is configured. [2002-12-01 19:49:43] [EMAIL PROTECTED] This is most likely another support question, but let's try help you anyway: What is said by phpinfo() for where it's trying to read php.ini from? [2002-12-01 18:53:36] [EMAIL PROTECTED] This is nearly identical to bug #20540, except I've got today's PHP version (and I'm someone else!). I've got php on apache working, phpinfo() says the configuration file path is c:\winnt (although everything else on this system is in c:\windows, and I had to create c:\winnt just to try and satisfy php). But the php.ini in c:\winnt still isn't being read, as judged by a couple changes (allow_call_time_pass_referece and url_fopen which I've set to non-default values). Yes, I'm restarting Apache; yes, I'm force-refreshing my browser; yes, I've verified there are no other php.ini files on the machine. I've even tried inserting syntax errors into php.ini, and moving it to the system32 directory or the c:\windows directory... no luck. I can't make that file have any effect at all. I've built and installed php a zillion times on Linux, and never had this problem. And I *hate* Windows. But I have to make this work to be able to use the gd extensions and image functions, and I'm pretty sure this bug is NOT bogus, since two of us are independently reporting the same thing in the same week. Any suggestions? -- Edit this bug report at http://bugs.php.net/?id=20753edit=1
#20753 [NEW]: php.ini not read
From: [EMAIL PROTECTED] Operating system: WinXP PHP version: 4.2.3 PHP Bug Type: PHP options/info functions Bug description: php.ini not read This is nearly identical to bug #20540, except I've got today's PHP version (and I'm someone else!). I've got php on apache working, phpinfo() says the configuration file path is c:\winnt (although everything else on this system is in c:\windows, and I had to create c:\winnt just to try and satisfy php). But the php.ini in c:\winnt still isn't being read, as judged by a couple changes (allow_call_time_pass_referece and url_fopen which I've set to non-default values). Yes, I'm restarting Apache; yes, I'm force-refreshing my browser; yes, I've verified there are no other php.ini files on the machine. I've even tried inserting syntax errors into php.ini, and moving it to the system32 directory or the c:\windows directory... no luck. I can't make that file have any effect at all. I've built and installed php a zillion times on Linux, and never had this problem. And I *hate* Windows. But I have to make this work to be able to use the gd extensions and image functions, and I'm pretty sure this bug is NOT bogus, since two of us are independently reporting the same thing in the same week. Any suggestions? -- Edit bug report at http://bugs.php.net/?id=20753edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20753r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20753r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20753r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20753r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20753r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20753r=support Expected behavior: http://bugs.php.net/fix.php?id=20753r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20753r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20753r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20753r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20753r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20753r=dst IIS Stability: http://bugs.php.net/fix.php?id=20753r=isapi
#20753 [Com]: php.ini not read
ID: 20753 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: PHP options/info functions Operating System: WinXP PHP Version: 4.2.3 New Comment: I assume you mean what phpinfo() prints out in the table at the top (I've clipped it here): System Windows NT 5.1 build 2600 Build Date Sep 6 2002 10:38:51 Server API Apache Virtual Directory Support enabled Configuration File (php.ini) Path c:\winnt Debug Build no Thread Safety enabled I'd be happy to try changing c:\winnt to some other directory, but I have no idea how to, or where that is configured. Previous Comments: [2002-12-01 19:49:43] [EMAIL PROTECTED] This is most likely another support question, but let's try help you anyway: What is said by phpinfo() for where it's trying to read php.ini from? [2002-12-01 18:53:36] [EMAIL PROTECTED] This is nearly identical to bug #20540, except I've got today's PHP version (and I'm someone else!). I've got php on apache working, phpinfo() says the configuration file path is c:\winnt (although everything else on this system is in c:\windows, and I had to create c:\winnt just to try and satisfy php). But the php.ini in c:\winnt still isn't being read, as judged by a couple changes (allow_call_time_pass_referece and url_fopen which I've set to non-default values). Yes, I'm restarting Apache; yes, I'm force-refreshing my browser; yes, I've verified there are no other php.ini files on the machine. I've even tried inserting syntax errors into php.ini, and moving it to the system32 directory or the c:\windows directory... no luck. I can't make that file have any effect at all. I've built and installed php a zillion times on Linux, and never had this problem. And I *hate* Windows. But I have to make this work to be able to use the gd extensions and image functions, and I'm pretty sure this bug is NOT bogus, since two of us are independently reporting the same thing in the same week. Any suggestions? -- Edit this bug report at http://bugs.php.net/?id=20753edit=1
#20753 [Com]: php.ini not read
ID: 20753 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: PHP options/info functions Operating System: WinXP PHP Version: 4.2.3 New Comment: OK, finally got it working: here's the top of phpinfo(): PHP Version 4.4.0-dev System Windows NT localhost 5.1 build 2600 Build Date Dec 2 2002 04:12:18 Server API Apache Virtual Directory Support enabled Configuration File (php.ini) Path C:\WINDOWS PHP API 20020918 Right below, it shows: Directive Local Value Master Value allow_call_time_pass_reference On On allow_url_fopen On On The file c:\windows\php.ini still has these entries: allow_call_time_pass_reference = Off allow_url_fopen = Off So it looks like even the CVS snapshot is ignoring the php.ini file it expects to see. Glad it doesn't want c:\winnt any more; that's an improvement. But the bug (or support issue) remains... Previous Comments: [2002-12-01 22:07:30] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-12-01 21:55:37] [EMAIL PROTECTED] I assume you mean what phpinfo() prints out in the table at the top (I've clipped it here): System Windows NT 5.1 build 2600 Build Date Sep 6 2002 10:38:51 Server API Apache Virtual Directory Support enabled Configuration File (php.ini) Path c:\winnt Debug Build no Thread Safety enabled I'd be happy to try changing c:\winnt to some other directory, but I have no idea how to, or where that is configured. [2002-12-01 19:49:43] [EMAIL PROTECTED] This is most likely another support question, but let's try help you anyway: What is said by phpinfo() for where it's trying to read php.ini from? [2002-12-01 18:53:36] [EMAIL PROTECTED] This is nearly identical to bug #20540, except I've got today's PHP version (and I'm someone else!). I've got php on apache working, phpinfo() says the configuration file path is c:\winnt (although everything else on this system is in c:\windows, and I had to create c:\winnt just to try and satisfy php). But the php.ini in c:\winnt still isn't being read, as judged by a couple changes (allow_call_time_pass_referece and url_fopen which I've set to non-default values). Yes, I'm restarting Apache; yes, I'm force-refreshing my browser; yes, I've verified there are no other php.ini files on the machine. I've even tried inserting syntax errors into php.ini, and moving it to the system32 directory or the c:\windows directory... no luck. I can't make that file have any effect at all. I've built and installed php a zillion times on Linux, and never had this problem. And I *hate* Windows. But I have to make this work to be able to use the gd extensions and image functions, and I'm pretty sure this bug is NOT bogus, since two of us are independently reporting the same thing in the same week. Any suggestions? -- Edit this bug report at http://bugs.php.net/?id=20753edit=1
#19621 [NEW]: Math needs a sign() function
From: [EMAIL PROTECTED] Operating system: Mandrake linux PHP version: 4.2.0 PHP Bug Type: Feature/Change Request Bug description: Math needs a sign() function The wonderful math-function list is missing a very important and simple function: sign(). The is the comlpementof abs(), and together with abs() allows you to separate the magnitude and sign of a number, e.g. for graphing purposes (it's hard to graph a negative number of pixels, and displaying money as $-99 looks dumb). It's a one-line function, so I've already written my own, but it really ought to be built-in. Thanks! -- Edit bug report at http://bugs.php.net/?id=19621edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=19621r=trysnapshot Fixed in CVS:http://bugs.php.net/fix.php?id=19621r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=19621r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=19621r=needtrace Try newer version: http://bugs.php.net/fix.php?id=19621r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=19621r=support Expected behavior: http://bugs.php.net/fix.php?id=19621r=notwrong Not enough info: http://bugs.php.net/fix.php?id=19621r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=19621r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=19621r=globals
Bug #16663 Updated: Different syntax for embedding HTML in PHP
ID: 16663
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: Feature/Change Request
Operating System: Linux
PHP Version: 4.2.0
New Comment:
There is nothing wrong with your alternative except that I can't find
info about the contstruct
echo HTML
some more html
HTML
in the online documentation. Should I add this to the notes regarding
Example 5-2. Advanced escaping on
http://www.php.net/manual/en/language.basic-syntax.php
in the online documentation, since this is apparently an additional
method for disabling the PHP parser ?
NOTE: I did try to search the online documentation for without
any result. I also spoke to a PHP programmer with considerably more
experience than me, who was also unfamiliar with this construct.
Previous Comments:
[2002-04-17 16:01:32] [EMAIL PROTECTED]
What's wrong with
?php
echo Ene mene foobr /\n;
echo HTML
hr
Some more html
hr
HTML
?
Any, unlikely SUCH a change is done. Ever. :-)
[2002-04-17 12:29:12] [EMAIL PROTECTED]
I can't seem to figure out how to edit the submission,
so I can't fix the missing on html
[2002-04-17 12:24:55] [EMAIL PROTECTED]
Missed the opening on html
[2002-04-17 12:18:47] [EMAIL PROTECTED]
The following can be confusing to read:
html
brThis is plain HTML
?
echo brThis is a PHP Block;
?
brThis is raw html text embedded in PHP.
?
echo brThis is the same outer PHP block;
?
brThis is more plain HTML
/html
The following is easier to read, at least for me,
with a C programming background:
html
brThis is plain HTML
?
echo brThis is a PHP Block;
HTML
{
brThis is raw html text embedded in PHP.
}
echo brThis is the same outer PHP block;
?
brThis is more plain HTML
/html
This would make HTML a reserved word that would turn off
the PHP parser within the following set of braces, or if
braces aren't present, until the next semicolon. The
advantage of this style is it makes it easier to see the
underlying block structure of the PHP code, yet avoids
having to use echo or print to output chunks of HTML code.
--
Edit this bug report at http://bugs.php.net/?id=16663edit=1
Bug #16663 Updated: Different syntax for embedding HTML in PHP
ID: 16663
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: Feature/Change Request
Operating System: Linux
PHP Version: 4.2.0
New Comment:
Well, I found another bug report #8685 which clued me in about where to
find the documentation for this type of
construct, which is a heredoc text entry. Interestingly,
the other report was also from someone trying to write readable,
block-structured code, and was also classified as bogus. I guess us
old guys who were around when Pascal was invented just have some weird
ideas about how code should be organized to be people friendly.
Previous Comments:
[2002-04-17 17:00:04] [EMAIL PROTECTED]
There is nothing wrong with your alternative except that I can't find
info about the contstruct
echo HTML
some more html
HTML
in the online documentation. Should I add this to the notes regarding
Example 5-2. Advanced escaping on
http://www.php.net/manual/en/language.basic-syntax.php
in the online documentation, since this is apparently an additional
method for disabling the PHP parser ?
NOTE: I did try to search the online documentation for without
any result. I also spoke to a PHP programmer with considerably more
experience than me, who was also unfamiliar with this construct.
[2002-04-17 16:01:32] [EMAIL PROTECTED]
What's wrong with
?php
echo Ene mene foobr /\n;
echo HTML
hr
Some more html
hr
HTML
?
Any, unlikely SUCH a change is done. Ever. :-)
[2002-04-17 12:29:12] [EMAIL PROTECTED]
I can't seem to figure out how to edit the submission,
so I can't fix the missing on html
[2002-04-17 12:24:55] [EMAIL PROTECTED]
Missed the opening on html
[2002-04-17 12:18:47] [EMAIL PROTECTED]
The following can be confusing to read:
html
brThis is plain HTML
?
echo brThis is a PHP Block;
?
brThis is raw html text embedded in PHP.
?
echo brThis is the same outer PHP block;
?
brThis is more plain HTML
/html
The following is easier to read, at least for me,
with a C programming background:
html
brThis is plain HTML
?
echo brThis is a PHP Block;
HTML
{
brThis is raw html text embedded in PHP.
}
echo brThis is the same outer PHP block;
?
brThis is more plain HTML
/html
This would make HTML a reserved word that would turn off
the PHP parser within the following set of braces, or if
braces aren't present, until the next semicolon. The
advantage of this style is it makes it easier to see the
underlying block structure of the PHP code, yet avoids
having to use echo or print to output chunks of HTML code.
--
Edit this bug report at http://bugs.php.net/?id=16663edit=1
