#49471 [Opn->Bgs]: Multiple object selection operators in quoted strings
ID: 49471
Updated by: j...@php.net
Reported By: tudor at tudorholton dot com
-Status: Open
+Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Ubuntu
-PHP Version: 5.2SVN-2009-09-05 (snap)
+PHP Version: 5.2.6
New Comment:
RTFM: http://www.php.net/types.string#language.types.string.parsing
This works fine:
echo "{$b->a->attr}";
Previous Comments:
[2009-09-05 05:41:54] tudor at tudorholton dot com
Description:
This is actually on Ubuntu Jaunty which is PHP version
5.2.6-3ubuntu4.2
Using multiple object access operators in a row inside a double-quoted
string causes the error:
Catchable fatal error: Object of class ... could not be converted to
string
The problem is that the operators are interpreted from left to right
and then converted to string. The last operation should be that the
object is converted to a string.
This is particularly important when using OO code because frequently
the current object ($this) references another object and then gets an
attribute from that. e.g. $this->that->attribute
Reproduce code:
---
a = new A();
}
function output() {
echo "$this->attr";
}
}
$b = new B();
$b->output();
echo "$b->attr";
echo "$b->a->attr";
?>
Expected result:
Hello B!Hello B!Hello A!
Actual result:
--
Hello B!Hello B!
Catchable fatal error: Object of class A could not be converted to
string in test.php on line 19
--
Edit this bug report at http://bugs.php.net/?id=49471&edit=1
#49472 [NEW]: Constants defined in Interfaces can be overridden
From: phil at mossyvale dot co dot uk Operating system: Mac OS X 10.5.8 PHP version: 5.3.0 PHP Bug Type: Class/Object related Bug description: Constants defined in Interfaces can be overridden Description: If an interface defines a constant and is then implemented by a class which is then extended with a further class and both classes implement the interface, the second class may override the interface constant without a fatal error. Also present in 5.2.10 on FreeBSD 7.2 Reproduce code: --- --- >From manual page: language.oop5.interfaces --- http://codepad.org/vStYX1Kz Expected result: Fatal error: Cannot inherit previously-inherited constant c from interface ia ... on line 18 Actual result: -- Program outputs "OceanSea" which indicates that the interface constant is still available but the class constant with the same name overrides it. -- Edit bug report at http://bugs.php.net/?id=49472&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49472&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49472&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49472&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49472&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49472&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49472&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49472&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49472&r=needscript Try newer version: http://bugs.php.net/fix.php?id=49472&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49472&r=support Expected behavior: http://bugs.php.net/fix.php?id=49472&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49472&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49472&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49472&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49472&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49472&r=dst IIS Stability: http://bugs.php.net/fix.php?id=49472&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49472&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49472&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49472&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49472&r=mysqlcfg
#49472 [Opn->Ver]: Constants defined in Interfaces can be overridden
ID: 49472 Updated by: j...@php.net Reported By: phil at mossyvale dot co dot uk -Status: Open +Status: Verified Bug Type: Class/Object related Operating System: * PHP Version: 5.*, 6 Previous Comments: [2009-09-05 10:08:19] phil at mossyvale dot co dot uk Description: If an interface defines a constant and is then implemented by a class which is then extended with a further class and both classes implement the interface, the second class may override the interface constant without a fatal error. Also present in 5.2.10 on FreeBSD 7.2 Reproduce code: --- --- >From manual page: language.oop5.interfaces --- http://codepad.org/vStYX1Kz Expected result: Fatal error: Cannot inherit previously-inherited constant c from interface ia ... on line 18 Actual result: -- Program outputs "OceanSea" which indicates that the interface constant is still available but the class constant with the same name overrides it. -- Edit this bug report at http://bugs.php.net/?id=49472&edit=1
#49182 [Asn]: PHP CGI always outputs the shebang line
ID: 49182 Updated by: j...@php.net Reported By: salsi at icosaedro dot it Status: Assigned Bug Type: CGI related Operating System: * PHP Version: 5.3SVN-2009-09-04 (SVN) Assigned To: iliaa New Comment: It's only useful for CGI and CLI. Other SAPIs shouldn't care about it. Previous Comments: [2009-09-04 15:26:16] j...@php.net Maybe that's a good argument for moving it out of the scanner and back into the SAPIs? I don't find it difficult to accept the argument that it's a SAPI-specific behaviour. [2009-09-04 11:22:10] j...@php.net Ilia's fix for bug #46844 actually broke it. [2009-09-04 08:35:46] j...@php.net http://svn.php.net/viewvc/php/php-src/trunk/Zend/zend_language_scanner.l?r1=272489&r2=273177 looks like the problem. [2009-09-04 07:48:19] j...@php.net Still happens using latest SVN checkout of today. [2009-09-04 07:41:34] j...@php.net Still borked. 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/49182 -- Edit this bug report at http://bugs.php.net/?id=49182&edit=1
#48746 [Fbk]: Unable to browse directories within Junction Points
ID: 48746
Updated by: paj...@php.net
Reported By: ddkees at illinois dot edu
Status: Feedback
Bug Type: Directory function related
Operating System: win32 only - Windows Server 2003
PHP Version: 5.3.0
Assigned To: pajoye
New Comment:
Please try using:
http://windows.php.net/downloads/qa/test/php-5.3.2-dev-Win32-VC9-x86.zip
It is a striped down build (thread safe). Only CLI is available but no
worry, it behaves the same than apache in TS mode.
Previous Comments:
[2009-09-04 20:59:28] phpstuff at cresstone dot com
Using junctions: is_file and file_exists are giving incorrect behavior
(false on files). is_dir as well, false on directories in the junction
and the junction itself.
The same functions are working well with symlinks.
If you need testing for this, you have mail.
[2009-09-04 20:45:25] paj...@php.net
@[4 Sep 8:20pm UTC] phpstuff at cresstone dot com
Using is_dir and is_file or file_exists and the cases you described,
does it work? (I don't think the filetype issue is related to what we
discuss here).
[2009-09-04 20:20:02] phpstuff at cresstone dot com
I was able replicate shoresofnowhere's behavior using windows 7...
I created a junction to a folder on another drive; running is_file() on
a file inside that junction returned false, as did is_dir(). Curious to
see what php thought it was looking at, I tested filetype(), which threw
an error.
I then tested symlinks in the same manner, and got good behavior.
Symlinks seem to be a good workaround for this issue.
Test log follows:
C:\mnt\test>mklink /J junction_otherDrive f:\downloads
Junction created for junction_otherDrive <<===>> f:\downloads
C:\mnt\test>mklink /D symlink_otherDrive f:\downloads
symbolic link created for symlink_otherDrive <<===>> f:\downloads
C:\mnt\test>dir
Volume in drive C is coreI7_System
Volume Serial Number is 38E2-2B62
Directory of C:\mnt\test
2009.09.04 16.05 .
2009.09.04 16.05 ..
2009.09.04 16.05 junction_otherDrive [f:\downloads]
2009.09.04 16.05 symlink_otherDrive [f:\downloads]
0 File(s) 0 bytes
4 Dir(s) 30,034,223,104 bytes free
C:\mnt\test>php -r var_dump(filetype('junction_otherdrive'));
PHP Warning: filetype(): Lstat failed for junction_otherdrive in
Command line code on line 1
Warning: filetype(): Lstat failed for junction_otherdrive in Command
line code on line 1
bool(false)
C:\mnt\test>php -r
var_dump(filetype('junction_otherdrive\php-5.2.0-win32-installer.msi'));
PHP Warning: filetype(): Lstat failed for
junction_otherdrive\php-5.2.0-win32-installer.msi in Comm
and line code on line 1
Warning: filetype(): Lstat failed for
junction_otherdrive\php-5.2.0-win32-installer.msi in Command l
ine code on line 1
bool(false)
C:\mnt\test>php -r var_dump(filetype('symlink_otherdrive'));
string(3) "dir"
C:\mnt\test>php -r
var_dump(filetype('symlink_otherdrive\php-5.2.0-win32-installer.msi'));
string(4) "file"
[2009-09-04 18:32:33] paj...@php.net
Ignore my last two comments, it works perfectly using what you
describe. I was testing it from another VM where this junction did not
exist.
I added a include 'dir3/two.php' to one.php, two.php being a simple
echo "two.php"
The output:
C:\test>\php53\debug_ts\php.exe -n one.php
two.php
bool(true)
C:\test>junction dir3
C:\test\dir3: JUNCTION
Substitute Name: e:\test
C:\test>dir dir3
...
09/04/2009 07:33 PM24 two.php
1 File(s) 24 bytes
2 Dir(s) 202,975,232 bytes free
[2009-09-04 17:50:34] paj...@php.net
Please note that it is again a XP/2k3 only issue. Debugging/fixing now.
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/48746
--
Edit this bug report at http://bugs.php.net/?id=48746&edit=1
#49474 [NEW]: use set_time_limit() trow an Warning info.
From: hack988 at gmail dot com Operating system: windows PHP version: 6SVN-2009-09-05 (snap) PHP Bug Type: Scripting Engine problem Bug description: use set_time_limit() trow an Warning info. Description: I'm test set_time_limit function with no param,it trow an warning info.I have see description in online manual: When called, set_time_limit() restarts the timeout counter from zero. In other words, if the timeout is the default 30 seconds, and 25 seconds into script execution a call such as set_time_limit(20) is made, the script will run for a total of 45 seconds before timing out. It's means this function with no param must work well. BTW:I'm test codes in php6-dev and php 5.2.9 all of them trow an warning.:( Reproduce code: --- set_time_limit(50); set_time_limit(); exit; Expected result: Warning: set_time_limit() expects exactly 1 parameter, 0 given in xxx on line 3 PHP Warning: set_time_limit() expects exactly 1 parameter, 0 given in xxx on line 3 -- Edit bug report at http://bugs.php.net/?id=49474&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49474&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49474&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49474&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49474&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49474&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49474&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49474&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49474&r=needscript Try newer version: http://bugs.php.net/fix.php?id=49474&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49474&r=support Expected behavior: http://bugs.php.net/fix.php?id=49474&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49474&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49474&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49474&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49474&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49474&r=dst IIS Stability: http://bugs.php.net/fix.php?id=49474&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49474&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49474&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49474&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49474&r=mysqlcfg
#49182 [Asn->Csd]: PHP CGI always outputs the shebang line
ID: 49182 Updated by: j...@php.net Reported By: salsi at icosaedro dot it -Status: Assigned +Status: Closed Bug Type: CGI related Operating System: * PHP Version: 5.3SVN-2009-09-04 (SVN) Assigned To: iliaa New Comment: Fixed in SVN. No idea in what release it will be in, but next snapshot of 5.3 at least has it. Previous Comments: [2009-09-05 17:07:15] s...@php.net Automatic comment from SVN on behalf of jani Revision: http://svn.php.net/viewvc/?view=revision&revision=288081 Log: - Fixed bug #49182 (PHP CGI always outputs the shebang line) [2009-09-05 11:50:19] j...@php.net It's only useful for CGI and CLI. Other SAPIs shouldn't care about it. [2009-09-04 15:26:16] j...@php.net Maybe that's a good argument for moving it out of the scanner and back into the SAPIs? I don't find it difficult to accept the argument that it's a SAPI-specific behaviour. [2009-09-04 11:22:10] j...@php.net Ilia's fix for bug #46844 actually broke it. [2009-09-04 08:35:46] j...@php.net http://svn.php.net/viewvc/php/php-src/trunk/Zend/zend_language_scanner.l?r1=272489&r2=273177 looks like the problem. 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/49182 -- Edit this bug report at http://bugs.php.net/?id=49182&edit=1
#49182 [Csd]: PHP CGI always outputs the shebang line
ID: 49182 Updated by: j...@php.net Reported By: salsi at icosaedro dot it Status: Closed Bug Type: CGI related Operating System: * PHP Version: 5.3SVN-2009-09-04 (SVN) Assigned To: iliaa New Comment: The fix was simply reverting this change: http://svn.php.net/viewvc?view=revision&revision=264152 Previous Comments: [2009-09-05 17:08:51] j...@php.net Fixed in SVN. No idea in what release it will be in, but next snapshot of 5.3 at least has it. [2009-09-05 17:07:15] s...@php.net Automatic comment from SVN on behalf of jani Revision: http://svn.php.net/viewvc/?view=revision&revision=288081 Log: - Fixed bug #49182 (PHP CGI always outputs the shebang line) [2009-09-05 11:50:19] j...@php.net It's only useful for CGI and CLI. Other SAPIs shouldn't care about it. [2009-09-04 15:26:16] j...@php.net Maybe that's a good argument for moving it out of the scanner and back into the SAPIs? I don't find it difficult to accept the argument that it's a SAPI-specific behaviour. [2009-09-04 11:22:10] j...@php.net Ilia's fix for bug #46844 actually broke it. 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/49182 -- Edit this bug report at http://bugs.php.net/?id=49182&edit=1
#47930 [Asn]: ext/filter crashes when module startup bails out
ID: 47930 Updated by: paj...@php.net Reported By: stas at zend dot com Status: Assigned Bug Type: Reproducible crash Operating System: * PHP Version: 5.2CVS-2009-04-29 -Assigned To: derick +Assigned To: stas New Comment: Any reason why this change has been commited to HEAD but never to 5.3, or has it been reverted? Please clarify the situation and sync both branches as soon as possible. Previous Comments: [2009-04-29 00:41:24] s...@php.net fixed for 5.3/HEAD, 5.2 fix still required, since 5.3+ fix changes binary API [2009-04-08 23:01:04] stas at zend dot com Description: 1. If one of the modules startup bails out, that leads to aborting the startup sequence and PG(modules_activated) be 0. This, in turn, precludes running RSHUTDOWN functions on modules. 2. ext/filter allocates IF_G(get_array), etc. in the course of the request startup, and if RSHUTDOWN is not called, they are not cleaned up. 3. Since ext/filter does not initialize IF_G arrays, on the next request uncleaned value will be used. Since these arrays are no longer pointing to a valid memory (which was cleaned on the end of the previous request), this will result in a crash. Reproduce code: --- 1. Create extension that uses zend_bailout in RINIT. 2. Run two requests while ext/filter is present and turned on 3. Crash! -- Edit this bug report at http://bugs.php.net/?id=47930&edit=1
#49470 [Com]: FILTER_SANITIZE_EMAIL does not work
ID: 49470
Comment by: contact at ghetmedia dot com
Reported By: contact at ghetmedia dot com
Status: Verified
Bug Type: Filter related
Operating System: *
PHP Version: 5.2SVN-2009-09-04 (snap)
New Comment:
This is not compliant with the domain name RFC.
Previous Comments:
[2009-09-04 23:26:46] contact at ghetmedia dot com
Description:
Filter_var and it's flag FILTER_SANITIZE_EMAIL do absolutely nothing.
Reproduce code:
---
echo filter_var('t...@t//est.com', FILTER_SANITIZE_EMAIL);
Expected result:
t...@test.com
Actual result:
--
t...@t//est.com
--
Edit this bug report at http://bugs.php.net/?id=49470&edit=1
#49274 [Ana->Asn]: filter_var() should accept objects without fatal error
ID: 49274 Updated by: paj...@php.net Reported By: cel...@php.net -Status: Analyzed +Status: Assigned Bug Type: Feature/Change Request Operating System: * PHP Version: 5.3SVN-2009-08-16 (SVN) -Assigned To: +Assigned To: pajoye New Comment: I will close it as soon as it gets merged in 5.3.1, if the RM agrees. Previous Comments: [2009-09-05 17:35:27] s...@php.net Automatic comment from SVN on behalf of pajoye Revision: http://svn.php.net/viewvc/?view=revision&revision=288083 Log: - fix #49274, filter_var does not accept object without a toString implementation [2009-08-17 21:59:13] paj...@php.net http://pastie.org/586442 should do it. I did not not test more than the test case here. [2009-08-17 13:55:58] paj...@php.net it is indeed valid for all objects but it is still an edge case. A check for IS_OBJECT + tostring() existence could be easy enough and with almost no impact(perf impact is null on the existing application). If you have some time to write one, go ahead. [2009-08-17 13:52:56] cel...@php.net the stdClass was just to illustrate the point, this happens with any object that doesn't have a __toString(). I would imagine it would be easier to check for IS_OBJECT and then see if it implements __toString than to do a custom error handler. The performance should be about the same (dismal). [2009-08-17 13:48:45] paj...@php.net As StdClass has no __toString implementation (obviously), it can't be converted to string. I tend to agree that it should not raise a fatal (recovable error) here as it defeats the main purpose of this API. I'm however not sure it is worth the effort to add custom error handler for this edge case. Patch welcome, it could help to get this edge case solved (I can't work on this exact issue any time soon). 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/49274 -- Edit this bug report at http://bugs.php.net/?id=49274&edit=1
#49469 [Opn->Fbk]: session.hash_function = sha512 doesnt work
ID: 49469 Updated by: j...@php.net Reported By: elfi_47 at gmx dot de -Status: Open +Status: Feedback Bug Type: Session related Operating System: openSuse 10.3 PHP Version: 5.3.0 New Comment: Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Previous Comments: [2009-09-04 19:27:59] elfi_47 at gmx dot de Description: php 5.3 ignores "session.hash_function = sha512". it sets automatically session.hash_function = 0 in hash_algos() sha512 is available. -- Edit this bug report at http://bugs.php.net/?id=49469&edit=1
#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:
---
";
}
?>
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=49475&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49475&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49475&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49475&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49475&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49475&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49475&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49475&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49475&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49475&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49475&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49475&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49475&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49475&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49475&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49475&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49475&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49475&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49475&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49475&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49475&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49475&r=mysqlcfg
#49190 [Opn->Bgs]: PharData::convertToExecutable does not recognize filenames with multiple dots
ID: 49190
Updated by: cel...@php.net
Reported By: alexander dot wahl at netclusive dot com
-Status: Open
+Status: Bogus
Bug Type: PHAR related
Operating System: Linux 2.6.26-2-amd64
PHP Version: 5.3.0
New Comment:
convertToExecutable(Phar::PHAR, Phar::NONE,
'.one.two.phar');
} catch (Exception $e) {
echo $e->getMessage();
}
?>
will do what you desire.
Previous Comments:
[2009-08-07 14:26:50] alexander dot wahl at netclusive dot com
email typo
[2009-08-07 14:25:44] alexander dot wahl at netlusive dot com
email typo
[2009-08-07 14:23:26] alexander dot wahl at netclusive dot com
Description:
PharData::convertToExecutable does not recognize filenames with
multiple
dots, while creating the new archive. Everything from the first dot is
ignored.
Reproduce code:
---
convertToExecutable(Phar::PHAR, Phar::NONE, '.phar');
} catch (Exception $e) {
echo $e->getMessage();
}
?>
Expected result:
A new PHAR archive with the expected filename:
test.one.two.phar
Actual result:
--
A new PHAR archive with the filename:
test.phar
--
Edit this bug report at http://bugs.php.net/?id=49190&edit=1
#49475 [Opn->Bgs]: readdir fails for Unicode filenames
ID: 49475
Updated by: paj...@php.net
Reported By: elmue at gmx dot de
-Status: Open
+Status: Bogus
Bug Type: *Unicode Issues
Operating System: Windows
PHP Version: 6SVN-2009-09-05 (snap)
New Comment:
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.
Previous Comments:
[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:
---
";
}
?>
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=49475&edit=1
#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:
---
";
}
?>
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=49475&edit=1
#48746 [Com]: Unable to browse directories within Junction Points
ID: 48746
Comment by: phpstuff at cresstone dot com
Reported By: ddkees at illinois dot edu
Status: Feedback
Bug Type: Directory function related
Operating System: win32 only - Windows Server 2003
PHP Version: 5.3.0
Assigned To: pajoye
New Comment:
That build fixed it for me.
Previous Comments:
[2009-09-05 18:10:32] s...@php.net
Automatic comment from SVN on behalf of pajoye
Revision: http://svn.php.net/viewvc/?view=revision&revision=288085
Log: - add test for #48746
[2009-09-05 16:34:37] paj...@php.net
Please try using:
http://windows.php.net/downloads/qa/test/php-5.3.2-dev-Win32-VC9-x86.zip
It is a striped down build (thread safe). Only CLI is available but no
worry, it behaves the same than apache in TS mode.
[2009-09-04 20:59:28] phpstuff at cresstone dot com
Using junctions: is_file and file_exists are giving incorrect behavior
(false on files). is_dir as well, false on directories in the junction
and the junction itself.
The same functions are working well with symlinks.
If you need testing for this, you have mail.
[2009-09-04 20:45:25] paj...@php.net
@[4 Sep 8:20pm UTC] phpstuff at cresstone dot com
Using is_dir and is_file or file_exists and the cases you described,
does it work? (I don't think the filetype issue is related to what we
discuss here).
[2009-09-04 20:20:02] phpstuff at cresstone dot com
I was able replicate shoresofnowhere's behavior using windows 7...
I created a junction to a folder on another drive; running is_file() on
a file inside that junction returned false, as did is_dir(). Curious to
see what php thought it was looking at, I tested filetype(), which threw
an error.
I then tested symlinks in the same manner, and got good behavior.
Symlinks seem to be a good workaround for this issue.
Test log follows:
C:\mnt\test>mklink /J junction_otherDrive f:\downloads
Junction created for junction_otherDrive <<===>> f:\downloads
C:\mnt\test>mklink /D symlink_otherDrive f:\downloads
symbolic link created for symlink_otherDrive <<===>> f:\downloads
C:\mnt\test>dir
Volume in drive C is coreI7_System
Volume Serial Number is 38E2-2B62
Directory of C:\mnt\test
2009.09.04 16.05 .
2009.09.04 16.05 ..
2009.09.04 16.05 junction_otherDrive [f:\downloads]
2009.09.04 16.05 symlink_otherDrive [f:\downloads]
0 File(s) 0 bytes
4 Dir(s) 30,034,223,104 bytes free
C:\mnt\test>php -r var_dump(filetype('junction_otherdrive'));
PHP Warning: filetype(): Lstat failed for junction_otherdrive in
Command line code on line 1
Warning: filetype(): Lstat failed for junction_otherdrive in Command
line code on line 1
bool(false)
C:\mnt\test>php -r
var_dump(filetype('junction_otherdrive\php-5.2.0-win32-installer.msi'));
PHP Warning: filetype(): Lstat failed for
junction_otherdrive\php-5.2.0-win32-installer.msi in Comm
and line code on line 1
Warning: filetype(): Lstat failed for
junction_otherdrive\php-5.2.0-win32-installer.msi in Command l
ine code on line 1
bool(false)
C:\mnt\test>php -r var_dump(filetype('symlink_otherdrive'));
string(3) "dir"
C:\mnt\test>php -r
var_dump(filetype('symlink_otherdrive\php-5.2.0-win32-installer.msi'));
string(4) "file"
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/48746
--
Edit this bug report at http://bugs.php.net/?id=48746&edit=1
#49475 [Bgs]: readdir fails for Unicode filenames
ID: 49475
Updated by: paj...@php.net
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:
That's the same, unless we change file ops to return binary string for
the string represented a path.
Previous Comments:
[2009-09-05 22:41:28] elmue at gmx dot de
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ü
[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:
---
";
}
?>
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=49475&edit=1
#47930 [Asn]: ext/filter crashes when module startup bails out
ID: 47930 Updated by: s...@php.net Reported By: stas at zend dot com Status: Assigned Bug Type: Reproducible crash Operating System: * PHP Version: 5.2CVS-2009-04-29 Assigned To: stas New Comment: Fix for 5.3 changes binary API, so it can't be applied to 5.2 Previous Comments: [2009-09-05 17:17:31] paj...@php.net Any reason why this change has been commited to HEAD but never to 5.3, or has it been reverted? Please clarify the situation and sync both branches as soon as possible. [2009-04-29 00:41:24] s...@php.net fixed for 5.3/HEAD, 5.2 fix still required, since 5.3+ fix changes binary API [2009-04-08 23:01:04] stas at zend dot com Description: 1. If one of the modules startup bails out, that leads to aborting the startup sequence and PG(modules_activated) be 0. This, in turn, precludes running RSHUTDOWN functions on modules. 2. ext/filter allocates IF_G(get_array), etc. in the course of the request startup, and if RSHUTDOWN is not called, they are not cleaned up. 3. Since ext/filter does not initialize IF_G arrays, on the next request uncleaned value will be used. Since these arrays are no longer pointing to a valid memory (which was cleaned on the end of the previous request), this will result in a crash. Reproduce code: --- 1. Create extension that uses zend_bailout in RINIT. 2. Run two requests while ext/filter is present and turned on 3. Crash! -- Edit this bug report at http://bugs.php.net/?id=47930&edit=1
#49476 [NEW]: $_ENV does not work
From: elmu at gmx dot de Operating system: Windows PHP version: 6SVN-2009-09-05 (snap) PHP Bug Type: Variables related Bug description: $_ENV does not work 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 bug report at http://bugs.php.net/?id=49476&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49476&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49476&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49476&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49476&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49476&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49476&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49476&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49476&r=needscript Try newer version: http://bugs.php.net/fix.php?id=49476&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49476&r=support Expected behavior: http://bugs.php.net/fix.php?id=49476&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49476&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49476&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49476&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49476&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49476&r=dst IIS Stability: http://bugs.php.net/fix.php?id=49476&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49476&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49476&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49476&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49476&r=mysqlcfg
#49476 [Opn]: $_ENV does not work
ID: 49476 User updated by: elmu 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: Sorry I wanted to say $_SERVER["SERVER_SIGNATURE"] works on both. Previous Comments: [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=49476&edit=1
#49267 [Com]: Linking fails for iconv: "Undefined symbols: _libiconv"
ID: 49267 Comment by: aoyagi dot kouhei at gmail dot com Reported By: s dot rost at ewerk dot com Status: Assigned Bug Type: Compile Failure Operating System: Mac OSX 10.6 Snow Leopard PHP Version: 5.3, 6 (2009-08-18) Assigned To: scottmac New Comment: Snow Leopard PHP5.3.1RC1 ./configure --prefix=/opt/php-5.3.1RC1 --enable-zip --with-apxs2=/opt/httpd/bin/apxs --with-bz2 --enable-calendar --with-curl --with-gd --enable-gd-native-ttf --enable-gd-jis-conv --enable-mbstring --with-pdo-pgsql=/opt/postgresql --with-pgsql=/opt/postgresql --enable-soap --enable-sockets --with-jpeg-dir=/opt/jpeg --with-png-dir=/opt/libpng --with-freetype-dir=/opt/freetype --with-zlib --with-libxml-dir=/opt/libxml2 --with-xsl=/opt/libxslt --with-readline=/opt/readline --with-gettext=/opt/gettext --with-iconv-dir=/opt/libiconv make Undefined symbols: "_libiconv_open", referenced from: _do_convert in gdkanji.o "_libiconv", referenced from: _do_convert in gdkanji.o __php_iconv_strlen in iconv.o _php_iconv_string in iconv.o _php_iconv_string in iconv.o __php_iconv_strpos in iconv.o __php_iconv_appendl in iconv.o __php_iconv_appendl in iconv.o _zif_iconv_substr in iconv.o _zif_iconv_mime_encode in iconv.o _zif_iconv_mime_encode in iconv.o _zif_iconv_mime_encode in iconv.o _zif_iconv_mime_encode in iconv.o _zif_iconv_mime_encode in iconv.o _zif_iconv_mime_encode in iconv.o _php_iconv_stream_filter_append_bucket in iconv.o _php_iconv_stream_filter_append_bucket in iconv.o "_libiconv_close", referenced from: _do_convert in gdkanji.o ld: symbol(s) not found collect2: ld returned 1 exit status make: *** [libs/libphp5.bundle] Error 1 Previous Comments: [2009-09-04 05:34:43] jay3ld at yahoo dot com Has any progress been made towards this with Snow Leopard? I am receiving the same issue with both PHP 5.3 and PHP 6. I don't get the above error. My error occurs during the configure stage. checking for iconv support... yes checking for iconv... no checking for libiconv... no checking for libiconv in -liconv... no checking for iconv in -liconv... no configure: error: Please reinstall the iconv library. I even tried to download and build a custom iconv library and pointed it with "--with-iconv-dir=/home/builds/iconv" and it still fails. [2009-08-15 16:30:35] scott...@php.net I'll look at the iconv issue once I get access to the snow leopard appleseed. I'd like to investigate a proper fix for this. [2009-08-15 16:27:05] s dot rost at ewerk dot com Right, the DNS stuff works in the snapshot (php5.3-200908151430) The precise linker error for iconv is: Undefined symbols: "_libiconv", referenced from: __php_iconv_strlen in iconv.o _php_iconv_string in iconv.o _php_iconv_string in iconv.o __php_iconv_strpos in iconv.o __php_iconv_appendl in iconv.o __php_iconv_appendl in iconv.o _zif_iconv_substr in iconv.o _zif_iconv_mime_encode in iconv.o _zif_iconv_mime_encode in iconv.o _zif_iconv_mime_encode in iconv.o _zif_iconv_mime_encode in iconv.o _zif_iconv_mime_encode in iconv.o _zif_iconv_mime_encode in iconv.o _php_iconv_stream_filter_append_bucket in iconv.o _php_iconv_stream_filter_append_bucket in iconv.o ld: symbol(s) not found collect2: ld returned 1 exit status make: *** [sapi/cgi/php-cgi] Error 1 [2009-08-15 15:26:39] scott...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ The DNS functions have been fixed in SVN already. The iconv stuff I've not looked at yet. [2009-08-15 13:54:11] s dot rost at ewerk dot com ext/iconv/iconv.c has to be changed to #ifdef HAVE_LIBICONV #define iconv iconv #endif Stupid copy/paste mistake. Also that does of course not really make sense, the #define is not needed at all. so probably the configure script should not detect LIBICONV in the first place, but plain iconv. 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/49267 -- Edit this bug report at http://bugs.php.net/?id=49267&edit=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=49477&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49477&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49477&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49477&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49477&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49477&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49477&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49477&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49477&r=needscript Try newer version: http://bugs.php.net/fix.php?id=49477&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49477&r=support Expected behavior: http://bugs.php.net/fix.php?id=49477&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49477&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49477&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49477&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49477&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49477&r=dst IIS Stability: http://bugs.php.net/fix.php?id=49477&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49477&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49477&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49477&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49477&r=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=49478&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49478&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49478&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49478&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49478&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49478&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49478&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49478&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49478&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49478&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49478&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49478&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49478&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49478&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49478&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49478&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49478&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49478&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49478&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49478&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49478&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49478&r=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=49479&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49479&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49479&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49479&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49479&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49479&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49479&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49479&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49479&r=needscript Try newer version: http://bugs.php.net/fix.php?id=49479&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49479&r=support Expected behavior: http://bugs.php.net/fix.php?id=49479&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49479&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49479&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49479&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49479&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49479&r=dst IIS Stability: http://bugs.php.net/fix.php?id=49479&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49479&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49479&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49479&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49479&r=mysqlcfg
#49267 [Com]: Linking fails for iconv: "Undefined symbols: _libiconv"
ID: 49267 Comment by: me at sleepycode dot com Reported By: s dot rost at ewerk dot com Status: Assigned Bug Type: Compile Failure Operating System: Mac OSX 10.6 Snow Leopard PHP Version: 5.3, 6 (2009-08-18) Assigned To: scottmac New Comment: I have the same issue as well with Snow Leopard and any version of PHP I try. I have built my own libiconv and this made little difference. My configure line: ./configure --prefix=/home/software/php/v5 \ --sysconfdir=/etc \ --localstatedir=/var \ --mandir=/usr/share/man \ --with-mysql=mysqlnd \ --with-mysqli=mysqlnd \ --with-pdo-mysql=mysqlnd \ --with-apxs2=/home/software/apache/bin/apxs \ --enable-maintainer-zts \ --with-zlib-dir=/home/software/zlib \ --with-pgsql=/home/software/postgresql \ --enable-mbstring \ --with-gd \ --with-png-dir=/home/software/libpng \ --with-iconv=/home/software/iconv The build error during make: Undefined symbols: "_libiconv_open", referenced from: _do_convert in gdkanji.o _php_iconv_string in iconv.o __php_iconv_strlen in iconv.o __php_iconv_substr in iconv.o __php_iconv_substr in iconv.o __php_iconv_strpos in iconv.o __php_iconv_mime_encode in iconv.o __php_iconv_mime_encode in iconv.o __php_iconv_mime_decode in iconv.o __php_iconv_mime_decode in iconv.o _php_iconv_stream_filter_ctor in iconv.o "_libiconv", referenced from: _do_convert in gdkanji.o "_libiconv_close", referenced from: _do_convert in gdkanji.o _php_iconv_string in iconv.o __php_iconv_strlen in iconv.o __php_iconv_substr in iconv.o __php_iconv_substr in iconv.o __php_iconv_strpos in iconv.o __php_iconv_mime_encode in iconv.o __php_iconv_mime_encode in iconv.o __php_iconv_mime_decode in iconv.o __php_iconv_mime_decode in iconv.o __php_iconv_mime_decode in iconv.o _php_iconv_stream_filter_dtor in iconv.o ld: symbol(s) not found collect2: ld returned 1 exit status make: *** [libs/libphp5.bundle] Error 1 Previous Comments: [2009-09-06 00:04:17] aoyagi dot kouhei at gmail dot com Snow Leopard PHP5.3.1RC1 ./configure --prefix=/opt/php-5.3.1RC1 --enable-zip --with-apxs2=/opt/httpd/bin/apxs --with-bz2 --enable-calendar --with-curl --with-gd --enable-gd-native-ttf --enable-gd-jis-conv --enable-mbstring --with-pdo-pgsql=/opt/postgresql --with-pgsql=/opt/postgresql --enable-soap --enable-sockets --with-jpeg-dir=/opt/jpeg --with-png-dir=/opt/libpng --with-freetype-dir=/opt/freetype --with-zlib --with-libxml-dir=/opt/libxml2 --with-xsl=/opt/libxslt --with-readline=/opt/readline --with-gettext=/opt/gettext --with-iconv-dir=/opt/libiconv make Undefined symbols: "_libiconv_open", referenced from: _do_convert in gdkanji.o "_libiconv", referenced from: _do_convert in gdkanji.o __php_iconv_strlen in iconv.o _php_iconv_string in iconv.o _php_iconv_string in iconv.o __php_iconv_strpos in iconv.o __php_iconv_appendl in iconv.o __php_iconv_appendl in iconv.o _zif_iconv_substr in iconv.o _zif_iconv_mime_encode in iconv.o _zif_iconv_mime_encode in iconv.o _zif_iconv_mime_encode in iconv.o _zif_iconv_mime_encode in iconv.o _zif_iconv_mime_encode in iconv.o _zif_iconv_mime_encode in iconv.o _php_iconv_stream_filter_append_bucket in iconv.o _php_iconv_stream_filter_append_bucket in iconv.o "_libiconv_close", referenced from: _do_convert in gdkanji.o ld: symbol(s) not found collect2: ld returned 1 exit status make: *** [libs/libphp5.bundle] Error 1 [2009-09-04 05:34:43] jay3ld at yahoo dot com Has any progress been made towards this with Snow Leopard? I am receiving the same issue with both PHP 5.3 and PHP 6. I don't get the above error. My error occurs during the configure stage. checking for iconv support... yes checking for iconv... no checking for libiconv... no checking for libiconv in -liconv... no checking for iconv in -liconv... no configure: error: Please reinstall the iconv library. I even tried to download and build a custom iconv library and pointed it with "--with-iconv-dir=/home/builds/iconv" and it still fails. [2009-08-15 16:30:35] scott...@php.net I'll look at the iconv issue once I get access to the snow leopard appleseed. I'd like to investigate a proper fix for this. [2009-08-15 16:27:05] s dot rost at ewerk dot com Right, the DNS stuff works in the snapshot (php5.3-200908151430) The precise linker error for iconv is: Undefined symbols: "_libiconv", referenced from: __php_iconv_strlen in iconv.o _php_iconv_stri
#49480 [NEW]: DateTime::createFromFormat uses current system time to fill missing fields
From: grodny at oneclick dot sk
Operating system:
PHP version: 5.3.0
PHP Bug Type: Date/time related
Bug description: DateTime::createFromFormat uses current system time to fill
missing fields
Description:
DateTime::createFromFormat uses current system time to fill missing fields
instead of zero values, which leads to inconsistent comparsions
and intervals returned by DateTime::diff.
DateTime::createFromFormat('Y-m-d', '2009-03-02') should always create
object(DateTime)#1 (3) {
["date"]=>
string(19) "2009-03-02 00:00:00"
...
}
Reproduce code:
---
Expected result:
bool(true)
Actual result:
--
bool(false)
--
Edit bug report at http://bugs.php.net/?id=49480&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49480&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49480&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49480&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49480&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49480&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49480&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49480&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49480&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49480&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49480&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49480&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49480&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49480&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49480&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49480&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49480&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49480&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49480&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49480&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49480&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49480&r=mysqlcfg
