#49478 [Fbk-Opn]: shell_exec does not work
ID: 49478
User updated by: elmue at gmx dot de
Reported By: elmue at gmx dot de
-Status: Feedback
+Status: Open
Bug Type: Program Execution
Operating System: Windows
PHP Version: 6SVN-2009-09-06 (snap)
Assigned To: pajoye
New Comment:
Hello
On which PHP6 version did you test it ?
Did you test on Windows ?
I used version build Sep 3 2009 21:23:55
Previous Comments:
[2009-09-22 08:41:40] paj...@php.net
I can't reproduce it with php6 neither with 5.3 or 5.2 in CLI or FCGI.
Can you try it with CLI/CGI too please?
[2009-09-22 05:18:15] ian at iglou dot com
Also broken in PHP Version 5.2.10; safe mode off.
An earlier version (no record of which) did work when used thus to get
a Windows dvd volume label:
if (preg_match('#Volume in drive [a-zA-Z]* is (.*)\n#i',
shell_exec('dir '.$drive.':'), $m)) {
$volname = ' ('.$m[1].')';
[2009-09-06 00:49:59] elmue at gmx dot de
Description:
On PHP 6 VC 6 from 3.sept.2009 the shell_exec command is broken.
Tested on Xampp on Windows XP with Apache 2.2.9.
Whatever you put into shell_exec e.g.
shell_exec(dir C:\\)
produces a
Warning shell_exec() [function.shell-exec]: Unable to execute 'dir
c:\'
The same script works fine on PHP 5
--
Edit this bug report at http://bugs.php.net/?id=49478edit=1
#49478 [Fbk-Opn]: shell_exec does not work
ID: 49478
User updated by: elmue at gmx dot de
Reported By: elmue at gmx dot de
-Status: Feedback
+Status: Open
Bug Type: Program Execution
Operating System: Windows
PHP Version: 6SVN-2009-09-06 (snap)
Assigned To: pajoye
New Comment:
Yes you are right.
In the build from 22.sep.2009 this bug is fixed.
Previous Comments:
[2009-09-22 14:06:54] paj...@php.net
Try with a recent snap please
[2009-09-22 14:06:37] paj...@php.net
Windows, today snaps.
[2009-09-22 13:46:42] elmue at gmx dot de
Hello
On which PHP6 version did you test it ?
Did you test on Windows ?
I used version build Sep 3 2009 21:23:55
[2009-09-22 08:41:40] paj...@php.net
I can't reproduce it with php6 neither with 5.3 or 5.2 in CLI or FCGI.
Can you try it with CLI/CGI too please?
[2009-09-22 05:18:15] ian at iglou dot com
Also broken in PHP Version 5.2.10; safe mode off.
An earlier version (no record of which) did work when used thus to get
a Windows dvd volume label:
if (preg_match('#Volume in drive [a-zA-Z]* is (.*)\n#i',
shell_exec('dir '.$drive.':'), $m)) {
$volname = ' ('.$m[1].')';
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/49478
--
Edit this bug report at http://bugs.php.net/?id=49478edit=1
#49476 [Com]: $_ENV does not work
ID: 49476 Comment by: elmue at gmx dot de Reported By: elmu at gmx dot de Status: Open Bug Type: Variables related Operating System: Windows PHP Version: 6SVN-2009-09-05 (snap) New Comment: I repeated the test on build from 22 sep 2009 and the result is the same $_ENV[OS] $_ENV[PROCESSOR_IDENTIFIER] $_ENV[COMPUTERNAME] are empty. Even a print_r($_ENV) shows: Array ( ) This cannot be caused by input encoding because these variables have no special characters in them. On PHP5 the same array has plenty content! Previous Comments: [2009-09-06 20:31:59] paj...@php.net ENV works just fine here. But there are changes about input encoding that have not been test at all. And all in all, the current status of php6 is not tested at all, unstable and needs heavy work to get to something usable (usable != stable). [2009-09-06 19:48:16] elmu at gmx dot de Note: It seems that the current PHP 6 has not yet been tested on Windows. All the bugs I found are related to filesystem or operation system. [2009-09-05 23:57:06] elmu at gmx dot de Sorry I wanted to say $_SERVER[SERVER_SIGNATURE] works on both. [2009-09-05 23:52:42] elmu at gmx dot de Description: $_ENV[OS] $_ENV[PROCESSOR_IDENTIFIER] $_ENV[COMPUTERNAME] are empty on PHP 6 VC6 while the same code works fine on PHP 5, while $_ENV[SERVER_SIGNATURE] works on both PHP 5 and PHP 6. On the other hand the missing values appear correctly in phpinfo() Strange. -- Edit this bug report at http://bugs.php.net/?id=49476edit=1
#49476 [Com]: $_ENV does not work
ID: 49476 Comment by: elmue at gmx dot de Reported By: elmu at gmx dot de Status: Open Bug Type: Variables related Operating System: Windows PHP Version: 6SVN-2009-09-05 (snap) New Comment: Hello In version 22 sep 2009 it is even worse: print_r($_FILES); throws: Failed to decode _FILES array The last time I tested on PHP6 this did work. Now its broken. Previous Comments: [2009-09-22 21:03:52] elmue at gmx dot de I repeated the test on build from 22 sep 2009 and the result is the same $_ENV[OS] $_ENV[PROCESSOR_IDENTIFIER] $_ENV[COMPUTERNAME] are empty. Even a print_r($_ENV) shows: Array ( ) This cannot be caused by input encoding because these variables have no special characters in them. On PHP5 the same array has plenty content! [2009-09-06 20:31:59] paj...@php.net ENV works just fine here. But there are changes about input encoding that have not been test at all. And all in all, the current status of php6 is not tested at all, unstable and needs heavy work to get to something usable (usable != stable). [2009-09-06 19:48:16] elmu at gmx dot de Note: It seems that the current PHP 6 has not yet been tested on Windows. All the bugs I found are related to filesystem or operation system. [2009-09-05 23:57:06] elmu at gmx dot de Sorry I wanted to say $_SERVER[SERVER_SIGNATURE] works on both. [2009-09-05 23:52:42] elmu at gmx dot de Description: $_ENV[OS] $_ENV[PROCESSOR_IDENTIFIER] $_ENV[COMPUTERNAME] are empty on PHP 6 VC6 while the same code works fine on PHP 5, while $_ENV[SERVER_SIGNATURE] works on both PHP 5 and PHP 6. On the other hand the missing values appear correctly in phpinfo() Strange. -- Edit this bug report at http://bugs.php.net/?id=49476edit=1
#49633 [NEW]: $_FILES cannot be accessed
From: elmue at gmx dot de Operating system: Windows PHP version: 6SVN-2009-09-22 (snap) PHP Bug Type: Variables related Bug description: $_FILES cannot be accessed Description: In version 22 sep 2009: print_r($_FILES); throws: Failed to decode _FILES array and Could not convert binary string to Unicode string (converter UTF-8 failed on bytes (0xF3) at offset 60) But there is no character F3 in the filename! -- Edit bug report at http://bugs.php.net/?id=49633edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49633r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49633r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49633r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49633r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49633r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49633r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49633r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49633r=needscript Try newer version: http://bugs.php.net/fix.php?id=49633r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49633r=support Expected behavior: http://bugs.php.net/fix.php?id=49633r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49633r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49633r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49633r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49633r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49633r=dst IIS Stability: http://bugs.php.net/fix.php?id=49633r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49633r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49633r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49633r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49633r=mysqlcfg
#49475 [NEW]: readdir fails for Unicode filenames
From: elmue at gmx dot de
Operating system: Windows
PHP version: 6SVN-2009-09-05 (snap)
PHP Bug Type: *Unicode Issues
Bug description: readdir fails for Unicode filenames
Description:
Hello
I have PHP6 - VC6 compiled on 3. Sept 2009.
How to reproduce the bug:
Create a file:
C:\Temp\Tést.txt
(note the accent on the e)
Execute the code below.
What happens is the warning:
Could not convert binary string to Unicode string (converter UTF-8 failed
on bytes (0xE9) at offset 1)
(E9 is the Ascii code of the 'é' character)
and an empty string is returned in $File.
If the filename contains russian or greek characters it is even worse:
In this case no warning is displayed and the filename is returned as
??.txt
This warning message is nonsense.
All Windows Operating Systems store Filenames in Unicode except Windows
95,98,ME which are out of date.
So there is no reason to put the filename into an UTF-8 converter as the
warning says.
There is no conversion required on Windows if the correct API is used.
Windows offers the old FindFirstFileA(...) API and the Unicode
FindFirstFileW(..) API. I hope that the PHP programmers did not make the
error to use the Ansii versions which are Codepage dependent and produce a
!lot! of problems.
The Wide API like FindFirstFileW(...) returns ALL filenames directly in
Unicode. There is NO CONVERSION required on Windows and there is NO UTF-8
converter required.
I also played around with different settings for
ini_set(unicode.filesystem_encoding, ...)
but the error stays the same.
There is design error deep in the code.
Elmü
Reproduce code:
---
?php
$hDir = opendir(C:\\Temp);
while ($hDir)
{
$File = readdir($hDir); // --- produces warning
if ($File === false) break;
echo File=$Filebr;
}
?
Expected result:
correct filename
no warning
Actual result:
--
the file is returned as empty string or as ?.txt
--
Edit bug report at http://bugs.php.net/?id=49475edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49475r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49475r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49475r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49475r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49475r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49475r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49475r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49475r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49475r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49475r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49475r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49475r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49475r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49475r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49475r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49475r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49475r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49475r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49475r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49475r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49475r=mysqlcfg
#49475 [Bgs]: readdir fails for Unicode filenames
ID: 49475
User updated by: elmue at gmx dot de
Reported By: elmue at gmx dot de
Status: Bogus
Bug Type: *Unicode Issues
Operating System: Windows
PHP Version: 6SVN-2009-09-05 (snap)
New Comment:
Hello
In the meantime you can use mbstring to convert to your local
encoding
I suppose that you did not read what I explained.
How do I use mbstring to convert anything if an empty string is
returned?
mbstring can only convert an empty string into another empty sting!
This would not be very usefull!
And mbstring also can't convert ??.txt into anything usefull.
The code that I posted works fine on PHP 5 (at least if I don't use
greek or russian characters) but on PHP 6 it is broken.
There is no way!
On PHP 6 you can't currently work with filenames that have an accent or
umlaut. Its worse than PHP 5.
Elmü
Previous Comments:
[2009-09-05 22:05:25] paj...@php.net
There is already a feature request about that. In the meantime you can
use mbstring to convert to your local encoding (check your prefs and
verify which encoding you have to use). But real unicode support for
file operations will not be available soon, early next year at the
soonest.
[2009-09-05 21:57:04] elmue at gmx dot de
Description:
Hello
I have PHP6 - VC6 compiled on 3. Sept 2009.
How to reproduce the bug:
Create a file:
C:\Temp\Tést.txt
(note the accent on the e)
Execute the code below.
What happens is the warning:
Could not convert binary string to Unicode string (converter UTF-8
failed on bytes (0xE9) at offset 1)
(E9 is the Ascii code of the 'é' character)
and an empty string is returned in $File.
If the filename contains russian or greek characters it is even worse:
In this case no warning is displayed and the filename is returned as
??.txt
This warning message is nonsense.
All Windows Operating Systems store Filenames in Unicode except Windows
95,98,ME which are out of date.
So there is no reason to put the filename into an UTF-8 converter as
the warning says.
There is no conversion required on Windows if the correct API is used.
Windows offers the old FindFirstFileA(...) API and the Unicode
FindFirstFileW(..) API. I hope that the PHP programmers did not make the
error to use the Ansii versions which are Codepage dependent and produce
a !lot! of problems.
The Wide API like FindFirstFileW(...) returns ALL filenames directly in
Unicode. There is NO CONVERSION required on Windows and there is NO
UTF-8 converter required.
I also played around with different settings for
ini_set(unicode.filesystem_encoding, ...)
but the error stays the same.
There is design error deep in the code.
Elmü
Reproduce code:
---
?php
$hDir = opendir(C:\\Temp);
while ($hDir)
{
$File = readdir($hDir); // --- produces warning
if ($File === false) break;
echo File=$Filebr;
}
?
Expected result:
correct filename
no warning
Actual result:
--
the file is returned as empty string or as ?.txt
--
Edit this bug report at http://bugs.php.net/?id=49475edit=1
#49477 [NEW]: PHP 6 VC 9 makes Apache not to start
From: elmue at gmx dot de Operating system: Windows PHP version: 6SVN-2009-09-06 (snap) PHP Bug Type: Apache2 related Bug description: PHP 6 VC 9 makes Apache not to start Description: Today I downloaded from http://windows.php.net/snapshots/ the VC 6 version of PHP 6 http://windows.php.net/downloads/snaps/php-6.0-win32-VC6-x86-latest.zip and installed it on Windows XP with Xampp, Apache version 2.2.9 It runs and functions. But the VC 9 http://windows.php.net/downloads/snaps/php-6.0-win32-VC9-x86-latest.zip is broken. Although both ZIPs contain files from 3. sept 2009 the one runs and the other one does not. The same way installed the VC6 runs but the VC9 makes that Apache does not start. In the Windows Event log there are two error entries generated: 1.) Cannot load E:/Programme/xampp/php6/php6apache2_2.dll into server: Syntax error on line 7 of E:/Programme/xampp/apache/conf/extra/httpd-xampp.conf This is ABSOULTE nonsense! There is no error in line 7 which is: LoadModule php6_module E:/Programme/xampp/php6/php6apache2_2.dll The SAME HTTPD-XAMP.CONF works with VC6 without problems. Without touching the conf file and only replacing the content of the php directory the errors are generated. So this is a bogus error telling that there is a syntax error which is not. The PHP.ini is the same in both cases: the one in the ZIP file: php.ini-development 2.) The second error in Event log says that the configuration is wrong. There is absoultely NO USEFULL information in these 2 error messages. The first one is bogus and the second one gives no information. Can anyone please check this on a Xampp to confirm this problem? Elmü -- Edit bug report at http://bugs.php.net/?id=49477edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49477r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49477r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49477r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49477r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49477r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49477r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49477r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49477r=needscript Try newer version: http://bugs.php.net/fix.php?id=49477r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49477r=support Expected behavior: http://bugs.php.net/fix.php?id=49477r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49477r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49477r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49477r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49477r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49477r=dst IIS Stability: http://bugs.php.net/fix.php?id=49477r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49477r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49477r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49477r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49477r=mysqlcfg
#49478 [NEW]: shell_exec does not work
From: elmue at gmx dot de Operating system: Windows PHP version: 6SVN-2009-09-06 (snap) PHP Bug Type: Program Execution Bug description: shell_exec does not work Description: On PHP 6 VC 6 from 3.sept.2009 the shell_exec command is broken. Tested on Xampp on Windows XP with Apache 2.2.9. Whatever you put into shell_exec e.g. shell_exec(dir C:\\) produces a Warning shell_exec() [function.shell-exec]: Unable to execute 'dir c:\' The same script works fine on PHP 5 -- Edit bug report at http://bugs.php.net/?id=49478edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49478r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49478r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49478r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49478r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49478r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49478r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49478r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49478r=needscript Try newer version: http://bugs.php.net/fix.php?id=49478r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49478r=support Expected behavior: http://bugs.php.net/fix.php?id=49478r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49478r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49478r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49478r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49478r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49478r=dst IIS Stability: http://bugs.php.net/fix.php?id=49478r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49478r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49478r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49478r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49478r=mysqlcfg
#49479 [NEW]: move_uploaded_file is dead
From: elmue at gmx dot de Operating system: Windows PHP version: 6SVN-2009-09-06 (snap) PHP Bug Type: Filesystem function related Bug description: move_uploaded_file is dead Description: On PHP 6 VC6 from 3.sept.2009 the function move_uploaded_file() is completely dead. Tested on Windows XP with Xampp, Apache 2.2.9 is_file($_FILES[UploadFile][tmp_name]) returns true that means that the files has been uploaded correctly. The array $_FILES is filled with correct values. The destination file for move_uploaded_file() is a valid path with filename but the file is never moved. The same script works fine on PHP 5. -- Edit bug report at http://bugs.php.net/?id=49479edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49479r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49479r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49479r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49479r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49479r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49479r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49479r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49479r=needscript Try newer version: http://bugs.php.net/fix.php?id=49479r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49479r=support Expected behavior: http://bugs.php.net/fix.php?id=49479r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49479r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49479r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49479r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49479r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49479r=dst IIS Stability: http://bugs.php.net/fix.php?id=49479r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49479r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49479r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49479r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49479r=mysqlcfg
