[PHP-BUG] Req #51532 [NEW]: Cannot override SplFileObject::fscanf()
From:
Operating system: MS Windows Vista
PHP version: 5.3.2
Package: SPL related
Bug Type: Feature/Change Request
Bug description:Cannot override SplFileObject::fscanf()
Description:
There seems to be a problem with overriding SPLFileObject::fscanf() method.
I'm not sure whether this is PHP language-related issue or issue with
method definition in SPLFileObject.
When you look at 'splfileobject.inc' file from PHP 5.3.2 source code you
can see that method definition is:
function fscanf($format /* , ... */)
so it seems logical to assume only one parameter in overridden method.
However, using Reflection API to get fscanf parameters:
$class = new ReflectionClass('SPLFileObject');
$method = $class-getMethod('fscanf');
$params = $method-getParameters();
foreach ($params as $p)
{
echo $p-getName() . PHP_EOL;
}
Prints out:
format
...
Yes - '...' is literally printed out.
So it leaves me puzzled - either I am missing something very obvious or
fscanf is handling variable-length method arguments in some non-standard
way (like using func_get_args()).
All in all - overriding fscanf in a way like in specified example test
script results in strict standards notice.
Test script:
---
class SomeOtherFileObject extends SPLFileObject {
function fscanf($format) {
echo 'my little dummy';
}
}
$test = new SomeOtherFileObject('test.php');
$test-fscanf('%s');
Expected result:
The fscanf method is overridden without PHP notices, warnings and errors.
Actual result:
--
Strict standards: Declaration of SomeOtherFileObject::fscanf() should be
compatible with that of SplFileObject::fscanf()
--
Edit bug report at http://bugs.php.net/bug.php?id=51532edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51532r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51532r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51532r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51532r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51532r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51532r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51532r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51532r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51532r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51532r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51532r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51532r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51532r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51532r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51532r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51532r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51532r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51532r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51532r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51532r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51532r=mysqlcfg
[PHP-BUG] Bug #51533 [NEW]: [recursive reference In Array] Nesting level too deep
From:
Operating system: Linux
PHP version: 5.3.2
Package: Scripting Engine problem
Bug Type: Bug
Bug description:[recursive reference In Array] Nesting level too deep
Description:
When there is recursive reference in an array comparison yields Fatal
Error.
Both == and === operators yields the same.
//---
If It is not a Bug then Recursion Detection is IMPOSSIBLE in PHP.
cause spl_object_hash() doesn't work on array or scaler types.
Test script:
---
?php
error_reporting(255);
ini_set('display_errors','On');
header('Content-Type: text/plain');
$a = array();
$a[0] = $a;
var_dump($a === $a[0]);
var_dump($a == $a[0]);
?
Expected result:
boolean true or false
Actual result:
--
Fatal error: Nesting level too deep - recursive dependency? in
/Server/http/php-bugs/nesting.php on line 8
--
Edit bug report at http://bugs.php.net/bug.php?id=51533edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51533r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51533r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51533r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51533r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51533r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51533r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51533r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51533r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51533r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51533r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51533r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51533r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51533r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51533r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51533r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51533r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51533r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51533r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51533r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51533r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51533r=mysqlcfg
Bug #51533 [Opn]: [recursive reference In Array] Nesting level too deep
Edit report at http://bugs.php.net/bug.php?id=51533edit=1
ID: 51533
User updated by: neel dot basu dot z at gmail dot com
Reported by: neel dot basu dot z at gmail dot com
Summary: [recursive reference In Array] Nesting level too deep
Status: Open
Type: Bug
Package: Scripting Engine problem
Operating System: Linux
PHP Version: 5.3.2
New Comment:
**If It is not a Bug then Recursive Reference Detection is IMPOSSIBLE in
PHP.
cause spl_object_hash() doesn't work on array or scaler types.
Previous Comments:
[2010-04-11 19:35:59] neel dot basu dot z at gmail dot com
Description:
When there is recursive reference in an array comparison yields Fatal
Error.
Both == and === operators yields the same.
//---
If It is not a Bug then Recursion Detection is IMPOSSIBLE in PHP.
cause spl_object_hash() doesn't work on array or scaler types.
Test script:
---
?php
error_reporting(255);
ini_set('display_errors','On');
header('Content-Type: text/plain');
$a = array();
$a[0] = $a;
var_dump($a === $a[0]);
var_dump($a == $a[0]);
?
Expected result:
boolean true or false
Actual result:
--
Fatal error: Nesting level too deep - recursive dependency? in
/Server/http/php-bugs/nesting.php on line 8
--
Edit this bug report at http://bugs.php.net/bug.php?id=51533edit=1
[PHP-BUG] Bug #51534 [NEW]: DOMImplementation::createDocument() does not correctly append children
From:
Operating system: Fedora 12 GNU/Linux
PHP version: 5.3.2
Package: DOM XML related
Bug Type: Bug
Bug description:DOMImplementation::createDocument() does not correctly append
children
Description:
The product of DOMDocument::createDocument() appends children outside of
the qualified name of the document element (i.e. the root element).
I am using php-5.3.2-1.fc12.i686 and php-xml-5.3.2-1.fc12.i686 installed
using Yellowdog Updater, Modified Package Manager. All other DOM methods
tried so far work fine.
Test script:
---
?php
$implementation = new DOMImplementation();
$doctype = $implementation-createDocumentType('html');
$document = $implementation-createDocument('http://www.w3.org/1999/xhtml',
'html', $doctype);
$head = $document-createElement('head');
$document-appendChild($head);
echo $document-saveHTML();
Expected result:
!DOCTYPE html
html xmlns=http://www.w3.org/1999/xhtml;
head/head
/html
Actual result:
--
!DOCTYPE html
html xmlns=http://www.w3.org/1999/xhtml;/htmlhead/head
--
Edit bug report at http://bugs.php.net/bug.php?id=51534edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51534r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51534r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51534r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51534r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51534r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51534r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51534r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51534r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51534r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51534r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51534r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51534r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51534r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51534r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51534r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51534r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51534r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51534r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51534r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51534r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51534r=mysqlcfg
Bug #51534 [Opn]: DOMImplementation::createDocument() does not correctly append children
Edit report at http://bugs.php.net/bug.php?id=51534edit=1
ID: 51534
User updated by: jameswithers89 at googlemail dot com
Reported by: jameswithers89 at googlemail dot com
Summary: DOMImplementation::createDocument() does not correctly
append children
Status: Open
Type: Bug
Package: DOM XML related
Operating System: Fedora 12 GNU/Linux
PHP Version: 5.3.2
New Comment:
The following code also produces the same error:
?php
$implementation = new DOMImplementation();
$doctype = $implementation-createDocumentType('html');
// Don't create a root element...
$document = $implementation-createDocument(null, null, $doctype);
// ...instead create a html element and set the xmlns attribute:
$html = $document-createElement('html');
$html-setAttribute('xmlns', 'http://www.w3.org/1999/xhtml');
$document-appendChild($html);
$head = $document-createElement('head');
$document-appendChild($head);
echo $document-saveHTML();
Previous Comments:
[2010-04-11 19:40:38] jameswithers89 at googlemail dot com
Description:
The product of DOMDocument::createDocument() appends children outside of
the qualified name of the document element (i.e. the root element).
I am using php-5.3.2-1.fc12.i686 and php-xml-5.3.2-1.fc12.i686 installed
using Yellowdog Updater, Modified Package Manager. All other DOM methods
tried so far work fine.
Test script:
---
?php
$implementation = new DOMImplementation();
$doctype = $implementation-createDocumentType('html');
$document =
$implementation-createDocument('http://www.w3.org/1999/xhtml', 'html',
$doctype);
$head = $document-createElement('head');
$document-appendChild($head);
echo $document-saveHTML();
Expected result:
!DOCTYPE html
html xmlns=http://www.w3.org/1999/xhtml;
head/head
/html
Actual result:
--
!DOCTYPE html
html xmlns=http://www.w3.org/1999/xhtml;/htmlhead/head
--
Edit this bug report at http://bugs.php.net/bug.php?id=51534edit=1
Bug #48498 [Opn-Ver]: COM object instantiation throws 'Invalid Syntax' exception
Edit report at http://bugs.php.net/bug.php?id=48498edit=1
ID: 48498
Updated by: phi...@php.net
Reported by: will at flourishlib dot com
Summary: COM object instantiation throws 'Invalid Syntax'
exception
-Status: Open
+Status: Verified
Type: Bug
Package: COM related
Operating System: Windows XP SP3
PHP Version: 5.2.10RC1
New Comment:
Please let us know when Capicom is (or is not) available because I have
a fresh XP
install here, with a new PHP 5.3.2 install, and am also getting Failed
to create
COM object 'CAPICOM.Utilities.1': Invalid syntax
Previous Comments:
[2009-11-03 21:29:36] ksin...@php.net
I was able to use CapiCom.Utilities.1 with PHP 5.2.11. Error is
generated when capicom is not registered and class is not available on
the machine.
[2009-06-27 00:11:06] paul at mantisforge dot org
This functionality seems to work fine in the 5.3.0 rc builds ( PHP
5.3.0RC5-dev (cli) (built: Jun 27 2009 00:33:01) (DEBUG)).
The following script appears to work for me against most of the
capicom.utilities functions:
?php
try {
$util = new COM('CAPICOM.Utilities.1');
} catch (Exception $e) {
echo $e-getMessage() . \n;
echo 'exception initialising com object... terminating...';
}
$string = 'foo';
$encoded = $util-Base64Encode($string); /* encoded string is \r\n
terminated */
echo $encoded . ' is base 64 encoded string:' . $util-
Base64Decode($encoded) . \n;
echo \n\n;
$hex = $util-BinaryToHex($string);
echo BinaryToHex: . $util-BinaryToHex($string) . \n;
echo hextobinary: . $util-HexToBinary($hex) . \n;
define( 'CAPICOM_ENCODE_BASE64', 0 );
echo Random Number: . $util-GetRandom(10, CAPICOM_ENCODE_BASE64) .
\n;
$variant = $util-BinaryStringToByteArray($string);
$i = 0;
foreach( $variant as $v) {
echo Byte( . $i++ . ): . $v . \n;
}
Outputing:
ZgBvAG8A
is base 64 encoded string:foo
BinaryToHex: 66006F006F00
hextobinary: foo
Random Number: PiMSnPtckiHFCQ==
Byte(0): 102
Byte(1): 0
Byte(2): 111
Byte(3): 0
Byte(4): 111
Byte(5): 0
--
1) It might be worth trying a newer version of php
2) it might be worth checking that the com object is registered
correctly by attempting to access it from a vbscript
[2009-06-08 18:05:57] will at flourishlib dot com
Description:
In previous versions of PHP it was possible to create a COM object for
CAPICOM to generate random data. I'm not sure at what version it broke,
but now trying to instantiate the COM object, an exception is thrown
with the message Failed to create COM object 'CAPICOM.Utilities.1':
Invalid syntax.
This behavior seem to be present on both 5.2.9-2 and 5.2.10RC1.
I've been unable to figure out what this error really means. The ProgID
I'm specifying is valid according to Microsoft -
http://msdn.microsoft.com/en-us/library/aa388176(VS.85).aspx.
Any sort of direction would be useful in trying to solve this issue.
Reproduce code:
---
new COM('CAPICOM.Utilities.1');
Expected result:
A COM object that can be used.
Actual result:
--
An exception with the message:
Failed to create COM object 'CAPICOM.Utilities.1': Invalid syntax
--
Edit this bug report at http://bugs.php.net/bug.php?id=48498edit=1
[PHP-BUG] Req #51536 [NEW]: Add sapi binary location to php ini search path
From: ksingla Operating system: Windows PHP version: 5.2.13 Package: *Configuration Issues Bug Type: Feature/Change Request Bug description:Add sapi binary location to php ini search path Description: PHP searches php.ini in the binary location which is retrieved using GetModuleFileName (first parameter to GetModuleFileName is NULL). This will return path to current *executable* which won't be path to php sapi binary in case of dlls. For IIS, location of w3wp.exe which is %windir%\system32\inetsrv\ will be added to php ini search path. Is this intentional? Can we change this code to make it look for php.ini in the folder where php sapi binary is present? Without this fix, users running non-cgi SAPIs are required to set PHPRC environment variable or IniFilePath registry key to make PHP pick php.ini in the php install folder. If this bug is fixed, windows installer can stop setting PHPRC path to [installdir] and will be able to support side-by-side (SxS) install of PHP 5.2 and PHP 5.3. For installer to support SxS install, this change is required in PHP 5.2 and PHP 5.3. If we are worried about this being breaking change, we can just *add* php sapi binary location to php ini search path. -- Edit bug report at http://bugs.php.net/bug.php?id=51536edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51536r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51536r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51536r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51536r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51536r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51536r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51536r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51536r=needscript Try newer version: http://bugs.php.net/fix.php?id=51536r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51536r=support Expected behavior: http://bugs.php.net/fix.php?id=51536r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51536r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51536r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51536r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51536r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51536r=dst IIS Stability: http://bugs.php.net/fix.php?id=51536r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51536r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51536r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51536r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51536r=mysqlcfg
Bug #48498 [Ver-Bgs]: COM object instantiation throws 'Invalid Syntax' exception
Edit report at http://bugs.php.net/bug.php?id=48498edit=1
ID: 48498
Updated by: ka...@php.net
Reported by: will at flourishlib dot com
Summary: COM object instantiation throws 'Invalid Syntax'
exception
-Status: Verified
+Status: Bogus
Type: Bug
Package: COM related
Operating System: Windows XP SP3
PHP Version: 5.2.10RC1
New Comment:
This is indeed because CAPICOM.Utilities.1 isn't installed.
What you need to do is to:
1) Install CAPICOM from:
http://www.microsoft.com/downloads/details.aspx?FamilyId=860EE43A-A843-462F-ABB5-FF88EA5896F6displaylang=en
2) Register the DLL: regsvr32 capicom.dll (capicom.dll is located in the
installed folder in %ProgramFiles%)
Previous Comments:
[2010-04-12 00:01:54] phi...@php.net
Please let us know when Capicom is (or is not) available because I have
a fresh XP
install here, with a new PHP 5.3.2 install, and am also getting Failed
to create
COM object 'CAPICOM.Utilities.1': Invalid syntax
[2009-11-03 21:29:36] ksin...@php.net
I was able to use CapiCom.Utilities.1 with PHP 5.2.11. Error is
generated when capicom is not registered and class is not available on
the machine.
[2009-06-27 00:11:06] paul at mantisforge dot org
This functionality seems to work fine in the 5.3.0 rc builds ( PHP
5.3.0RC5-dev (cli) (built: Jun 27 2009 00:33:01) (DEBUG)).
The following script appears to work for me against most of the
capicom.utilities functions:
?php
try {
$util = new COM('CAPICOM.Utilities.1');
} catch (Exception $e) {
echo $e-getMessage() . \n;
echo 'exception initialising com object... terminating...';
}
$string = 'foo';
$encoded = $util-Base64Encode($string); /* encoded string is \r\n
terminated */
echo $encoded . ' is base 64 encoded string:' . $util-
Base64Decode($encoded) . \n;
echo \n\n;
$hex = $util-BinaryToHex($string);
echo BinaryToHex: . $util-BinaryToHex($string) . \n;
echo hextobinary: . $util-HexToBinary($hex) . \n;
define( 'CAPICOM_ENCODE_BASE64', 0 );
echo Random Number: . $util-GetRandom(10, CAPICOM_ENCODE_BASE64) .
\n;
$variant = $util-BinaryStringToByteArray($string);
$i = 0;
foreach( $variant as $v) {
echo Byte( . $i++ . ): . $v . \n;
}
Outputing:
ZgBvAG8A
is base 64 encoded string:foo
BinaryToHex: 66006F006F00
hextobinary: foo
Random Number: PiMSnPtckiHFCQ==
Byte(0): 102
Byte(1): 0
Byte(2): 111
Byte(3): 0
Byte(4): 111
Byte(5): 0
--
1) It might be worth trying a newer version of php
2) it might be worth checking that the com object is registered
correctly by attempting to access it from a vbscript
[2009-06-08 18:05:57] will at flourishlib dot com
Description:
In previous versions of PHP it was possible to create a COM object for
CAPICOM to generate random data. I'm not sure at what version it broke,
but now trying to instantiate the COM object, an exception is thrown
with the message Failed to create COM object 'CAPICOM.Utilities.1':
Invalid syntax.
This behavior seem to be present on both 5.2.9-2 and 5.2.10RC1.
I've been unable to figure out what this error really means. The ProgID
I'm specifying is valid according to Microsoft -
http://msdn.microsoft.com/en-us/library/aa388176(VS.85).aspx.
Any sort of direction would be useful in trying to solve this issue.
Reproduce code:
---
new COM('CAPICOM.Utilities.1');
Expected result:
A COM object that can be used.
Actual result:
--
An exception with the message:
Failed to create COM object 'CAPICOM.Utilities.1': Invalid syntax
--
Edit this bug report at http://bugs.php.net/bug.php?id=48498edit=1
Bug #51205 [Opn-Fbk]: Fatal error: com_exception: The parameter is incorrect
Edit report at http://bugs.php.net/bug.php?id=51205edit=1 ID: 51205 Updated by: ka...@php.net Reported by: zelnaga at gmail dot com Summary: Fatal error: com_exception: The parameter is incorrect -Status: Open +Status: Feedback Type: Bug Package: COM related Operating System: Windows XP PHP Version: 5.3.1 New Comment: You cannot use VT_ARRAY as the only type sent to VARIANT's ctor. VT_ARRAY is a flag that needs to be OR'd with another type, e.g.: $variant = new VARIANT($..., VT_UI1 | VT_ARRAY); Previous Comments: [2010-03-26 18:47:12] zelnaga at gmail dot com the $rng-GetBytes($v); line. [2010-03-15 15:27:30] ka...@php.net In what line does this happen? [2010-03-04 22:31:57] zelnaga at gmail dot com Description: Hi, I need to use RNGCryptoServiceProvider in PHP. I have tried: $rng = new DOTNET(mscorlib, System.Security.Cryptography.RNGCryptoServiceProvider); $arr = array(0); $v = new VARIANT($arr,VT_ARRAY); $rng-GetBytes($v); unset($rng); The component loads fine. But I got this error: Fatal error: Uncaught exception 'com_exception' with message 'Error [0x80070057] The parameter is incorrect. Any ideas? -- Edit this bug report at http://bugs.php.net/bug.php?id=51205edit=1
Req #46709 [Opn-Csd]: When no include_path is set in php.ini, it defaults to .;C:\php5\pear
Edit report at http://bugs.php.net/bug.php?id=46709edit=1 ID: 46709 Updated by: paj...@php.net Reported by: peaceable_whale at hotmail dot com Summary: When no include_path is set in php.ini, it defaults to .;C:\php5\pear -Status: Open +Status: Closed Type: Feature/Change Request -Package: Feature/Change Request +Package: *General Issues Operating System: Windows PHP Version: 5.2.7 -Assigned To: +Assigned To: pajoye New Comment: It is now set to .;c:\php\include which should exists when installed correctly (windows or linux) Previous Comments: [2008-12-07 04:50:54] peaceable_whale at hotmail dot com Affecting PHP 5.2.7. [2008-11-28 14:49:35] peaceable_whale at hotmail dot com Correction: Corrected OS to Windows [2008-11-28 14:48:18] peaceable_whale at hotmail dot com Description: When no include_path is set in php.ini, it defaults to .;C:\php5\pear, a path that may not exist. I think . is enough. This bug is intended to replace Bug #29085. Reproduce code: --- Install PHP with the Windows Installer and does not set an include_path manually. Then run phpinfo(). Expected result: include_path should be . Actual result: -- include_path is .;C:\php5\pear -- Edit this bug report at http://bugs.php.net/bug.php?id=46709edit=1
Req #41062 [Opn-Asn]: is_executable only looks at basic executables
Edit report at http://bugs.php.net/bug.php?id=41062edit=1 ID: 41062 Updated by: paj...@php.net Reported by: rquadl...@php.net Summary: is_executable only looks at basic executables -Status: Open +Status: Assigned Type: Feature/Change Request -Package: Feature/Change Request +Package: *General Issues Operating System: Windows XP SP2 PHP Version: 5CVS-2007-04-12 (snap) -Assigned To: +Assigned To: pajoye Previous Comments: [2007-04-12 14:07:55] rquadl...@php.net Description: For Windows, the is_executable() function only checks the file extensions of exe, com, bat and cmd. This is incomplete. Within Windows, there is an environment variable called PATHEXT. This contains a list of extensions which are executable. If you type a program whose extension is in this list and the program with that extension is in the path, then it is executed. You can easily add .PHP to this list (see UserNote http://www.php.net/manual/en/features.commandline.php#53252). This is completely normal behaviour on windows. Using the FileTypes mechanism allows any type of file to have an automatic handler (double click a PDF file and Acrobat loads with that file). By also adding the extension to the PATHEXT environment variable you can type just the name at the CLI and the lovely windows magic happens automagically. The standard list of executable types within windows XP is: PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH Mine is: PATHEXT=.COM;.EXE;.BAT;.CMD;.PHP;.PYC;.PY; I don't deal with MS VB scripts, but I do deal with PHP and Python! All of these are executable (i.e. the behaviour of an abc.php is the same as an abc.bat or an abc.exe). Admittedly this is only on windows, but the current method should either be documented as only being of limited use on Windows (with the 4 types) or be extended to look at the Windows mechanism (just like I assume the *ix version looks at an executable bit on the permissions?). The following is a screen grab to prove the point. 12/04/2007 15:02:28 C:\type d:\PHP Quickies\isexec.php ?php echo $argv[0], ' is ', (is_executable($argv[0]) ? '' : 'not '), 'executable'; ? 12/04/2007 15:02:34 C:\set path Path=C:\Batch;C:\PHP5;D:\PHP Quickies;C:\Program Files\Windows Resource Kits\Tools;C:\Python\Lib;C:\Program Files\WinRAR;D:\Sage\UTILS;c:\program files\imagemagick;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program Files\Universal Extractor\bin;C:\Program Files\Microsoft SQL Server\80\Tools\BINN;C:\Program Files\Nmap;D:\Cygwin\bin; PATHEXT=.COM;.EXE;.BAT;.CMD;.PHP;.PYC;.PY;.VBS;.VBE;.JS;.JSE;.WSF;.WSH 12/04/2007 15:02:37 C:\isexec D:\PHP Quickies\isexec.php is not executable Reproduce code: --- ?php echo is_executable($argv[0]) ? 'Executable' : 'Not executable'; ? Expected result: D:\PHP Quickies\isexec.php is executable Actual result: -- D:\PHP Quickies\isexec.php is not executable -- Edit this bug report at http://bugs.php.net/bug.php?id=41062edit=1
Req #20196 [Opn-Csd]: PEAR in include_path
Edit report at http://bugs.php.net/bug.php?id=20196edit=1 ID: 20196 Updated by: paj...@php.net Reported by: anoland at bigfoot dot com Summary: PEAR in include_path -Status: Open +Status: Closed Type: Feature/Change Request -Package: Feature/Change Request +Package: *General Issues Operating System: Win2K PHP Version: 4.3.0-pre2 -Assigned To: +Assigned To: pajoye Previous Comments: [2002-10-31 11:34:17] anoland at bigfoot dot com RE: bug 19698. I am requesting that the default path of c:\php4\pear be removed from the code. By having this hardcoded you are making several assumptions about my dev and production environment. Assumptions that aren't necessarly true. -- Edit this bug report at http://bugs.php.net/bug.php?id=20196edit=1
Req #15367 [Opn-Wfx]: open_basedir = ~ (cgi mode)
Edit report at http://bugs.php.net/bug.php?id=15367edit=1 ID: 15367 Updated by: paj...@php.net Reported by: akapoli at x3 dot hu Summary: open_basedir = ~ (cgi mode) -Status: Open +Status: Wont fix Type: Feature/Change Request -Package: Feature/Change Request +Package: *General Issues Operating System: Linux PHP Version: 4.0.6 New Comment: ~ is shell specific and is by no mean a valid path. Previous Comments: [2002-02-04 09:13:48] akapoli at x3 dot hu It would be so nice to set the open_basedir in php.ini to the current user's home directory: open_basedir = ~ We are hosting several virtual sites. They run php whith their own UID (Apache suexec - php in cgi mode). We have to lock them to safe place: their home dir. Now this option is not available so we set open_basedir = ., but this makes difficulties in case of sophisticated applications, where the application is divided into directories, and the backward opens are needed ( ex. include(../includes/lib.inc) ). -- Edit this bug report at http://bugs.php.net/bug.php?id=15367edit=1
Req #13810 [Opn-Csd]: Per directory php.ini overrides
Edit report at http://bugs.php.net/bug.php?id=13810edit=1 ID: 13810 Updated by: paj...@php.net Reported by: richard at alavator dot com Summary: Per directory php.ini overrides -Status: Open +Status: Closed Type: Feature/Change Request -Package: Feature/Change Request +Package: *General Issues Operating System: All PHP Version: 4.0.6 -Assigned To: +Assigned To: pajoye New Comment: 5.3+ has this feature for FCGI. pecl.php.net/htscanner allows that for 5.2. Previous Comments: [2001-10-24 23:19:42] richard at alavator dot com I tried writing wrappers for PHP that called it with -d OPTION, and -s to show source, and then creating an apache Action in the .htaccess file, but this did now work, as PHP ignores the command line parameters when invoked as a CGI. Another suitable workaround would be at have PHP pay attention to CERTAIN command line parameters (such as -d and -s) but refuse to process files specified on the command line, and only allow the adjustment of certain options. [2001-10-24 05:24:45] richard at alavator dot com I run a server and have always used .htaccess to modify php settings on a per directory basis. I am now opening my server to other people, so I need to refine the security model, which prevents me from using PHP as a module. Unfortunately, I can't use PHP as a CGI at this time, because I have no way of changing options on a per directory basis. I would be nice if PHP could be compiled with an option which would have it perform the following actions each time it is invoked as a CGI: 1. Parse the normal configuration file 2. Look in each directory from the document root to the script directory, and progressively parse php.ini files in those directories overriding any settings from the main php.ini file (but not otherwise disturbing the php configuration) This is probably a fairly intensive hit for memory hungry machines, but AFAIK, it is the only way to provide per-directory PHP options in a similar mannar to .htaccess on servers which don't have .htaccess, or where security makes using .htaccess impossible. -- Edit this bug report at http://bugs.php.net/bug.php?id=13810edit=1
Bug #48498 [Bgs]: COM object instantiation throws 'Invalid Syntax' exception
Edit report at http://bugs.php.net/bug.php?id=48498edit=1
ID: 48498
User updated by: will at flourishlib dot com
Reported by: will at flourishlib dot com
Summary: COM object instantiation throws 'Invalid Syntax'
exception
Status: Bogus
Type: Bug
Package: COM related
Operating System: Windows XP SP3
PHP Version: 5.2.10RC1
New Comment:
Thanks for the replies/help on this. Is it possible to improve the error
message
so it says the COM object is Not found instead of Invalid syntax?
I understand if this is outside the control of PHP.
Previous Comments:
[2010-04-12 01:30:05] ka...@php.net
This is indeed because CAPICOM.Utilities.1 isn't installed.
What you need to do is to:
1) Install CAPICOM from:
http://www.microsoft.com/downloads/details.aspx?FamilyId=860EE43A-A843-462F-ABB5-FF88EA5896F6displaylang=en
2) Register the DLL: regsvr32 capicom.dll (capicom.dll is located in the
installed folder in %ProgramFiles%)
[2010-04-12 00:01:54] phi...@php.net
Please let us know when Capicom is (or is not) available because I have
a fresh XP
install here, with a new PHP 5.3.2 install, and am also getting Failed
to create
COM object 'CAPICOM.Utilities.1': Invalid syntax
[2009-11-03 21:29:36] ksin...@php.net
I was able to use CapiCom.Utilities.1 with PHP 5.2.11. Error is
generated when capicom is not registered and class is not available on
the machine.
[2009-06-27 00:11:06] paul at mantisforge dot org
This functionality seems to work fine in the 5.3.0 rc builds ( PHP
5.3.0RC5-dev (cli) (built: Jun 27 2009 00:33:01) (DEBUG)).
The following script appears to work for me against most of the
capicom.utilities functions:
?php
try {
$util = new COM('CAPICOM.Utilities.1');
} catch (Exception $e) {
echo $e-getMessage() . \n;
echo 'exception initialising com object... terminating...';
}
$string = 'foo';
$encoded = $util-Base64Encode($string); /* encoded string is \r\n
terminated */
echo $encoded . ' is base 64 encoded string:' . $util-
Base64Decode($encoded) . \n;
echo \n\n;
$hex = $util-BinaryToHex($string);
echo BinaryToHex: . $util-BinaryToHex($string) . \n;
echo hextobinary: . $util-HexToBinary($hex) . \n;
define( 'CAPICOM_ENCODE_BASE64', 0 );
echo Random Number: . $util-GetRandom(10, CAPICOM_ENCODE_BASE64) .
\n;
$variant = $util-BinaryStringToByteArray($string);
$i = 0;
foreach( $variant as $v) {
echo Byte( . $i++ . ): . $v . \n;
}
Outputing:
ZgBvAG8A
is base 64 encoded string:foo
BinaryToHex: 66006F006F00
hextobinary: foo
Random Number: PiMSnPtckiHFCQ==
Byte(0): 102
Byte(1): 0
Byte(2): 111
Byte(3): 0
Byte(4): 111
Byte(5): 0
--
1) It might be worth trying a newer version of php
2) it might be worth checking that the com object is registered
correctly by attempting to access it from a vbscript
[2009-06-08 18:05:57] will at flourishlib dot com
Description:
In previous versions of PHP it was possible to create a COM object for
CAPICOM to generate random data. I'm not sure at what version it broke,
but now trying to instantiate the COM object, an exception is thrown
with the message Failed to create COM object 'CAPICOM.Utilities.1':
Invalid syntax.
This behavior seem to be present on both 5.2.9-2 and 5.2.10RC1.
I've been unable to figure out what this error really means. The ProgID
I'm specifying is valid according to Microsoft -
http://msdn.microsoft.com/en-us/library/aa388176(VS.85).aspx.
Any sort of direction would be useful in trying to solve this issue.
Reproduce code:
---
new COM('CAPICOM.Utilities.1');
Expected result:
A COM object that can be used.
Actual result:
--
An exception with the message:
Failed to create COM object 'CAPICOM.Utilities.1': Invalid syntax
--
Edit this bug report at http://bugs.php.net/bug.php?id=48498edit=1
Bug #33685 [Com]: configure: error: libjpeg.(a|so) not found.
Edit report at http://bugs.php.net/bug.php?id=33685edit=1 ID: 33685 Comment by: aneeshknlr at gmail dot com Reported by: matt at azoogleads dot com Summary: configure: error: libjpeg.(a|so) not found. Status: Wont fix Type: Bug Package: PHP options/info functions Operating System: RHEL 4 ES/x86_64 PHP Version: 4.4.0 New Comment: Easy Workaround.. # ln -s /usr/lib64/libjpeg.so /usr/lib/ # ln -s /usr/lib64/libpng.so /usr/lib/ Previous Comments: [2005-07-14 17:02:03] matt at azoogleads dot com Please disregard my last post, all is fine. I didn't have the freetype-devel package installed ;-) [2005-07-14 16:06:10] matt at azoogleads dot com I created the symlinks you mentioned which got around the libjpeg issue (thanks!), only to run into the error configure: error: freetype2 not found! I've tried using --with-freetype-dir=/opt, --with-freetype-dir=/usr and --with-freetype-dir without any luck. Am I going to run into trouble if I run PHP 4.4.0 under 64-bit Linux? [2005-07-14 01:18:27] sni...@php.net I didn't notice the x86_64 there. This bug is fixed in PHP 5.1 (current CVS HEAD). It will not be fixed in PHP 4. Workaround: # ln -s /usr/include /opt/include # ln -s /usr/lib64 /opt/lib And use these options and values for them: --with-mysql=/opt --with-jpeg-dir=/opt --with-png-dir=/opt [2005-07-13 23:08:24] matt at azoogleads dot com I wasn't able to make out anything obvious in the config.log file (searching for any reference to 'jpeg'). Here's a copy of config.log for your reference: http://ca.geocities.com/msiem...@rogers.com/config.log [2005-07-13 22:45:45] sni...@php.net Check the config.log for the real reason why the check failed. Configure outputs 'checking for the location of libjpeg... yes' because you have '--with-jpeg-dir', not that it found 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/bug.php?id=33685 -- Edit this bug report at http://bugs.php.net/bug.php?id=33685edit=1
