#47878 [NEW]: ScriptControl function capitalization discrepancy
From: csaba at alum dot mit dot edu
Operating system: Win XP Pro
PHP version: 5.3.0RC1
PHP Bug Type: COM related
Bug description: ScriptControl function capitalization discrepancy
Description:
It is possible to call a PHP function in a class that has been stuffed
into a ScriptControl using the code below. However, the name of the
function must be given as lower case, which is probably not the intent.
This is especially odd when the original function's name contains capital
letters.
Reproduce code:
---
http://bugs.php.net/bug.php?id=33386
class twoFuncs {
public function Func1() { echo " func one\n"; }
public function func2() { echo " func two\n"; } }
$clsInstTF = new twoFuncs; // class instance
$oScript = new COM("MSScriptControl.ScriptControl");
$oScript->Language = "VBScript";
$oScript->AddObject ("tF", $clsInstTF, true);
$clsInstTF->func1();// OK
$clsInstTF->Func1();// OK
$oScript->ExecuteStatement ("tF.func1");// OK
$oScript->ExecuteStatement ("tf.func1");// OK
$oScript->ExecuteStatement ("tF.Func1");// Error
?>
Expected result:
I expect so see " func one" repeated on five consecutive lines
Actual result:
--
" func one" is repeated four times, and on the 5th attempt an error
results:
Object doesn't support this property or method: 'tF.Func1'
My guess is that what is happening is that when the function name is being
matched, the actual function name is being lower cased while the function
name being sought is not being lower cased. Note that class instance in
the VBScript script control is matched regardless of capitalization.
In contrast, if the language line is changed to:
$oScript->Language = "VBScript";
then 4th test line (tf.func1) should be commented out because JScript is
case sensitive there. But after that commenting out, the last line still
errors.
This bug is similar to, but distinct from, bug 33386
Csaba Gabor from Vienna
--
Edit bug report at http://bugs.php.net/?id=47878&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47878&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47878&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47878&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47878&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47878&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47878&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47878&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47878&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47878&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47878&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47878&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47878&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47878&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47878&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47878&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47878&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47878&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47878&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47878&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47878&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47878&r=mysqlcfg
#42551 [Asn]: new COM("HTMLFile") => warnings
ID: 42551
User updated by: csaba at alum dot mit dot edu
Reported By: csaba at alum dot mit dot edu
Status: Assigned
Bug Type: COM related
Operating System: Win XP Pro
PHP Version: 5.2.4
Assigned To: wharmby
New Comment:
There is another variant of this which crops up from time to time (I am
using version 5.2.6). Unfortunately, I cannot detect any pattern in
when it happens. It only happens with low frequency (around 2 percent
of the time), but when it happens my screen is filled with 31 error
warnings. The following line
$oFSO = new COM("Scripting.FileSystemObject");
will (sometimes) cause 31 warnings of the following type:
Warning: com::com(): Type library constant BinaryCompare is already
defined in C:\phpScripts\myScript.php on line 32
The specific list of constants it complains about is:
BinaryCompare TextCompare DatabaseCompare ForReading ForWriting
ForAppending TristateTrue TristateFalse TristateUseDefault TristateMixed
Normal ReadOnly Hidden System Volume Directory Archive Alias Compressed
UnknownType Removable Fixed Remote CDRom RamDisk WindowsFolder
SystemFolder TemporaryFolder StdIn StdOut StdErr
This has even happened when the script was the very first thing that I
ran after a reboot.
In any case, I would expect that if the value of the constants is the
same, then I not get the complaint.
Previous Comments:
[2007-09-05 12:44:45] j...@php.net
Assigned to the maintainer.
[2007-09-04 21:13:55] csaba at alum dot mit dot edu
Description:
When I attempt to do
$doc = new COM("HTMLFile");
this results in warnings that Type Library constants True and False are
already defined. Otherwise, the script runs fine.
The equivalent code as a .vbs file runs wihtout complaints
Csaba Gabor from Vienna
Reproduce code:
---
parentWindow;
print ($doc->location . "\n");
$win->ExecScript(
"window.keepLooping=true");
$win->setTimeout (
"alert('timeout works');
window.keepLooping=false;", 2000);
while ($win->keepLooping)
com_message_pump(200);
print ("Done Looping");
?>
Expected result:
The only thing I expect to see printed is:
about:blank
Done Looping
Actual result:
--
Warning: com::com(): Type library constant True is already defined in
C:\test2.php on line 2
Warning: com::com(): Type library constant False is already defined in
C:\test2.php on line 2
about:blank
Done Looping
--
Edit this bug report at http://bugs.php.net/?id=42551&edit=1
#44071 [Fbk->Opn]: realpath does not handle drive letters correctly
ID: 44071
User updated by: csaba at alum dot mit dot edu
Reported By: csaba at alum dot mit dot edu
-Status: Feedback
+Status: Open
Bug Type: Filesystem function related
Operating System: Windows
PHP Version: 5.2.5
New Comment:
It's still a problem. On my Win XP Pro, with
PHP 5.2.6-dev (cli) (built: Feb 13 2008 12:05:17)
php -r "var_dump(array(getcwd(),realpath('c:')));"
produced:
array(2) {
[0]=>
string(18) "C:\Winapps\PHP.net"
[1]=>
string(3) "C:\"
}
The second string is wrong - it should
have been the same as the first.
Previous Comments:
[2008-02-13 18:47:03] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows (zip):
http://snaps.php.net/win32/php5.2-win32-latest.zip
For Windows (installer):
http://snaps.php.net/win32/php5.2-win32-installer-latest.msi
--------------------
[2008-02-08 02:08:29] csaba at alum dot mit dot edu
is_file and is_dir seem to be similarly affected.
For example realpath("c:frump") will return false if
c:\frump does not exist (note the extra backslash),
whereas it should be checking for frump hanging off
the current directory on the c: drive
------------------------
[2008-02-07 16:26:22] csaba at alum dot mit dot edu
Description:
realpath does not handle a drive letters correctly, when the
drive letter is not followed by a backslash:
1) When books is a subdirectory of the current working directory on
the c: drive (getcwd) realpath("c:books") returns false
2) realpath("c:.") and realpath("c:..") both return the three
character string: C:\
Expected result:
1. books\ should be suffixed onto the current working directory of the
c: drive
2. The current working directory of the c: drive (and one level higher
for the case of ..) should be returned, instead of the root.
Csaba Gabor from Vienna
--
Edit this bug report at http://bugs.php.net/?id=44071&edit=1
#44071 [Opn]: realpath does not handle drive letters correctly
ID: 44071
User updated by: csaba at alum dot mit dot edu
Reported By: csaba at alum dot mit dot edu
Status: Open
Bug Type: Filesystem function related
-Operating System: Win XP
+Operating System: Windows
PHP Version: 5.2.5
New Comment:
is_file and is_dir seem to be similarly affected.
For example realpath("c:frump") will return false if
c:\frump does not exist (note the extra backslash),
whereas it should be checking for frump hanging off
the current directory on the c: drive
Previous Comments:
[2008-02-07 16:26:22] csaba at alum dot mit dot edu
Description:
realpath does not handle a drive letters correctly, when the
drive letter is not followed by a backslash:
1) When books is a subdirectory of the current working directory on
the c: drive (getcwd) realpath("c:books") returns false
2) realpath("c:.") and realpath("c:..") both return the three
character string: C:\
Expected result:
1. books\ should be suffixed onto the current working directory of the
c: drive
2. The current working directory of the c: drive (and one level higher
for the case of ..) should be returned, instead of the root.
Csaba Gabor from Vienna
--
Edit this bug report at http://bugs.php.net/?id=44071&edit=1
#44071 [NEW]: realpath does not handle drive letters correctly
From: csaba at alum dot mit dot edu
Operating system: Win XP
PHP version: 5.2.5
PHP Bug Type: Filesystem function related
Bug description: realpath does not handle drive letters correctly
Description:
realpath does not handle a drive letters correctly, when the
drive letter is not followed by a backslash:
1) When books is a subdirectory of the current working directory on the
c: drive (getcwd) realpath("c:books") returns false
2) realpath("c:.") and realpath("c:..") both return the three character
string: C:\
Expected result:
1. books\ should be suffixed onto the current working directory of the c:
drive
2. The current working directory of the c: drive (and one level higher
for the case of ..) should be returned, instead of the root.
Csaba Gabor from Vienna
--
Edit bug report at http://bugs.php.net/?id=44071&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=44071&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=44071&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=44071&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=44071&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44071&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=44071&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=44071&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44071&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44071&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=44071&r=support
Expected behavior:http://bugs.php.net/fix.php?id=44071&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=44071&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=44071&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44071&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=44071&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=44071&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44071&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=44071&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=44071&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=44071&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44071&r=mysqlcfg
#43897 [NEW]: $ie not cleared on IE quit
From: csaba at alum dot mit dot edu
Operating system: Win XP Pro
PHP version: 5.2.5
PHP Bug Type: COM related
Bug description: $ie not cleared on IE quit
Description:
In the code below, if the visible IE is closed, whether by script or by
the user, the bug manifests itself. What will happen is that there will be
a sequence of (ReadyState) 4's displayed while IE is extant. When IE is
closed, "Exiting" should be printed, but what happens is that a sequence of
ReadyState=0's is printed, which is a bug.
The bug only happens if there are no instances of IE when the script is
run.
The second instance of $ie has to be 'static'
Csaba Gabor from Vienna
Reproduce code:
---
visible = true;
$ie->Navigate2 ("about:blank");
$ie2 = new COM("InternetExplorer.Application");
try { while ($ie->ReadyState>=0) {
print $ie->ReadyState;
com_message_pump(200); } }
catch (com_exception $e) {}
print "Exiting";
?>
Expected result:
I expect to see a sequence of 4s until I close IE, and then I expect to
see Exiting printed
Actual result:
--
A sequence of 4s is printed, but when I close IE a sequence of 0s is
printed which doesn't terminate till I use the windows task manager
(ctrl+alt+delete) to kill the iexplore process. (One could also use ctrl+C
in the Cmd window, but that leaves a hidden IE instance, so the bug won't
show itself next time around, until the IE is removed).
The bug manifests itself without user actions if
$ie->Quit();
is inserted right above the 'try' line
If there is already an instance of IE in existence, then the bug does not
happen.
The bug will also show itself if the '$ie2' line is replaced with:
ieStatic();
function ieStatic() {
static $ie;
$ie = new COM("InternetExplorer.Application"); }
--
Edit bug report at http://bugs.php.net/?id=43897&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=43897&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=43897&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=43897&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=43897&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=43897&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=43897&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=43897&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=43897&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=43897&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=43897&r=support
Expected behavior:http://bugs.php.net/fix.php?id=43897&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=43897&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=43897&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=43897&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43897&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=43897&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=43897&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=43897&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=43897&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=43897&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=43897&r=mysqlcfg
#43838 [NEW]: variant_set with IE leads to hang
From: csaba at alum dot mit dot edu
Operating system: Win XP Pro
PHP version: 5.2.5
PHP Bug Type: COM related
Bug description: variant_set with IE leads to hang
Description:
If an event sink is set on IE, and then a new window is created by that IE
(by clicking on a link with target=_blank, say), then NewWindow2 fires. By
replacing the first argument to NewWindow2 (via set_variant) it is possible
to identify the pending new ie and to assign a sink, $sink2, to it).
The problem is that the $sink2->ie is somehow corrupted to such an extent
that trying to access anything on it hangs ie badly.
There is a 2nd less severe but still significant problem: If the bug
causing 2 lines just above the print "\n"; in BeforeNavigate2 are commented
out, then the PHP code will terminate if either instance of IE is closed.
However, there is also an error genereated at the same time (the specific
error varies, but I suspect that it has to do with cleanup of the COM
objects).
Reproduce code:
---
" .
"Goog";
$ie = new COM("InternetExplorer.Application");
sink_ie($ie);
$ie->visible = true;
$ie->Navigate2("about:blank");
while ($ie->ReadyState<4) com_message_pump(200);
$ie->Navigate2("javascript:\"$newIEpage\"");
$ie->document->title = "variant_set Launcher";
$keepLooping = true;
while ($keepLooping) com_message_pump(200);
print "Exiting";
class mysink {
public $ie = null; // reqd for evt sink to function
function __construct($ie) { $this->ie = $ie; }
public function BeforeNavigate2 (
$ie, $url, $flags, $targetFrameName,
$postData, $headers, &$cancel) {
print __FUNCTION__ . ": " . typename($ie) . ", ";
print $ie->hwnd . ", rs: " . $ie->ReadyState;
print "; " . $url . "\n";
global $aES;
print " Sink count: " . sizeof($aES);
print ", this->ie: ";
print typename($this->ie) . ", "; // produces bug
print $this->ie->hwnd; // produces bug
print "\n";
}
public function NewWindow2 (&$newIe, $cancel) {
$ie = new COM("InternetExplorer.Application");
print "NewWindow2: ";
variant_set($newIe, $ie);
$sink2 = sink_ie($ie);
print $sink2->ie->hwnd . "\n";
}
public function DownloadComplete() {
print __FUNCTION__ . "\n"; }
public function DocumentComplete($dom, $url) {
print __FUNCTION__ . ": $url\n"; }
public function onQuit() { print "Quitting\n";
$GLOBALS['keepLooping'] = false; }
}
function typename($objCOM) {
// similar to typename in vbscript
if (empty($objCOM)) return "no COM object";
if (gettype($objCOM)!="object")
return "not a COM object";
ob_start();
com_print_typeinfo($objCOM);
$typeInfo = ob_get_contents();
ob_end_clean();
$pattern = "/^\\s*class (.*) \\{/";
if (!($matchCnt = preg_match($pattern,
$typeInfo, $aMatch)))
return "Not found";
return "COM:" . $aMatch[1];
}
function sink_ie($ie) {
// sink $ie, and add to global array of sinks
global $aES;
com_event_sink ($ie, $aES[] = $sink =
new mysink($ie),
"DWebBrowserEvents2");
return $sink;
}
?>
Expected result:
This is PHP CLI code. When run from the cmd prompt, I expect two
instances of IE to come up (they do), and for the cmd prompt to display the
navigation progress.
Now I could see that $sink2->ie becomes obsolete somehow (even though its
hwnd is the same as the hwnd that comes into BeforeNavigate2), but what
seems really wrong is to get a hang upon trying to do anything with that
variable in BeforeNavigate2 (either $this->ie or $aES[sizeof($aES)-1]->ie)
Actual result:
--
If the included script is run as is, then typename($this->ie) causes a
hang. If it is commented out, $this->ie->hwnd causes a hang. If both of
these statements (the two lines before the last print statement in
BeforeNavigate2) are commented out, then both IE pages will load OK (ie.
the main bug goes away), and there will only be issues when the php code
shuts down on account of one of the two IE's being closed.
A note about the code: While it may appear somewhat convoluted, the point
of the original code was to track navigation progress within ie, and this
works fine. However, when (simulated) clicking on a link causes the
browser to open a new window, then navigation tracking must continue with a
new ie, and the way to get ahold of that ie is with the NewWindow2 or
NewWindow3 event, and I used the former.
Two things need to happen in NewWindow2. The first is that the first
argument to the event handler needs to be set to an unini
#43624 [NEW]: fmod($a,$b) wrong when $b is a multiple of $a - continued
From: csaba at alum dot mit dot edu Operating system: Win XP PHP version: 5.2.5 PHP Bug Type: Math related Bug description: fmod($a,$b) wrong when $b is a multiple of $a - continued Description: This continues bug report 43572 at http://bugs.php.net/bug.php?id=43572&edit=2 which discussion is incomplete, yet has been prematurely closed. > The value that you expect (0) is obtained using float precision. > (In C) PHP uses double, and with this type fmod() returns 1.3. So, to be concrete: $a = 6.5; print gettype($a); // double $b = 1.3; print gettype($b); // double $c = $a / $b; print gettype($c); // double $d = 5.0; print gettype ($d); // double print $c - $d; // 0 print (gettype($c - $d)); // double print ($c===$d) ? "same" : "different"; // same print gettype ($b - fmod($a, $b)); // double print $b - fmod($a, $b); // 2.22044604925E-16 In other words, PHP's own (double) math shows that 6.5 / 1.3 === 5.0 Regardless of the internal representation and precision of 6.5 and 1.3, division of the former ($a) by the latter ($b) results in a double value identical to 5.0. fMod should return 0 in this situation. Csaba Gabor from New York PS. I would prefer that these comments be moved to bug 43572 and that it be reopened until the discussion is completed, rather than having multiple threads. -- Edit bug report at http://bugs.php.net/?id=43624&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=43624&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=43624&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=43624&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=43624&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=43624&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=43624&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=43624&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=43624&r=needscript Try newer version:http://bugs.php.net/fix.php?id=43624&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=43624&r=support Expected behavior:http://bugs.php.net/fix.php?id=43624&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=43624&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=43624&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=43624&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43624&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=43624&r=dst IIS Stability:http://bugs.php.net/fix.php?id=43624&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=43624&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=43624&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=43624&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=43624&r=mysqlcfg
#43572 [Fbk->Opn]: fmod($a,$b) wrong when $b is a multiple of $a
ID: 43572 User updated by: csaba at alum dot mit dot edu Reported By: csaba at alum dot mit dot edu -Status: Feedback +Status: Open Bug Type: Math related Operating System: Win XP PHP Version: 5.2.5 New Comment: Just to be clear: fmod(9.75,1.625) => 0 Expected, and works correctly for me. php -n -r "echo fmod(6.5, 1.3);" => 1.3 which is not correct (0 is correct) Csaba Note that on windows systems, double quotes are needed (because of the space) instead of the single quotes. Previous Comments: [2007-12-12 09:52:14] [EMAIL PROTECTED] Try this with CLI: php -n -r 'echo fmod(9.75,1.625);' [2007-12-12 09:51:33] [EMAIL PROTECTED] Works fine for me on Linux. ---- [2007-12-12 00:55:39] csaba at alum dot mit dot edu Description: if $div evenly divides $num, fmod($num, $div) still returns a value not equal to 0 for almost all decimal $div, where the decimal portion is not n/2^k for some n and k. e.g. fmod(9.75,1.625) => 0 because .125 is 5/2^3 Expected result: I expect to see fmod return 0 when the 1st argument is a multiple of the 2nd. Csaba Gabor from Vienna Actual result: -- fmod(6.5, 1.3) => 1.3 which is incorrect -- Edit this bug report at http://bugs.php.net/?id=43572&edit=1
#43572 [NEW]: fmod($a,$b) wrong when $b is a multiple of $a
From: csaba at alum dot mit dot edu Operating system: Win XP PHP version: 5.2.5 PHP Bug Type: Math related Bug description: fmod($a,$b) wrong when $b is a multiple of $a Description: if $div evenly divides $num, fmod($num, $div) still returns a value not equal to 0 for almost all decimal $div, where the decimal portion is not n/2^k for some n and k. e.g. fmod(9.75,1.625) => 0 because .125 is 5/2^3 Expected result: I expect to see fmod return 0 when the 1st argument is a multiple of the 2nd. Csaba Gabor from Vienna Actual result: -- fmod(6.5, 1.3) => 1.3 which is incorrect -- Edit bug report at http://bugs.php.net/?id=43572&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=43572&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=43572&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=43572&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=43572&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=43572&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=43572&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=43572&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=43572&r=needscript Try newer version:http://bugs.php.net/fix.php?id=43572&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=43572&r=support Expected behavior:http://bugs.php.net/fix.php?id=43572&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=43572&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=43572&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=43572&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43572&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=43572&r=dst IIS Stability:http://bugs.php.net/fix.php?id=43572&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=43572&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=43572&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=43572&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=43572&r=mysqlcfg
#43275 [NEW]: get_class problem with COM objects
From: csaba at alum dot mit dot edu
Operating system: Win XP Pro
PHP version: 5.2.5
PHP Bug Type: Class/Object related
Bug description: get_class problem with COM objects
Description:
Anomaly: get_class returns "com" with InternetExplorer and Excel COM
objects. But with other COM objects it returns "variant". This seems
inconsistent to me.
Reproduce code:
---
Navigate2 ("about:blank");
while ($ie->readyState<4) {
com_message_pump(200); }
$doc = $ie->document;
$body = $doc->body;
$excel = new COM("Excel.Application");
$wb = $excel->workbooks->add();
$aCom = array(ie, doc, body, excel, wb);
foreach ($aCom as $comObj)
print "$comObj: " . gettype($$comObj) .
" => " . get_class($$comObj) . "\n";
?>
Expected result:
ie: com => IWebBrowser2
doc: com => HTMLDocument
body: com => HTMLBody
excel: com => Application
wb: com => Workbook
or
ie: object => com:IWebBrowser2
doc: object => com:HTMLDocument
body: object => com:HTMLBody
excel: object => com:Application
wb: object => com:Workbook
or at a bare minimum
ie: object => com
doc: object => com
body: object => com
excel: object => com
wb: object => com
To be specific: I am advocating that gettype() on a com object return
"com". More importantly, get_class on a COM object should return
consistently: either always "com", or "com:" followed by the typename, or
(my preference) simply the typename.
Typename here refers to the VB typename function (or use my typeName
function found on http://php.net/com_print_typeinfo)
Csaba Gabor from Vienna
Actual result:
--
ie: object => com
doc: object => variant
body: object => variant
excel: object => com
wb: object => variant
--
Edit bug report at http://bugs.php.net/?id=43275&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=43275&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=43275&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=43275&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=43275&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=43275&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=43275&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=43275&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=43275&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=43275&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=43275&r=support
Expected behavior:http://bugs.php.net/fix.php?id=43275&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=43275&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=43275&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=43275&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43275&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=43275&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=43275&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=43275&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=43275&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=43275&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=43275&r=mysqlcfg
#42585 [NEW]: die() in event handler => PHP hangs
From: csaba at alum dot mit dot edu
Operating system: Win XP Pro
PHP version: 5.2.4
PHP Bug Type: COM related
Bug description: die() in event handler => PHP hangs
Description:
If I have a COM object call into PHP (via com_event_sink or IE's
window.setTimeout) with a die() within the called code, then PHP hangs.
In the example below, IE comes up and waits around for 4 seconds, after
which an $ie->quit() is issued. In the event handler (function OnQuit()) a
die() is issued. While IE does shut down, PHP does not return me the
command prompt. This is from PHP CLI, of course.
Csaba Gabor from Vienna
Reproduce code:
---
terminated = true;
} }
$ie = new COM("InternetExplorer.Application");
$ie->Visible = true;
$sink = new IESink;
com_event_sink($ie, $sink, "DWebBrowserEvents2");
$ie->Navigate("http://www.php.net/";);
$start = time();
$quitted = false;
while (!$sink->terminated) {
com_message_pump(200);
if (time()-$start>4 && !$quitted) {
$quitted=true;
$ie->quit(); } }
print "Finished!\n";
?>
Expected result:
I expect to be shown the following three lines, ie to go away, AND for PHP
to terminate:
title has changed: PHP: Hypertext Preprocessor
title has changed: PHP: Hypertext Preprocessor
Quitting
Actual result:
--
The above 3 lines are shown, IE goes away, BUT php does not terminate.
Also, note that if I manually shut IE down, instead of waiting the 4
seconds, then I get the following additional line (and PHP still hangs the
cmd prompt):
Fatal error: Call to undefined method com::quit() in Unknown on line 0
It seems to me that the while loop stays active, since that's the only
place that $ie->quit() is issued.
--
Edit bug report at http://bugs.php.net/?id=42585&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=42585&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=42585&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=42585&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=42585&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=42585&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=42585&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=42585&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=42585&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=42585&r=support
Expected behavior:http://bugs.php.net/fix.php?id=42585&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=42585&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=42585&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=42585&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42585&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=42585&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=42585&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=42585&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=42585&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=42585&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=42585&r=mysqlcfg
#35875 [NoF->Opn]: IE event failure upon scheduling script
ID: 35875
User updated by: csaba at alum dot mit dot edu
Reported By: csaba at alum dot mit dot edu
-Status: No Feedback
+Status: Open
Bug Type: COM related
Operating System: WinXP Pro
-PHP Version: 5.1.1
+PHP Version: 5.2.4
Assigned To: wharmby
New Comment:
Hi Andy, this is still happening in the same way as I originally
reported. This is with PHP 5.2.4.
Since we both have XP, I thought it might be my Norton Antivirus, but
turning off the protection did not help.
It also happens when I place event handlers on IE (com_event_sink).
My php.ini settings for COM are as follows:
com.allow_dcom = true
com.autoregister_typelib = true
com.autoregister_casesensitive = false
com.autoregister_verbose = true
Previous Comments:
[2007-06-14 01:00:00] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2007-06-06 22:24:27] [EMAIL PROTECTED]
So, it's 7th of June, what about the tests? :)
[2007-04-11 21:00:21] csaba at alum dot mit dot edu
Hi Andy,
First, in case I haven't yet expressed appreciation for your
examining the series of COM bugs I reported, a big THANK YOU to you. I
appreciate it very much.
I am currently traveling and not in a position to do the testing that
you asked. Once I arrive back on about April 24, I will attend to
carrying out the tests.
Thanks,
Csaba
[2007-04-11 14:59:12] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.2-win32-latest.zip
Hi Csaba,
Is this still an issue for you with the latest level of PHP ?
I have taken your supplied testcase and corrected the typo:
popup ("In the catch")==> mypopup ("In the catch")
to get it to run from command line and it runs as you describe; 2
pop-ups before IE is terminated and 2 after.
Next I scheduled it to run with AT command and again all was OK. I ran
it as both:
AT 13:18 %comspec% "/K php "
and
AT 13:18 /interactive %comspec% "/K php "
and both ran fine at the specified time; I just had to use Windows
Task Manager in the first case to dispose of IE and so prompt the 3rd
and 4th popups.
Next I scheduled it using schtasks. On my Windows XP system I do have a
user-id & password and I scheduled the task in 2 ways:
schtasks /Create /SC once /TN schTest /TR "php.exe "
/ST 14:12:00 /RU "\"
(and supplied password when promoted)
and
schtasks /Create /SC once /TN schTest /TR "php.exe "
/ST 14:15:00 /RU "System"
and again both times the script ran at the specified time with all 4
pop-ups.
Can you please re-try with latest PHP snapshot on your system and let
me know the result.
Regards
Andy
[2007-04-11 13:16:56] [EMAIL PROTECTED]
Hi Wez,
I will take a look at this one next
Regards
Andy
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/35875
--
Edit this bug report at http://bugs.php.net/?id=35875&edit=1
#42551 [NEW]: new COM("HTMLFile") => warnings
From: csaba at alum dot mit dot edu
Operating system: Win XP Pro
PHP version: 5.2.4
PHP Bug Type: COM related
Bug description: new COM("HTMLFile") => warnings
Description:
When I attempt to do
$doc = new COM("HTMLFile");
this results in warnings that Type Library constants True and False are
already defined. Otherwise, the script runs fine.
The equivalent code as a .vbs file runs wihtout complaints
Csaba Gabor from Vienna
Reproduce code:
---
parentWindow;
print ($doc->location . "\n");
$win->ExecScript(
"window.keepLooping=true");
$win->setTimeout (
"alert('timeout works');
window.keepLooping=false;", 2000);
while ($win->keepLooping)
com_message_pump(200);
print ("Done Looping");
?>
Expected result:
The only thing I expect to see printed is:
about:blank
Done Looping
Actual result:
--
Warning: com::com(): Type library constant True is already defined in
C:\test2.php on line 2
Warning: com::com(): Type library constant False is already defined in
C:\test2.php on line 2
about:blank
Done Looping
--
Edit bug report at http://bugs.php.net/?id=42551&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=42551&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=42551&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=42551&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=42551&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=42551&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=42551&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=42551&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=42551&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=42551&r=support
Expected behavior:http://bugs.php.net/fix.php?id=42551&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=42551&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=42551&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=42551&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42551&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=42551&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=42551&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=42551&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=42551&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=42551&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=42551&r=mysqlcfg
#42413 [NEW]: Cannot iterate IE's event object
From: csaba at alum dot mit dot edu
Operating system: Win XP Pro
PHP version: 5.2.3
PHP Bug Type: COM related
Bug description: Cannot iterate IE's event object
Description:
I can't iterate over IE's $ie->document->createEventObject() with PHP
whereas I can in IE.
Reproduce code:
---
visible = true;
// ensure a document exists within ie
$ie->Navigate2 ("about:blank");
while ($ie->readyState!=4) usleep(10);
// convenience
$doc = $ie->document;
$window = $doc->parentWindow;
// required - var must be declared
$window->execScript ("var evt='';");
// create an event object
$window->evt = $doc->createEventObject();
// proof the object is valid, iteratable
$window->execScript("
var str=''; var idx;
for (idx in evt)
str+=idx+'; ';
alert('Keys: '+str);");
// Bug: can't iterate the object in PHP
foreach ($window->evt as $prop => $val)
print "$prop ";
// ensure ie is still alive
$window->execScript("alert('Alive');");
$ie->quit(); // necessary since visible
?>
Expected result:
I expect PHP not to die at the foreach
I expect the same text to be output as with the alert
Actual result:
--
PHP falls over upon hitting the foreach loop with:
Fatal error: Uncaught exception 'Exception' with message 'Object of type
variant did not create an Iterator' in c:\phpBugs\foreach.php: 28
Stack trace:
#0 C:\phpBugs\foreach.php(28): unknown()
#1 {main} thrown in C:\phpBugs\foreach.php on line 28
--
Edit bug report at http://bugs.php.net/?id=42413&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=42413&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=42413&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=42413&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=42413&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=42413&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=42413&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=42413&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=42413&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=42413&r=support
Expected behavior:http://bugs.php.net/fix.php?id=42413&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=42413&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=42413&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=42413&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42413&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=42413&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=42413&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=42413&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=42413&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=42413&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=42413&r=mysqlcfg
#35875 [Fbk->Opn]: IE event failure upon scheduling script
ID: 35875
User updated by: csaba at alum dot mit dot edu
Reported By: csaba at alum dot mit dot edu
-Status: Feedback
+Status: Open
Bug Type: COM related
Operating System: WinXP Pro
PHP Version: 5.1.1
Assigned To: wharmby
New Comment:
Hi Andy,
First, in case I haven't yet expressed appreciation for your
examining the series of COM bugs I reported, a big THANK YOU to you. I
appreciate it very much.
I am currently traveling and not in a position to do the testing that
you asked. Once I arrive back on about April 24, I will attend to
carrying out the tests.
Thanks,
Csaba
Previous Comments:
[2007-04-11 14:59:12] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.2-win32-latest.zip
Hi Csaba,
Is this still an issue for you with the latest level of PHP ?
I have taken your supplied testcase and corrected the typo:
popup ("In the catch")==> mypopup ("In the catch")
to get it to run from command line and it runs as you describe; 2
pop-ups before IE is terminated and 2 after.
Next I scheduled it to run with AT command and again all was OK. I ran
it as both:
AT 13:18 %comspec% "/K php "
and
AT 13:18 /interactive %comspec% "/K php "
and both ran fine at the specified time; I just had to use Windows
Task Manager in the first case to dispose of IE and so prompt the 3rd
and 4th popups.
Next I scheduled it using schtasks. On my Windows XP system I do have a
user-id & password and I scheduled the task in 2 ways:
schtasks /Create /SC once /TN schTest /TR "php.exe "
/ST 14:12:00 /RU "\"
(and supplied password when promoted)
and
schtasks /Create /SC once /TN schTest /TR "php.exe "
/ST 14:15:00 /RU "System"
and again both times the script ran at the specified time with all 4
pop-ups.
Can you please re-try with latest PHP snapshot on your system and let
me know the result.
Regards
Andy
[2007-04-11 13:16:56] [EMAIL PROTECTED]
Hi Wez,
I will take a look at this one next
Regards
Andy
[2006-01-03 14:11:45] [EMAIL PROTECTED]
Assigned to the maintainer, don't expect any response.
--------------------
[2006-01-03 11:55:03] csaba at alum dot mit dot edu
I have some additional information on this problem. If I schedule the
php task using SchTasks as "Gabor", shown below, then the php script
runs fine. In order to be able to do this on my single user, no
password system I must first allow Scheduled Tasks to be run without
password as described here:
http://groups.google.com/group/microsoft.public.windowsxp.general/browse_frm/thread/c1b603be72394ee2/
Then, at the command window I type (on one wrapped line):
C:\phpApps>schtasks /Create /SC once /TN schTest /TR "php.exe
c:\phpApps\schTest.php" /ST 11:23:00 /RU "Gabor"
Just to repeat the original problem: There is a discrepancy when
scheduling (as SYSTEM - the default for AT) the php task vs. the
vbscript task to do essentially the same thing. The php task errors
when its created IE attempts to run code within the task while the
vbscript task runs fine. Both scripts run fine when run directly from
the command window.
Csaba
PS. The problem is also exhibited if I ask IE to call into PHP
directly (via a PHP class) instead of directing it into a ScriptControl.
I illustrated the method shown above because it is the direct analogue
of the standard VBScript approach, but I can also provide a "pure" PHP
way. However, in that case, when the script is scheduled as SYSTEM (via
the AT command) the error is: Permission denied
[2006-01-03 03:52:45] csaba at alum dot mit dot edu
Description:
My script brings up an instance of IE, and then it places onto IE a
function that will execute one of the script's functions (within the
script's environment). This is a normal scenario usually achieved
through com_event_sink in PHP. However, I have implemented this
independent of events. I have both a VB and PHP version, both are
working fine from the command line, thanks very much.
The problem is that when I run the PHP version using the scheduler
(either AT or SchTask), I get an IE error IE right at the point that it
tries to call back into the script (a permissions issue?). The
scheduled VB version works fine, and if I schedule PHP to invoke the VB
version that works just fine, too.
Csaba Gabor from Vienna
Reproduce code:
---
visi
#17822 [Opn->Csd]: Realpath, getcwd not returning true pathname
ID: 17822 User updated by: csaba at alum dot mit dot edu Reported By: csaba at alum dot mit dot edu -Status: Open +Status: Closed Bug Type: Feature/Change Request Operating System: Windows - all PHP Version: 4.3.0 Assigned To: sfox New Comment: Hurrah! This now appears fixed. realpath(strtolower(getcwd())) is now the same as realpath(strtoupper(getcwd())) is now the same as getcwd() on my Win XP Pro under PHP 5.2.1RC4-dev (cli) (built: Jan 25 2007 08:24:12) Thanks, Csaba Gabor from Vienna Previous Comments: [2004-04-23 00:26:09] csaba at alum dot mit dot edu I have tested this with the latest snapshot 5.0 RC 2 of April 22 on my Win 2K Pro system and it is still a problem. Here are the outputs that I get (I did an inititial print right after the first cwd() so you can see what windows thinks the directory is): C:\Morph\phpDev\40gNiKU5LQ0C c:\Morph\phpDev\40gniku5lq0c c:\Morph\phpDev\40gniku5lq0c C:\Morph\phpDev\40GNIKU5LQ0C C:\Morph\phpDev\40GNIKU5LQ0C So it appears that the middle part is OK but the drive letter and the final directory need some shoring up. Csaba Gabor [2003-02-15 17:38:53] csaba at alum dot mit dot edu I have marked this bug as open because of the demonstration below on my PHP 4.3 build date Dec. 20, 2002; Apache 2.0.43 Filter; Win2K Pro system. Here is the test: getcwd Problem " . getcwd(); print "" . realpath(getcwd()); chdir (strtoupper($cwd)); print "" . getcwd(); print "" . realpath(getcwd()); ?> On my system the first 2 directories show in lower case, the last two are in caps. Csaba -------- [2002-06-18 18:20:36] csaba at alum dot mit dot edu realpath and getcwd on Windows systems do not actually report the applicable directory, but rather a string that will !strcasecmp() with the true directory: I have a directory name, $dir, on my Win2K system (PHP 4.2.0), but it's in all lower case, and I'd like to get the actual pathname including the capitalizations: Both realpath() and dirname() only muck around with the $dir string and don't hit the file system. Not only that, but getcwd() returns $dir (sans capitalizations) after I've hopped over to it with chdir($dir)! My only solution to this point is to pop up a level and use readdir(...) but this is wasteful, only giving me one level at a time. Isn't there a REAL realpath() for windows? Thanks, Csaba Gabor -- Edit this bug report at http://bugs.php.net/?id=17822&edit=1
#34297 [NoF->Csd]: get_object_vars on COM object produces Apache error
ID: 34297 User updated by: csaba at alum dot mit dot edu Reported By: csaba at alum dot mit dot edu -Status: No Feedback +Status: Closed Bug Type: COM related Operating System: win32 PHP Version: 5CVS-2005-08-31 Assigned To: wez New Comment: Hurrah, I just checked and I'm not getting any errors. This is with the latest version of PHP 5.2 and Apache 2.2. Thanks. Previous Comments: [2007-01-01 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2006-12-24 12:39:50] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip [2005-08-31 13:33:52] [EMAIL PROTECTED] Assigned to the maintainer. [2005-08-31 11:45:40] csaba at alum dot mit dot edu I just went to http://snaps.php.net and got the latest binaries: php5.1-win32-200508310630.zip The problem still exists for me as originally reported. Csaba [2005-08-29 16:47:53] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/34297 -- Edit this bug report at http://bugs.php.net/?id=34297&edit=1
#40236 [NEW]: echo ... | php -a function allocation eats memory
From: csaba at alum dot mit dot edu Operating system: Win XP PHP version: 5CVS-2007-01-25 (snap) PHP Bug Type: Scripting Engine problem Bug description: echo ... | php -a function allocation eats memory Description: The following command line (single line in the cmd window) call does not work unless memory_limit is set to 9M or higher in php.ini on my Win XP Pro: echo ^^^ | php.exe -a It complains about having run out of memory: Interactive mode enabled Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 786432 bytes) in C:\phpLib\-(1) : eval()'d code on line 1 Reproduce code: --- The invocation line above looks a little scary (but it's just a loop to define functions) - the below single line achieves the same result: echo ^^^ | php -a Expected result: I expect the default configuration (of 8M) to be more than enough for trivial code to be invoked with the -a option. Indeed, php.exe -r "include(test.php);" works just fine It seems like each function declaration gobbles over 1M of memory when php is invoked with the -a option. I use the -a construct frequently since php-cgi.exe does not allow the -r construct, and I've noticed that between July and December of 2006 is when this problem started happening. In particular, I have an auto_prepend_file with about 50 functions defined and for php to start running on this requires that I set memory_limit to 56M minimum so that the php invocations with -a can run! Actual result: -- Tested on the most recent snaps of PHP 5.2 and PHP 6. Csaba Gabor from Vienna -- Edit bug report at http://bugs.php.net/?id=40236&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=40236&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=40236&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=40236&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=40236&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=40236&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=40236&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=40236&r=needscript Try newer version:http://bugs.php.net/fix.php?id=40236&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=40236&r=support Expected behavior:http://bugs.php.net/fix.php?id=40236&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=40236&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=40236&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=40236&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40236&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=40236&r=dst IIS Stability:http://bugs.php.net/fix.php?id=40236&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=40236&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=40236&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=40236&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=40236&r=mysqlcfg
#37984 [NEW]: CLI sometimes crashes on Shell.Application
From: csaba at alum dot mit dot edu
Operating system: Win XP Pro
PHP version: 5CVS-2006-07-01 (snap)
PHP Bug Type: COM related
Bug description: CLI sometimes crashes on Shell.Application
Description:
Sorry I cannot reliably reproduce this but...
php-win.exe often errors, giving me one of those "would you like to report
this to Microsoft dialogs" on account of the $ox=new
COM("Shell.Application"); line. This happens in version 5.1.1 (from about
Dec. 2005) and today's 5.2 Note that it only happens:
1. with php-win.exe
2. in the php-win -a form and not the -r form
3. when the Shell.Application line is present
4. when the execScript line is present
The last two lines and the opener="me" line are not required for the bug
to be shown. They are there so that when you go to the new IE, you can
make it go away by pressing any key.
Also, despite the bug, the new IE appears and the execScript functionality
is present.
// to see the bug, have DOSKEY active, and
// call the file below (named inc.php) a few
// times from a (wrapped) command line with:
// echo ^^^Whoever");
?^^^> | php-win -a
// or
// echo ^^^Whoever"); ?^^^> | php-win -d
auto_prepend_file=inc.php -a
Reproduce code:
---
Navigate2("about:blank");
// allow for settling
while ($ie->ReadyState!=4) usleep(1);
$ie->Visible = true;
// next line allows self.close()
$ie->Document->ParentWindow->opener="me";
// escape handler definition
$ie->document->parentWindow->execScript(
"document.onkeypress=function(){window.close();}");
// proof of access to IE
$ie->document->body->innerHTML = $html;
// so escape handler listens
$ie->document->body->focus(); }
?>
Expected result:
I don't expect to see any CLI error message
Actual result:
--
Every so often, sometimes consistently every time, I get a CLI error
dialog box on account of the Shell.Application line, which is not even
used (in the example).
The more windows you have open (IE and otherwise), the more likely the bug
is to show itself. Under 25 windows open, and it doesn't fail much. Also,
the problem tends to surface more readily if you go do your thing and then
come back to the Cmd window 10 or 20 minutes later and then try it again.
Sorry, I can't be more specific. I'm probably as unhappy reporting on an
intermittent bug as you are reading about it.
Csaba Gabor from Vienna
--
Edit bug report at http://bugs.php.net/?id=37984&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=37984&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=37984&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=37984&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=37984&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=37984&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=37984&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=37984&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=37984&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=37984&r=support
Expected behavior:http://bugs.php.net/fix.php?id=37984&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=37984&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=37984&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=37984&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=37984&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=37984&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=37984&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=37984&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=37984&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=37984&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=37984&r=mysqlcfg
#35875 [Opn]: IE event failure upon scheduling script
ID: 35875
User updated by: csaba at alum dot mit dot edu
Reported By: csaba at alum dot mit dot edu
Status: Open
Bug Type: COM related
Operating System: WinXP Pro
PHP Version: 5.1.1
New Comment:
I have some additional information on this problem. If I schedule the
php task using SchTasks as "Gabor", shown below, then the php script
runs fine. In order to be able to do this on my single user, no
password system I must first allow Scheduled Tasks to be run without
password as described here:
http://groups.google.com/group/microsoft.public.windowsxp.general/browse_frm/thread/c1b603be72394ee2/
Then, at the command window I type (on one wrapped line):
C:\phpApps>schtasks /Create /SC once /TN schTest /TR "php.exe
c:\phpApps\schTest.php" /ST 11:23:00 /RU "Gabor"
Just to repeat the original problem: There is a discrepancy when
scheduling (as SYSTEM - the default for AT) the php task vs. the
vbscript task to do essentially the same thing. The php task errors
when its created IE attempts to run code within the task while the
vbscript task runs fine. Both scripts run fine when run directly from
the command window.
Csaba
PS. The problem is also exhibited if I ask IE to call into PHP
directly (via a PHP class) instead of directing it into a
ScriptControl. I illustrated the method shown above because it is the
direct analogue of the standard VBScript approach, but I can also
provide a "pure" PHP way. However, in that case, when the script is
scheduled as SYSTEM (via the AT command) the error is: Permission
denied
Previous Comments:
------------
[2006-01-03 03:52:45] csaba at alum dot mit dot edu
Description:
My script brings up an instance of IE, and then it places onto IE a
function that will execute one of the script's functions (within the
script's environment). This is a normal scenario usually achieved
through com_event_sink in PHP. However, I have implemented this
independent of events. I have both a VB and PHP version, both are
working fine from the command line, thanks very much.
The problem is that when I run the PHP version using the scheduler
(either AT or SchTask), I get an IE error IE right at the point that it
tries to call back into the script (a permissions issue?). The
scheduled VB version works fine, and if I schedule PHP to invoke the VB
version that works just fine, too.
Csaba Gabor from Vienna
Reproduce code:
---
visible = true;
$ie->Navigate2("about:blank"); // empty DOM
while ($ie->readyState<4) usleep(1);// wait for IE
$window =$ie->document->parentWindow;
$window->execScript("window.doneP=false"); // init var
$oScript=new COM("MSScriptControl.ScriptControl");
$oScript->Language = "VBScript";
$oScript->AddCode('Sub EvtWrapper()
CreateObject("WScript.Shell").Popup _
"ScriptControl reached", 4, "WScript popup", 131120
End Sub');
$oScript->AddObject ("mydoc", $ie->document);
$oScript->ExecuteStatement(
'mydoc.onclick=GetRef("EvtWrapper")');
$window->execScript(
"window.myfunc=window.document.onclick");
$window->setTimeout("window.myfunc()",100);
mypopup("At com_message_pump");
try { while (!$window->doneP) com_message_pump(500); }
catch (Exception $e) { popup ("In the catch"); }
mypopup ("Done with script");
function mypopup ($text) {
$oWSH = new COM("WScript.Shell");
$oWSH->Popup($text, 4, "PHP Popup", 131120); }
?>
Expected result:
I expect this script, schTest.php, to not error when it is scheduled
with AT as:
AT 14:10 %comspec% "/K php c:\path\to\schTest.php"
In particular, just as when it is run directly, IE should come up, and
then there should be two popups: "At com_message_pump" followed by
"ScriptControl reached". Once IE is dismissed, there should be two
more popups: "In the catch" and "Done with script"
Actual result:
--
When SchTest.php is run directly (or via a .vbs invocation) then all
four popups show normally. However, when schTest.php is scheduled
through AT, then there is an IE error saying
Line: 0
Error: Object doesn't support this property or method.
When I try the scheduling through SchTask (same results as with AT),
then it is scheduled as NT AUTHORITY\SYSTEM (no password). I'm the
only user on my system and since I don't have a password, I haven't
figured out how to schedule tasks to run under my user name.
I am happy to provide the corresponding VBScript code if it would be
helpful.
--
Edit this bug report at http://bugs.php.net/?id=35875&edit=1
#35875 [NEW]: IE event failure upon scheduling script
From: csaba at alum dot mit dot edu
Operating system: WinXP Pro
PHP version: 5.1.1
PHP Bug Type: COM related
Bug description: IE event failure upon scheduling script
Description:
My script brings up an instance of IE, and then it places onto IE a
function that will execute one of the script's functions (within the
script's environment). This is a normal scenario usually achieved through
com_event_sink in PHP. However, I have implemented this independent of
events. I have both a VB and PHP version, both are working fine from the
command line, thanks very much.
The problem is that when I run the PHP version using the scheduler (either
AT or SchTask), I get an IE error IE right at the point that it tries to
call back into the script (a permissions issue?). The scheduled VB
version works fine, and if I schedule PHP to invoke the VB version that
works just fine, too.
Csaba Gabor from Vienna
Reproduce code:
---
visible = true;
$ie->Navigate2("about:blank"); // empty DOM
while ($ie->readyState<4) usleep(1);// wait for IE
$window =$ie->document->parentWindow;
$window->execScript("window.doneP=false"); // init var
$oScript=new COM("MSScriptControl.ScriptControl");
$oScript->Language = "VBScript";
$oScript->AddCode('Sub EvtWrapper()
CreateObject("WScript.Shell").Popup _
"ScriptControl reached", 4, "WScript popup", 131120
End Sub');
$oScript->AddObject ("mydoc", $ie->document);
$oScript->ExecuteStatement(
'mydoc.onclick=GetRef("EvtWrapper")');
$window->execScript(
"window.myfunc=window.document.onclick");
$window->setTimeout("window.myfunc()",100);
mypopup("At com_message_pump");
try { while (!$window->doneP) com_message_pump(500); }
catch (Exception $e) { popup ("In the catch"); }
mypopup ("Done with script");
function mypopup ($text) {
$oWSH = new COM("WScript.Shell");
$oWSH->Popup($text, 4, "PHP Popup", 131120); }
?>
Expected result:
I expect this script, schTest.php, to not error when it is scheduled with
AT as:
AT 14:10 %comspec% "/K php c:\path\to\schTest.php"
In particular, just as when it is run directly, IE should come up, and
then there should be two popups: "At com_message_pump" followed by
"ScriptControl reached". Once IE is dismissed, there should be two more
popups: "In the catch" and "Done with script"
Actual result:
--
When SchTest.php is run directly (or via a .vbs invocation) then all four
popups show normally. However, when schTest.php is scheduled through AT,
then there is an IE error saying
Line: 0
Error: Object doesn't support this property or method.
When I try the scheduling through SchTask (same results as with AT), then
it is scheduled as NT AUTHORITY\SYSTEM (no password). I'm the only user
on my system and since I don't have a password, I haven't figured out how
to schedule tasks to run under my user name.
I am happy to provide the corresponding VBScript code if it would be
helpful.
--
Edit bug report at http://bugs.php.net/?id=35875&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=35875&r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=35875&r=trysnapshot51
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=35875&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=35875&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=35875&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=35875&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=35875&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=35875&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=35875&r=support
Expected behavior:http://bugs.php.net/fix.php?id=35875&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=35875&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=35875&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=35875&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35875&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=35875&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=35875&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=35875&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=35875&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=35875&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=35875&r=mysqlcfg
#35872 [NEW]: CLI errors upon exit if class is left on IE
From: csaba at alum dot mit dot edu
Operating system: Win XP Pro
PHP version: 5.1.1
PHP Bug Type: COM related
Bug description: CLI errors upon exit if class is left on IE
Description:
If IE is left open when a PHP script ends, and we have affixed a class
instance to IE, CLI generates an error.
Csaba Gabor from Vienna
Reproduce code:
---
visible = true;// show it
$ie->Navigate2("about:blank");// give IE empty DOM
while ($ie->readyState<4) usleep(1); // wait for ready
class frob { }// dummy class
$frob = new frob; // instantiate it
$window=$ie->document->parentWindow; // window ref
$window->execScript("window.myclass=false"); // always allocate ie vars
$window->myclass = $frob; // pathway to PHP
$window->alert ("Program is ending"); // proof of no errors to here
//$window->myclass = null; // CLI errors if this commented out
?>
Expected result:
PHP is quite good about cleaning up after itself. I expect PHP to nicely
finish and leave IE up, without and CLI error dialogs asking if I want to
send a report to Microsoft.
Actual result:
--
After dismissing the "Program is ending" alert box, I get the dreaded CLI
error dialog asking if I want to send a report to Microsoft.
--
Edit bug report at http://bugs.php.net/?id=35872&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=35872&r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=35872&r=trysnapshot51
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=35872&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=35872&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=35872&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=35872&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=35872&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=35872&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=35872&r=support
Expected behavior:http://bugs.php.net/fix.php?id=35872&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=35872&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=35872&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=35872&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35872&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=35872&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=35872&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=35872&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=35872&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=35872&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=35872&r=mysqlcfg
#35811 [Opn]: auto_prepend_file neither prepends nor includes
ID: 35811
User updated by: csaba at alum dot mit dot edu
Reported By: csaba at alum dot mit dot edu
Status: Open
-Bug Type:Documentation problem
+Bug Type:Scripting Engine problem
PHP Version: 5.1.1
New Comment:
I start off with: The named auto_prepend_file should act as either a
prepended file (that is, a section placed at the beginning of the main
script) or as an include file (placed at the beginning of the main
script). If this assumption about the intent of the auto_prepend_file
is incorrect, then sniper would be correct that there is merely a
documentation issue.
In effect, the way a script is run is that first the main script file
is parsed for syntax and (key point!) functions are defined, but the
script is not yet interpreted. AFTER the parsing/definition phase the
script is interpreted (Script1 in the initial report demonstrates
this). Therefore, if include('includeMe.php') is at the beginning (or
anywhere else) of the main script, all the functions in the main script
should be defined before the script of includeMe.php is interpreted
(Script2 and includeMe.php demonstrate this).
That is to say: the consequence of my main assumption is that all
functions in the main script should be defined before the
auto_prepend_file script is interpreted. However, this is not what
happens with auto_prepend_file=c:\path\to\includeMe.php. The script in
includeMe.php is interpreted before the functions in the main script
file are defined (as Script3 in the initial report demonstrates). This
contradics my initial assumption, which I feel indicates a php bug
rather than an error in my assumption. That is to say, the
auto_prepend_file is not behaving as it is indended to, and I suggest
this behaviour should be corrected rather than the documentation merely
changed to reflect behaviour. The use case in the initial report is
intended to bolster this argument.
Csaba
Perhaps auto_prepend_file does behave as the developers meant it to,
but then it doesn't seem consistent with the option name nor the spirit
of the documentation. If the initial creator of the option had intended
it to behave as it is, would it not have made more sense to have picked
a name along the lines of auto_start or auto_preload or auto_load,
reflecting the intention more strongly?
There's a documentation problem in any event, but shouldn't that wait
till the true intention of the option has been decided? Thus, I hope
I'm not out of line in recategorizing this as a Scripting Engine
problem.
Previous Comments:
[2005-12-27 14:58:24] [EMAIL PROTECTED]
I don't understand a word of this report so I assume it's documentation
issue. The ini option behaves just like it's meant to.
----------------
[2005-12-27 01:42:33] csaba at alum dot mit dot edu
Description:
auto_prepend_file in the php.ini file neither acts as if it prepends
the designated file nor as if it were included (as stated at
http://hu.php.net/manual/en/ini.core.php#ini.auto-prepend-file).
Specifically, if this were the case, then functions defined in the main
script would take precedence over functions defined in the
auto_prepend_file, but they do not.
Use case: It seems reasonable to define a standard library of all
functions available to all scripts under a php installation (through
the auto_prepend_file php.ini setting). It also makes sense for select
scripts to be able to override these functions. In a single .php file
(with no auto_prepend_file present), this would be accomplished as
follows with Script1:
This produces no error, and an output of: Second B. If the last line
is commented out, you would instead get: First B.
Moving the first two lines to includeMe.php:
and invoking the following script2 leads to the same result:
However, if php.ini's auto_prepend_file now points to includeMe.php and
the include statement is removed from script2 to yield script3, script3
will error with a duplicate function definition, which is what I am
reporting as improper behaviour. Script3:
Thanks,
Csaba Gabor from Vienna
Expected result:
My expectation for what the auto_prepend_file does is that it either
prepends the designated file to the main script, or treats it as having
been named by an include/require function as the 1st line of the script
(the difference is effectively whether the function definitions in the
auto_prepend_file are seen before the main script's function
definitions or not).
To be specific: Remove, the first statement from the doc and have only
(with code to match): Specifies the name of the file to be parsed as if
it were called via an include construct at the very beginning of the
main script (so include_path is used).
Actual result:
--
The documentation at t
#35811 [NEW]: auto_prepend_file neither prepends nor includes
From: csaba at alum dot mit dot edu Operating system: PHP version: 5.1.1 PHP Bug Type: Scripting Engine problem Bug description: auto_prepend_file neither prepends nor includes Description: auto_prepend_file in the php.ini file neither acts as if it prepends the designated file nor as if it were included (as stated at http://hu.php.net/manual/en/ini.core.php#ini.auto-prepend-file). Specifically, if this were the case, then functions defined in the main script would take precedence over functions defined in the auto_prepend_file, but they do not. Use case: It seems reasonable to define a standard library of all functions available to all scripts under a php installation (through the auto_prepend_file php.ini setting). It also makes sense for select scripts to be able to override these functions. In a single .php file (with no auto_prepend_file present), this would be accomplished as follows with Script1: This produces no error, and an output of: Second B. If the last line is commented out, you would instead get: First B. Moving the first two lines to includeMe.php: and invoking the following script2 leads to the same result: However, if php.ini's auto_prepend_file now points to includeMe.php and the include statement is removed from script2 to yield script3, script3 will error with a duplicate function definition, which is what I am reporting as improper behaviour. Script3: Thanks, Csaba Gabor from Vienna Expected result: My expectation for what the auto_prepend_file does is that it either prepends the designated file to the main script, or treats it as having been named by an include/require function as the 1st line of the script (the difference is effectively whether the function definitions in the auto_prepend_file are seen before the main script's function definitions or not). To be specific: Remove, the first statement from the doc and have only (with code to match): Specifies the name of the file to be parsed as if it were called via an include construct at the very beginning of the main script (so include_path is used). Actual result: -- The documentation at the page above claims two contradictory things: It says that auto_prepend_file is parsed before the main file, and it says that the file is included as if it were called with the include() function. The current situation is that the auto_prepend_file is parsed separately (before) the main script file (as opposed to prepended or included), but the file name is placed onto the include file list (so that it can no longer be include_once'd - see also: http://bugs.php.net/bug.php?id=32924) -- Edit bug report at http://bugs.php.net/?id=35811&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=35811&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=35811&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=35811&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=35811&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=35811&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=35811&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=35811&r=needscript Try newer version:http://bugs.php.net/fix.php?id=35811&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=35811&r=support Expected behavior:http://bugs.php.net/fix.php?id=35811&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=35811&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=35811&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=35811&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35811&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=35811&r=dst IIS Stability:http://bugs.php.net/fix.php?id=35811&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=35811&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=35811&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=35811&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=35811&r=mysqlcfg
#35719 [NEW]: com_event_sink fails under Apache
From: csaba at alum dot mit dot edu
Operating system: Win XP Pro
PHP version: 5.1.1
PHP Bug Type: COM related
Bug description: com_event_sink fails under Apache
Description:
Using com_event_sink when PHP 5.1.1 runs as a module leads to PHP timing
out and generating an ugly apache error.
I want to be able to start up IE as a COM object and load a page into it
so that I may parse the page. This makes sense because page scraping (ie,
using the contents returned by file_get_contents($url) or other means) is
not always tenable since scripts may substantially alter the page. It is
reasonable to wait for the page to load before starting to deal with it,
hence the need for com_event_sink.
If the below code is run as CLI PHP, then it works just fine: Run the
script, see an IE window come up, and then close that IE window to
terminate the script. You can get a record of what happened in the file
'log' in the same directory as the script.
To see the bug, invoke the php file via a web server (I have been using
localhost/phpapp/theScript.php). The IE window will come up and php.net
will be loaded, but the last entry showing in the log file is:
com_event_sink has been called
Whether or not the IE window is closed, the script will time out and an
Apache HTTP Server error comes up apologizing for the inconvenience and
asking whether I'd like to tell Microsoft about the problem.
Csaba Gabor from Vienna
Reproduce code:
---
com_event_sink test page
\n";
file_put_contents($GLOBALS['logFile'],
"$out\n", FILE_APPEND); }
class IESink {
public $terminated = false;
public function TitleChange($text) {
logit ("title has changed: $text"); }
public function DocumentComplete (&$dom, $url) {
logit ("doc has loaded: $url"); }
public function OnQuit() {
logit ("Quitting");
$this->terminated = true; } }
$ie = new COM("InternetExplorer.Application");
$ie->Visible = true;
$url = "http://php.net";;
$ie->Navigate($url);
$sink = new IESink;
logit ("About to sink");
com_event_sink($ie, $sink, "DWebBrowserEvents2");
logit ("com_event_sink has been called");
while (!$sink->terminated) {
com_message_pump(1000); }
logit ("finished!");
?>
Expected result:
I expect to see events fire even when IE is brought up while it is invoked
under a web server.
Actual result:
--
IE Events don't fire, and there is an ugly error when PHP times out.
--
Edit bug report at http://bugs.php.net/?id=35719&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=35719&r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=35719&r=trysnapshot51
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=35719&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=35719&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=35719&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=35719&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=35719&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=35719&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=35719&r=support
Expected behavior:http://bugs.php.net/fix.php?id=35719&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=35719&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=35719&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=35719&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35719&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=35719&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=35719&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=35719&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=35719&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=35719&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=35719&r=mysqlcfg
#35438 [Fbk->Opn]: array_splice resetting loop index when in function
ID: 35438
User updated by: csaba at alum dot mit dot edu
Reported By: csaba at alum dot mit dot edu
-Status: Feedback
+Status: Open
Bug Type: Arrays related
Operating System: Win XP Pro
PHP Version: 5CVS-2005-11-28 (snap)
New Comment:
OK, let's suppose that it is true that the array's pointer gets reset.
In that case, why does the version where myfunc is declared without the
'&' not produce an infinite loop, and why does the inline version
(below) not produce an infinite loop? If the array's pointer is simply
reset then all of the three versions should fail (go into an infinite
loop) in the same way. But only the '&' version fails according to the
model you just presented. There's clearly another piece to this
puzzle.
$entry) {
print "$i: $entry, {$ar[$i]}\n";
array_splice($ar, $i, 0, array_splice($ar, sizeof($ar)-1, 1));
var_dump($ar);
}
//}
?>
The ACTUAL results of this inline version produce the same result as
the non '&' myfunc version (which you can get by uncommenting the three
commented out lines above):
0: a, a array(2) { [0]=> string(1) "b" [1]=> string(1) "a" }
1: b, a array(2) { [0]=> string(1) "b" [1]=> string(1) "a" }
Previous Comments:
[2005-11-28 19:12:59] [EMAIL PROTECTED]
Yes, array_splice() resets internal pointer of the array and this is
expected, because is being modified in this function.
Looking at the code, I should say you're definitely doing something
wrong and I don't see a reason why you're expecting to get something
different from the actual result.
[2005-11-28 15:46:12] csaba at alum dot mit dot edu
OK, this is my last posting of a simplified example:
$entry) {
print "$i: $entry, {$ar[$i]}\n";
array_splice($ar, $i, 0, array_splice($ar, sizeof($ar)-1, 1));
var_dump($ar);
}}
?>
The above ACTUAL results in an infinte loop:
0: a, a array(2) { [0]=> string(1) "b" [1]=> string(1) "a" }
0: b, b array(2) { [0]=> string(1) "a" [1]=> string(1) "b" }
0: a, a array(2) { [0]=> string(1) "b" [1]=> string(1) "a" }
0: b, b array(2) { [0]=> string(1) "a" [1]=> string(1) "b" }
0: a, a array(2) { [0]=> string(1) "b" [1]=> string(1) "a" }
0: b, b array(2) { [0]=> string(1) "a" [1]=> string(1) "b" }
...
The EXPECTED is what you get if you declare myfunc without the &:
0: a, a array(2) { [0]=> string(1) "b" [1]=> string(1) "a" }
1: b, a array(2) { [0]=> string(1) "b" [1]=> string(1) "a" }
Note that $entry and $ar[$i] differ on the second line
[2005-11-28 04:33:42] csaba at alum dot mit dot edu
Description:
I apologize in advance if this is not a bug, but I've narrowed it down
as far as I can and can't see the problem, so here goes...
I have an array that essentially contains the results of a (BFS)
breadth first search, a recursive directory listing. I want to
represent the heirarchical nature of the listing which means that I
want the results of the BFS converted to a DFS (depth first search)
format. I accomplish this by means of a double loop. The actual
transpositioning of the array elements happens by means of a double
array_splice: Use an inner array_splice to cut out a single entry
(which returns that entry) and then splice that in using the outer
array_splice. In fact, this works when the code is implemented at the
top level.
However, if I encapsulate the code in a function which passes $aDir by
reference, and then call the function, I wind up in an infinite loop.
The double splice is performed just fine, but then outer loop counter
($i) resets upon the next pass through the foreach, whereas this does
not happen if the code is not encapsulated within a function.
After spending some time on this, I can't spot the reason. Now I know
all bets are off you are modifying the array (which is the reason for
the advance apology), but the behaviour difference of top level vs.
function seemed interesting enough to warrant a report. I can
additionally say that this is specific to foreach and pass by
reference. If I replace the foreach with a
for ($i=0;$i\n";
bfs2dfs($aDir);
function bfs2dfs(&$aDir) {
foreach ($aDir as $i => $file) {
print "$i: $file\n";
$slashPos = strlen($file)-1; // final slash pos
while (($slashPos = strrpos($file, "/",
$slashPos-strlen($file)-1))!==false)
if (($key=array_search($common=substr($file,
0,$slashPos+1),
#35438 [Fbk->Opn]: array_splice resetting loop index when in function
ID: 35438
User updated by: csaba at alum dot mit dot edu
Reported By: csaba at alum dot mit dot edu
-Status: Feedback
+Status: Open
Bug Type: Arrays related
Operating System: Win XP Pro
PHP Version: 5CVS-2005-11-28 (snap)
New Comment:
OK, this is my last posting of a simplified example:
$entry) {
print "$i: $entry, {$ar[$i]}\n";
array_splice($ar, $i, 0, array_splice($ar, sizeof($ar)-1, 1));
var_dump($ar);
}}
?>
The above ACTUAL results in an infinte loop:
0: a, a array(2) { [0]=> string(1) "b" [1]=> string(1) "a" }
0: b, b array(2) { [0]=> string(1) "a" [1]=> string(1) "b" }
0: a, a array(2) { [0]=> string(1) "b" [1]=> string(1) "a" }
0: b, b array(2) { [0]=> string(1) "a" [1]=> string(1) "b" }
0: a, a array(2) { [0]=> string(1) "b" [1]=> string(1) "a" }
0: b, b array(2) { [0]=> string(1) "a" [1]=> string(1) "b" }
...
The EXPECTED is what you get if you declare myfunc without the &:
0: a, a array(2) { [0]=> string(1) "b" [1]=> string(1) "a" }
1: b, a array(2) { [0]=> string(1) "b" [1]=> string(1) "a" }
Note that $entry and $ar[$i] differ on the second line
Previous Comments:
------------------------
[2005-11-28 15:21:07] [EMAIL PROTECTED]
Where are the "Expected" and "Actual" results?
[2005-11-28 15:15:12] csaba at alum dot mit dot edu
OK, I think this is going to be my last post on simplifying this
example. I was wrong in saying that the similar mysort does not
exhibit the problem. It does, but I had the print statement in the
wrong place earlier. So I've simplified the bubble sort to illustrate
the issue. Note that you will see the foreach loop is gone through
twice. Presumably this happens because the array_splice messes up the
foreach, but on the second pass since the array is already sorted, the
array_splice won't be executed again, so the foreach won't reset again.
Also, as before, the problem does not happen if $aDir is not passed by
reference.
\n";
mysort($aDir);
function mysort(&$aDir) {
foreach ($aDir as $i => $file) {
print "$i: $file\n";
if (!$i || ($file>=$aDir[$i-1])) continue;
for ($j=0;$j<$i;++$j) if ($aDir[$j]>$file) break;
array_splice($aDir, $j, 0, array_splice($aDir, $i, 1));
print "after splice with (i, j, file) as ($i, $j, $file)\n";
var_dump($aDir);
}
}
?>
Csaba
------------------------
[2005-11-28 15:06:01] [EMAIL PROTECTED]
Come up with _simple_ code we can cut'n'paste. This is not simple.
There's million and one things that can affect it.
[2005-11-28 14:40:56] csaba at alum dot mit dot edu
I am able to make a slight simplification. If I assume that each
directory's parent also exists in the array (that is to say, no filter
was applied), then I don't need the while loop. Furthermore, I don't
need the if clause testing for existence either. But the problem still
exists. Hence, the simpler:
\n";
bfs2dfs($aDir);
function bfs2dfs(&$aDir) {
foreach ($aDir as $i => $file) {
print "$i: $file\n";
// if top level file or dir, then continue
if (($slashPos = strrpos($file, "/", -2))===false) continue;
$parent=substr($file, 0,$slashPos+1);
$key=array_search($parent,$aDir); // guarenteed to exist
for ($j=$key+1;$j<$i;++$j)
if ($parent!=substr($aDir[$j],0, $slashPos+1)) break;
array_splice($aDir, $j, 0, array_splice($aDir, $i, 1));
print "after splice with (i, j, file) as ($i, $j, $file)\n";
var_dump($aDir);
print "\n";
continue 1; }
}
?>
[2005-11-28 04:33:42] csaba at alum dot mit dot edu
Description:
I apologize in advance if this is not a bug, but I've narrowed it down
as far as I can and can't see the problem, so here goes...
I have an array that essentially contains the results of a (BFS)
breadth first search, a recursive directory listing. I want to
represent the heirarchical nature of the listing which means that I
want the results of the BFS converted to a DFS (depth first search)
format. I accomplish this by means of a double loop. The actual
transpositioning of the array elements happens by means of a double
array_splice: Use an inner array_splice to cut out a single entry
(which returns that entry) and then splice that in using the outer
array_splice. In fact, this works when the code is implemented at
#35438 [Bgs->Opn]: array_splice resetting loop index when in function
ID: 35438
User updated by: csaba at alum dot mit dot edu
Reported By: csaba at alum dot mit dot edu
-Status: Bogus
+Status: Open
Bug Type: Arrays related
Operating System: Win XP Pro
PHP Version: 5CVS-2005-11-28 (snap)
New Comment:
OK, I think this is going to be my last post on simplifying this
example. I was wrong in saying that the similar mysort does not
exhibit the problem. It does, but I had the print statement in the
wrong place earlier. So I've simplified the bubble sort to illustrate
the issue. Note that you will see the foreach loop is gone through
twice. Presumably this happens because the array_splice messes up the
foreach, but on the second pass since the array is already sorted, the
array_splice won't be executed again, so the foreach won't reset again.
Also, as before, the problem does not happen if $aDir is not passed by
reference.
\n";
mysort($aDir);
function mysort(&$aDir) {
foreach ($aDir as $i => $file) {
print "$i: $file\n";
if (!$i || ($file>=$aDir[$i-1])) continue;
for ($j=0;$j<$i;++$j) if ($aDir[$j]>$file) break;
array_splice($aDir, $j, 0, array_splice($aDir, $i, 1));
print "after splice with (i, j, file) as ($i, $j, $file)\n";
var_dump($aDir);
}
}
?>
Csaba
Previous Comments:
[2005-11-28 15:06:01] [EMAIL PROTECTED]
Come up with _simple_ code we can cut'n'paste. This is not simple.
There's million and one things that can affect it.
------------------------
[2005-11-28 14:40:56] csaba at alum dot mit dot edu
I am able to make a slight simplification. If I assume that each
directory's parent also exists in the array (that is to say, no filter
was applied), then I don't need the while loop. Furthermore, I don't
need the if clause testing for existence either. But the problem still
exists. Hence, the simpler:
\n";
bfs2dfs($aDir);
function bfs2dfs(&$aDir) {
foreach ($aDir as $i => $file) {
print "$i: $file\n";
// if top level file or dir, then continue
if (($slashPos = strrpos($file, "/", -2))===false) continue;
$parent=substr($file, 0,$slashPos+1);
$key=array_search($parent,$aDir); // guarenteed to exist
for ($j=$key+1;$j<$i;++$j)
if ($parent!=substr($aDir[$j],0, $slashPos+1)) break;
array_splice($aDir, $j, 0, array_splice($aDir, $i, 1));
print "after splice with (i, j, file) as ($i, $j, $file)\n";
var_dump($aDir);
print "\n";
continue 1; }
}
?>
[2005-11-28 04:33:42] csaba at alum dot mit dot edu
Description:
I apologize in advance if this is not a bug, but I've narrowed it down
as far as I can and can't see the problem, so here goes...
I have an array that essentially contains the results of a (BFS)
breadth first search, a recursive directory listing. I want to
represent the heirarchical nature of the listing which means that I
want the results of the BFS converted to a DFS (depth first search)
format. I accomplish this by means of a double loop. The actual
transpositioning of the array elements happens by means of a double
array_splice: Use an inner array_splice to cut out a single entry
(which returns that entry) and then splice that in using the outer
array_splice. In fact, this works when the code is implemented at the
top level.
However, if I encapsulate the code in a function which passes $aDir by
reference, and then call the function, I wind up in an infinite loop.
The double splice is performed just fine, but then outer loop counter
($i) resets upon the next pass through the foreach, whereas this does
not happen if the code is not encapsulated within a function.
After spending some time on this, I can't spot the reason. Now I know
all bets are off you are modifying the array (which is the reason for
the advance apology), but the behaviour difference of top level vs.
function seemed interesting enough to warrant a report. I can
additionally say that this is specific to foreach and pass by
reference. If I replace the foreach with a
for ($i=0;$i\n";
bfs2dfs($aDir);
function bfs2dfs(&$aDir) {
foreach ($aDir as $i => $file) {
print "$i: $file\n";
$slashPos = strlen($file)-1; // final slash pos
while (($slashPos = strrpos($file, "/",
$slashPos-strlen($file)-1))!==false)
if (($key=array_search($common=substr($file,
0,$slashPos+1),$aDir))!==false) {
for ($j=$key+1;$j<$i;++$j)
if ($common!=substr($aDir[$j],0,
$slashPos+1))
break;
array_splice($aDir, $j, 0,
array_splice($aDir, $i, 1));print "after
splice
#35438 [Opn]: array_splice resetting loop index when in function
ID: 35438
User updated by: csaba at alum dot mit dot edu
Reported By: csaba at alum dot mit dot edu
Status: Open
Bug Type: Unknown/Other Function
Operating System: Win XP Pro
PHP Version: 5CVS-2005-11-28 (snap)
New Comment:
I am able to make a slight simplification. If I assume that each
directory's parent also exists in the array (that is to say, no filter
was applied), then I don't need the while loop. Furthermore, I don't
need the if clause testing for existence either. But the problem still
exists. Hence, the simpler:
\n";
bfs2dfs($aDir);
function bfs2dfs(&$aDir) {
foreach ($aDir as $i => $file) {
print "$i: $file\n";
// if top level file or dir, then continue
if (($slashPos = strrpos($file, "/", -2))===false) continue;
$parent=substr($file, 0,$slashPos+1);
$key=array_search($parent,$aDir); // guarenteed to exist
for ($j=$key+1;$j<$i;++$j)
if ($parent!=substr($aDir[$j],0, $slashPos+1)) break;
array_splice($aDir, $j, 0, array_splice($aDir, $i, 1));
print "after splice with (i, j, file) as ($i, $j, $file)\n";
var_dump($aDir);
print "\n";
continue 1; }
}
?>
Previous Comments:
------------------------
[2005-11-28 14:10:44] csaba at alum dot mit dot edu
For comparison sake, here is a function (doing a bubble sort) that has
most of the same elements as the original one, but it works as
expected:
$file) {
while ($i && ($file<$ar[$i-1])) {
for ($j=0;$j<$i;++$j) if ($ar[$j]>$file) break;
print "(i=>file; j=>ar[j]) => " .
"($i => $file; $j => {$ar[$j]})\n";
array_splice($ar, $j, 0, array_splice($ar, $i, 1));
continue 2; }}
}
mysort($ar);
var_dump ($ar);
?>
[2005-11-28 13:42:16] csaba at alum dot mit dot edu
Sorry Tony, truly I do not like submitting such a complicated example.
I tried to construct a simpler version before submitting and I wasn't
able to.
I tried to give an overview of how the code is supposed to work in the
three paragraphs just under the code itself in the original posting,
but I'll try a more detailed explanation with example here:
The original array starts off as ["B/", "file", "B/C/"]. Terminating
slashes indicate a directory. So the main directory had "B/" and
"file" in it, and "B/" has an empty subdirectory "B/C/".
I want the array to acquire the form ["B/", "B/C/", "file"] where the
"B/C/" follows the "B/" since it's a subdirectory, but the code has to
deal with more general situations (specifically, there may be filters
to weed out some of the entries in the original array). But all this
is just background in where $aDir is coming from. On to the code,
which which I'll try to illustrate by example.
The foreach starts off with ($i => $file) of
0 => B/
and the while tries to see if there are any directories above 'B/'.
There aren't so we're on to the next iteration.
1 => file
There are again no directories above 'file' so we're on to the next
iteration
2 => B/C/
This time the while sees a '/' (prior to the final one) so it knows
there is a higher level directory above 'B/C/', namely 'B/' (at this
point $slashPos=1).
The if tests to see if this higher level directory ($common='B/') is an
entry in $aDir. It is, with $key=0 (in the more general case, specific
ancestor directories are not guaranteed because of possible filters) so
we get to the body of the if.
Now the entries in $aDir from 0 to $i-1 are in DFS order (because that
is what the function is producing). This means that the descendants of
the (or any given) ancestor will be grouped in a contiguous block just
after said ancestor. We can test for this block by checking for (with
the for loop) the first entry of which $common, the ancester, is not
the initial starting substring (which is what the if is doing). In our
example, this happens right away with "file" so that $j=1 and we break
out of the for loop.
Thus we have identified where the current entry being processed ($i=2;
$file="B/C/") should go (just before position $j=1). So we snip out
the current entry with array_splice($aDir, $i, 1) and we insert it to
position $j with array_splice($aDir, $j, 0, array_splice($aDir, $i,
1))
This correctly gives us $aDir = ["B/", "B/C/", "file"] as the print and
var_dump show. At this point we are ready to continue with the foreach,
hence the continue 2;
Unfortunately, the foreach loop has been reset at this point and gives
($i=0; $file="B/"). We'll wi
#35438 [Opn]: array_splice resetting loop index when in function
ID: 35438
User updated by: csaba at alum dot mit dot edu
Reported By: csaba at alum dot mit dot edu
Status: Open
Bug Type: Unknown/Other Function
Operating System: Win XP Pro
PHP Version: 5CVS-2005-11-28 (snap)
New Comment:
For comparison sake, here is a function (doing a bubble sort) that has
most of the same elements as the original one, but it works as
expected:
$file) {
while ($i && ($file<$ar[$i-1])) {
for ($j=0;$j<$i;++$j) if ($ar[$j]>$file) break;
print "(i=>file; j=>ar[j]) => " .
"($i => $file; $j => {$ar[$j]})\n";
array_splice($ar, $j, 0, array_splice($ar, $i, 1));
continue 2; }}
}
mysort($ar);
var_dump ($ar);
?>
Previous Comments:
------------------------
[2005-11-28 13:42:16] csaba at alum dot mit dot edu
Sorry Tony, truly I do not like submitting such a complicated example.
I tried to construct a simpler version before submitting and I wasn't
able to.
I tried to give an overview of how the code is supposed to work in the
three paragraphs just under the code itself in the original posting,
but I'll try a more detailed explanation with example here:
The original array starts off as ["B/", "file", "B/C/"]. Terminating
slashes indicate a directory. So the main directory had "B/" and
"file" in it, and "B/" has an empty subdirectory "B/C/".
I want the array to acquire the form ["B/", "B/C/", "file"] where the
"B/C/" follows the "B/" since it's a subdirectory, but the code has to
deal with more general situations (specifically, there may be filters
to weed out some of the entries in the original array). But all this
is just background in where $aDir is coming from. On to the code,
which which I'll try to illustrate by example.
The foreach starts off with ($i => $file) of
0 => B/
and the while tries to see if there are any directories above 'B/'.
There aren't so we're on to the next iteration.
1 => file
There are again no directories above 'file' so we're on to the next
iteration
2 => B/C/
This time the while sees a '/' (prior to the final one) so it knows
there is a higher level directory above 'B/C/', namely 'B/' (at this
point $slashPos=1).
The if tests to see if this higher level directory ($common='B/') is an
entry in $aDir. It is, with $key=0 (in the more general case, specific
ancestor directories are not guaranteed because of possible filters) so
we get to the body of the if.
Now the entries in $aDir from 0 to $i-1 are in DFS order (because that
is what the function is producing). This means that the descendants of
the (or any given) ancestor will be grouped in a contiguous block just
after said ancestor. We can test for this block by checking for (with
the for loop) the first entry of which $common, the ancester, is not
the initial starting substring (which is what the if is doing). In our
example, this happens right away with "file" so that $j=1 and we break
out of the for loop.
Thus we have identified where the current entry being processed ($i=2;
$file="B/C/") should go (just before position $j=1). So we snip out
the current entry with array_splice($aDir, $i, 1) and we insert it to
position $j with array_splice($aDir, $j, 0, array_splice($aDir, $i,
1))
This correctly gives us $aDir = ["B/", "B/C/", "file"] as the print and
var_dump show. At this point we are ready to continue with the foreach,
hence the continue 2;
Unfortunately, the foreach loop has been reset at this point and gives
($i=0; $file="B/"). We'll wind up in an infinite loop, but that is not
the issue - the resetting of the foreach is what is in question.
Tony, I'm happy to answer further questions, but I can't figure out how
to simplify my example currently, though I wish I could.
Csaba
------------------------
[2005-11-28 12:35:08] [EMAIL PROTECTED]
Are you able to understand your code yourself?
Can you make it CLEAR, so I don't have to spend half of the day trying
to get what this code does?
[2005-11-28 12:32:52] csaba at alum dot mit dot edu
\n";
bfs2dfs($aDir);
function bfs2dfs(&$aDir) {
foreach ($aDir as $i => $file) {
print "$i: $file\n";
$slashPos = strlen($file)-1; // final slash pos
while (($slashPos = strrpos($file, "/",
$slashPos-strlen($file)-1))!==false)
if (($key=array_search($common=substr($file,
0,$slashPos+1),$aDir))!==false) {
for ($j=$key+1;$j<$i;++$j)
if ($common!=substr($a
#35438 [Fbk->Opn]: array_splice resetting loop index when in function
ID: 35438
User updated by: csaba at alum dot mit dot edu
Reported By: csaba at alum dot mit dot edu
-Status: Feedback
+Status: Open
Bug Type: Unknown/Other Function
Operating System: Win XP Pro
PHP Version: 5CVS-2005-11-28 (snap)
New Comment:
Sorry Tony, truly I do not like submitting such a complicated example.
I tried to construct a simpler version before submitting and I wasn't
able to.
I tried to give an overview of how the code is supposed to work in the
three paragraphs just under the code itself in the original posting,
but I'll try a more detailed explanation with example here:
The original array starts off as ["B/", "file", "B/C/"]. Terminating
slashes indicate a directory. So the main directory had "B/" and
"file" in it, and "B/" has an empty subdirectory "B/C/".
I want the array to acquire the form ["B/", "B/C/", "file"] where the
"B/C/" follows the "B/" since it's a subdirectory, but the code has to
deal with more general situations (specifically, there may be filters
to weed out some of the entries in the original array). But all this
is just background in where $aDir is coming from. On to the code,
which which I'll try to illustrate by example.
The foreach starts off with ($i => $file) of
0 => B/
and the while tries to see if there are any directories above 'B/'.
There aren't so we're on to the next iteration.
1 => file
There are again no directories above 'file' so we're on to the next
iteration
2 => B/C/
This time the while sees a '/' (prior to the final one) so it knows
there is a higher level directory above 'B/C/', namely 'B/' (at this
point $slashPos=1).
The if tests to see if this higher level directory ($common='B/') is an
entry in $aDir. It is, with $key=0 (in the more general case, specific
ancestor directories are not guaranteed because of possible filters) so
we get to the body of the if.
Now the entries in $aDir from 0 to $i-1 are in DFS order (because that
is what the function is producing). This means that the descendants of
the (or any given) ancestor will be grouped in a contiguous block just
after said ancestor. We can test for this block by checking for (with
the for loop) the first entry of which $common, the ancester, is not
the initial starting substring (which is what the if is doing). In our
example, this happens right away with "file" so that $j=1 and we break
out of the for loop.
Thus we have identified where the current entry being processed ($i=2;
$file="B/C/") should go (just before position $j=1). So we snip out
the current entry with array_splice($aDir, $i, 1) and we insert it to
position $j with array_splice($aDir, $j, 0, array_splice($aDir, $i,
1))
This correctly gives us $aDir = ["B/", "B/C/", "file"] as the print and
var_dump show. At this point we are ready to continue with the foreach,
hence the continue 2;
Unfortunately, the foreach loop has been reset at this point and gives
($i=0; $file="B/"). We'll wind up in an infinite loop, but that is not
the issue - the resetting of the foreach is what is in question.
Tony, I'm happy to answer further questions, but I can't figure out how
to simplify my example currently, though I wish I could.
Csaba
Previous Comments:
--------
[2005-11-28 12:35:08] [EMAIL PROTECTED]
Are you able to understand your code yourself?
Can you make it CLEAR, so I don't have to spend half of the day trying
to get what this code does?
[2005-11-28 12:32:52] csaba at alum dot mit dot edu
\n";
bfs2dfs($aDir);
function bfs2dfs(&$aDir) {
foreach ($aDir as $i => $file) {
print "$i: $file\n";
$slashPos = strlen($file)-1; // final slash pos
while (($slashPos = strrpos($file, "/",
$slashPos-strlen($file)-1))!==false)
if (($key=array_search($common=substr($file,
0,$slashPos+1),$aDir))!==false) {
for ($j=$key+1;$j<$i;++$j)
if ($common!=substr($aDir[$j],0, $slashPos+1)) break;
array_splice($aDir, $j, 0, array_splice($aDir, $i, 1));
print "after splice with (i, j, file) as ($i, $j, $file)\n";
var_dump($aDir);
print "\n";
continue 2; }}
}
?>
[2005-11-28 12:14:04] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require
#35438 [Fbk->Opn]: array_splice resetting loop index when in function
ID: 35438
User updated by: csaba at alum dot mit dot edu
Reported By: csaba at alum dot mit dot edu
-Status: Feedback
+Status: Open
Bug Type: Scripting Engine problem
Operating System: Win XP Pro
PHP Version: 5CVS-2005-11-28 (snap)
New Comment:
\n";
bfs2dfs($aDir);
function bfs2dfs(&$aDir) {
foreach ($aDir as $i => $file) {
print "$i: $file\n";
$slashPos = strlen($file)-1; // final slash pos
while (($slashPos = strrpos($file, "/",
$slashPos-strlen($file)-1))!==false)
if (($key=array_search($common=substr($file,
0,$slashPos+1),$aDir))!==false) {
for ($j=$key+1;$j<$i;++$j)
if ($common!=substr($aDir[$j],0, $slashPos+1)) break;
array_splice($aDir, $j, 0, array_splice($aDir, $i, 1));
print "after splice with (i, j, file) as ($i, $j, $file)\n";
var_dump($aDir);
print "\n";
continue 2; }}
}
?>
Previous Comments:
[2005-11-28 12:14:04] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc.
If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.
------------------------
[2005-11-28 04:33:42] csaba at alum dot mit dot edu
Description:
I apologize in advance if this is not a bug, but I've narrowed it down
as far as I can and can't see the problem, so here goes...
I have an array that essentially contains the results of a (BFS)
breadth first search, a recursive directory listing. I want to
represent the heirarchical nature of the listing which means that I
want the results of the BFS converted to a DFS (depth first search)
format. I accomplish this by means of a double loop. The actual
transpositioning of the array elements happens by means of a double
array_splice: Use an inner array_splice to cut out a single entry
(which returns that entry) and then splice that in using the outer
array_splice. In fact, this works when the code is implemented at the
top level.
However, if I encapsulate the code in a function which passes $aDir by
reference, and then call the function, I wind up in an infinite loop.
The double splice is performed just fine, but then outer loop counter
($i) resets upon the next pass through the foreach, whereas this does
not happen if the code is not encapsulated within a function.
After spending some time on this, I can't spot the reason. Now I know
all bets are off you are modifying the array (which is the reason for
the advance apology), but the behaviour difference of top level vs.
function seemed interesting enough to warrant a report. I can
additionally say that this is specific to foreach and pass by
reference. If I replace the foreach with a
for ($i=0;$i\n";
bfs2dfs($aDir);
function bfs2dfs(&$aDir) {
foreach ($aDir as $i => $file) {
print "$i: $file\n";
$slashPos = strlen($file)-1; // final slash pos
while (($slashPos = strrpos($file, "/",
$slashPos-strlen($file)-1))!==false)
if (($key=array_search($common=substr($file,
0,$slashPos+1),$aDir))!==false) {
for ($j=$key+1;$j<$i;++$j)
if ($common!=substr($aDir[$j],0,
$slashPos+1))
break;
array_splice($aDir, $j, 0,
array_splice($aDir, $i, 1));print "after
splice with (i,
j, file) " .
"as ($i, $j, $file)\n";
var_dump($aDir);
print "\n";
continue 2; }}
}
The idea behind this code is that we march through the array and each
time we encounter a file or dir, we move it to be the last child (of
already encountered children) of the most immediate (already
encountered) ancestor.
We do this by peeling off lower level subdirectories one after another
(that's what the while does) and see if what remains has already been
encountered (that's what the first if tests), hence processed. If so,
we march forward from that point (the for loop), checking to see (the
second if) when we are no longer a descendent of this ancestor. That
gives the position to insert the current file, which is done by means
of the double array_splice.
Again, if I comment out the function definition line and its closing
'}' and the bfs2dfs($aDir) call, the code works as expected. If the
foreach is replace by a for, the code works as expected, and if the
function declares $aDir by value instead of &$aDir by ref, the code
also works as expected.
Expected result:
#35438 [NEW]: array_splice resetting loop index when in function
From: csaba at alum dot mit dot edu
Operating system: Win XP Pro
PHP version: 5CVS-2005-11-28 (snap)
PHP Bug Type: Scripting Engine problem
Bug description: array_splice resetting loop index when in function
Description:
I apologize in advance if this is not a bug, but I've narrowed it down as
far as I can and can't see the problem, so here goes...
I have an array that essentially contains the results of a (BFS) breadth
first search, a recursive directory listing. I want to represent the
heirarchical nature of the listing which means that I want the results of
the BFS converted to a DFS (depth first search) format. I accomplish this
by means of a double loop. The actual transpositioning of the array
elements happens by means of a double array_splice: Use an inner
array_splice to cut out a single entry (which returns that entry) and then
splice that in using the outer array_splice. In fact, this works when the
code is implemented at the top level.
However, if I encapsulate the code in a function which passes $aDir by
reference, and then call the function, I wind up in an infinite loop. The
double splice is performed just fine, but then outer loop counter ($i)
resets upon the next pass through the foreach, whereas this does not
happen if the code is not encapsulated within a function.
After spending some time on this, I can't spot the reason. Now I know all
bets are off you are modifying the array (which is the reason for the
advance apology), but the behaviour difference of top level vs. function
seemed interesting enough to warrant a report. I can additionally say
that this is specific to foreach and pass by reference. If I replace the
foreach with a
for ($i=0;$i\n";
bfs2dfs($aDir);
function bfs2dfs(&$aDir) {
foreach ($aDir as $i => $file) {
print "$i: $file\n";
$slashPos = strlen($file)-1; // final slash pos
while (($slashPos = strrpos($file, "/",
$slashPos-strlen($file)-1))!==false)
if (($key=array_search($common=substr($file,
0,$slashPos+1),$aDir))!==false) {
for ($j=$key+1;$j<$i;++$j)
if ($common!=substr($aDir[$j],0,
$slashPos+1))
break;
array_splice($aDir, $j, 0,
array_splice($aDir, $i, 1));print "after
splice with (i, j,
file) " .
"as ($i, $j, $file)\n";
var_dump($aDir);
print "\n";
continue 2; }}
}
The idea behind this code is that we march through the array and each time
we encounter a file or dir, we move it to be the last child (of already
encountered children) of the most immediate (already encountered)
ancestor.
We do this by peeling off lower level subdirectories one after another
(that's what the while does) and see if what remains has already been
encountered (that's what the first if tests), hence processed. If so, we
march forward from that point (the for loop), checking to see (the second
if) when we are no longer a descendent of this ancestor. That gives the
position to insert the current file, which is done by means of the double
array_splice.
Again, if I comment out the function definition line and its closing '}'
and the bfs2dfs($aDir) call, the code works as expected. If the foreach
is replace by a for, the code works as expected, and if the function
declares $aDir by value instead of &$aDir by ref, the code also works as
expected.
Expected result:
array(3) { [0]=> string(2) "B/" [1]=> string(4) "file" [2]=> string(4)
"B/C/" }
0: B/
1: file
2: B/C/
after splice with (i, j, file) as (2, 1, B/C/)
array(3) { [0]=> string(2) "B/" [1]=> string(4) "B/C/" [2]=> string(4)
"file" }
Actual result:
--
exactly the same as with the expected result, but then it continues
looping infinitely with the following:
0: B/
1: B/C/
after splice with (i, j, file) as (1, 1, B/C/)
array(3) { [0]=> string(2) "B/" [1]=> string(4) "B/C/" [2]=> string(4)
"file" }
The interesting thing here is not the infinite loop, but the fact that the
loop counter ($i) reset to 0.
--
Edit bug report at http://bugs.php.net/?id=35438&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=35438&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=35438&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=35438&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=35438&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=35438&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=35438&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=35438&r=needscript
Try newer version: http://bugs.php.ne
#35365 [WFx->Opn]: phpinfo's css affects other parts of page
ID: 35365
User updated by: csaba at alum dot mit dot edu
Reported By: csaba at alum dot mit dot edu
-Status: Wont fix
+Status: Open
Bug Type:PHP options/info functions
PHP Version: 5CVS-2005-11-24 (snap)
New Comment:
This is the second half of the report. It is a poor man's "band aid"
code to show that phpinfo() could produce output that doesn't interfere
with the prior parts of the page. I say "poor man's" because this type
of preg_replacing is not bulletproof, and the fix really belongs in the
bowels of php and not as an external revision. The short classes like
.v should be eliminated and really there should only be a .phpinfo
class and maybe one or two others (to differentiate between td.v and
td.e for example) - but this is secondary. I'm no expert in CSS,
though.
To see it work, replace in the original report with
the code below (all of which should be below the example page (the demo
table) found at the top of this bug report.
... base page goes here ...
in phpinfo()
reclass($phpinfo, "h1", $cP . "h1");
reclass($phpinfo, "h2", $cP . "h2");
$phpinfo = preg_replace('//',
"", $phpinfo);
return $phpinfo;
}
function reclass (&$phpinfo, $elem, $toClass,
$startOfLineP=true, $delim=">") {
$phpinfo = preg_replace("/" .
($startOfLineP ? "^<" : "<") . "$elem$delim/" .
($startOfLineP ? "m" : ""),
"<$elem class=$toClass$delim", $phpinfo); }
function redeclareClass ($aClassNames, &$phpinfo,
$classPfx) {
foreach ($aClassNames as $oC) // $oC = oldClass
$phpinfo = preg_replace(
"/^\\.?$oC (.*)\\}/m",
".$classPfx$oC $1}", $phpinfo); }
function xferCSS ($srcElem, $destElem, &$phpinfo) {
preg_match ("/^$srcElem { ?(.*)\\}/m",
$phpinfo, $aM, PREG_OFFSET_CAPTURE);
$CSS = $aM[1][0]; $mL = strlen($aM[0][0]);
// next line longer to account for possible
// space (' ?') in 1st line
$phpinfo = substr_replace ($phpinfo, "",
$aM[1][1]-($mL-(strlen($CSS))), $mL+1);
$phpinfo = preg_replace(
"/^($destElem {)(.*)\\}/m",
"$1$2 $CSS}",$phpinfo); }
?>
Note that all the features described in the original report have
returned to the top table: it has thick light borders, a yellow
background, serif fonts, and row 2, cell 2 has only one line
Csaba
Previous Comments:
[2005-11-24 13:17:15] [EMAIL PROTECTED]
This is a debug tool
[2005-11-24 13:09:31] csaba at alum dot mit dot edu
Description:
phpinfo's style sheet drastically affects other parts of the web page
being generated, and there seems to be no compelling reason for it.
For example, note the output of the following .php page:
phpinfo test page
Row1, Col1
Row1, Col2
Row2, Col1
Row2, Col2
In particular, on both IE 6 and FF,
there are thick light borders, yellow background,
serif fonts, and row 2, cell 2 has only one line
Now add the following line:
While this prints out the php information, it drastically alters the
appearance of the table at the top of the page. Specifically, the
background color has gone from yellow to white, the table borders are
now all thin, dark lines, the fonts are now all sans serif, and row 2,
cell 2 now has 2 lines with the text on the top line and the image to
the right on the line below.
Expected result:
I expect the original page, by and large, to remain the same as before
phpinfo was invoked. In particular, the bulk of the problems happen
because many of phpinfo()'s style declarations are applied to element
types instead of phpinfo() specific classes within an element type.
For example,
table { ... } affects all tables and not just phpinfo()'s tables. I
would like to suggest making a phpinfo() specific class and using this
for all elements generated with phpinfo()
Thanks,
Csaba Gabor from Vienna
--
Edit this bug report at http://bugs.php.net/?id=35365&edit=1
#35365 [NEW]: phpinfo's css affects other parts of page
From: csaba at alum dot mit dot edu
Operating system:
PHP version: 5CVS-2005-11-24 (snap)
PHP Bug Type: PHP options/info functions
Bug description: phpinfo's css affects other parts of page
Description:
phpinfo's style sheet drastically affects other parts of the web page
being generated, and there seems to be no compelling reason for it.
For example, note the output of the following .php page:
phpinfo test page
Row1, Col1
Row1, Col2
Row2, Col1
Row2, Col2
In particular, on both IE 6 and FF,
there are thick light borders, yellow background,
serif fonts, and row 2, cell 2 has only one line
Now add the following line:
While this prints out the php information, it drastically alters the
appearance of the table at the top of the page. Specifically, the
background color has gone from yellow to white, the table borders are now
all thin, dark lines, the fonts are now all sans serif, and row 2, cell 2
now has 2 lines with the text on the top line and the image to the right
on the line below.
Expected result:
I expect the original page, by and large, to remain the same as before
phpinfo was invoked. In particular, the bulk of the problems happen
because many of phpinfo()'s style declarations are applied to element
types instead of phpinfo() specific classes within an element type. For
example,
table { ... } affects all tables and not just phpinfo()'s tables. I would
like to suggest making a phpinfo() specific class and using this for all
elements generated with phpinfo()
Thanks,
Csaba Gabor from Vienna
--
Edit bug report at http://bugs.php.net/?id=35365&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=35365&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=35365&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=35365&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=35365&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=35365&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=35365&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=35365&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=35365&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=35365&r=support
Expected behavior: http://bugs.php.net/fix.php?id=35365&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=35365&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=35365&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=35365&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35365&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=35365&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=35365&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=35365&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=35365&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=35365&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=35365&r=mysqlcfg
#35345 [NEW]: SQLite won't load (specified module not found)
From: csaba at alum dot mit dot edu Operating system: Win XP Pro PHP version: 5CVS-2005-11-23 (snap) PHP Bug Type: SQLite related Bug description: SQLite won't load (specified module not found) Description: I downloaded a new snapshot (.zip) of PHP (version 5.1.0 RC7), stopped Apache 2 and overwrote the prior extracted files (about 10), all sitting in c:\winapps\php.net. In addition, I also extracted php_sqlite.dll to the same directory (since my sqlite code which had been relying on PHP 5.1 of Aug 31 no longer functioned). Next I went into c:\windows\php.ini and added the line extension=php_sqlite.dll (the only other extension I have loading is php_shmop.dll). * Note, at the least there seems to be a documentation bug because php.net/sqlite says to add php_extension=php_sqlite.dll * Now when I go to restart apache 2, I get the following confirm alert/msgbox twice: Warning PHP Startup: Unable to load dynamic library './php_sqlite.dll' - The specified module could not be found. This is an exceptionally unhelpful message as a normal person would suspect that there is a problem locating php_sqlite.dll as that is the only thing specified. At any rate, the loading is successful if I also add extension=php_pdo.dll to php.ini and plunk php_pdo.dll into the main directory. Without setting extension nor file for php_pdo_sqlite.dll Thanks, Csaba Gabor from Vienna Expected result: 1. I expect that all I need to run my older code is php_sqlite.dll I do not expect to need php_pdo.dll which I do not currently utilitze in my code. php_pdo.dll should be relying on php_sqlite.dll, if anything, and not the other way around. 2. I expect the docs in http://php.net/sqlite (and perhaps also http://php.net/pdo-sqlite) to mention when I should use only php_sqlite.dll (and set extension), when I need to include php_pdo.dll (and whether I should use php_sqlite.dll with it or php_pdo_sqlite.dll or both). Actual result: -- 1. php_sqlite.dll seems to require php_pdo.dll to function. This seems counterintuitive, at best. 2. A user (me) is sure to wonder how the two ...sqlite.dll come into play. This is in addition/commensurate with being confused about how to swap drivers between v2 and 3 and when one would want to do so. In other words, there seem to be possibilities of with/without pdo, v2 or v3 drivers, and two distinct sqlite dll's. -- Edit bug report at http://bugs.php.net/?id=35345&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=35345&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=35345&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=35345&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=35345&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=35345&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=35345&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=35345&r=needscript Try newer version: http://bugs.php.net/fix.php?id=35345&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=35345&r=support Expected behavior: http://bugs.php.net/fix.php?id=35345&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=35345&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=35345&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=35345&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35345&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=35345&r=dst IIS Stability: http://bugs.php.net/fix.php?id=35345&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=35345&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=35345&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=35345&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=35345&r=mysqlcfg
#35343 [NEW]: phpinfo() produces invalid CSS
From: csaba at alum dot mit dot edu
Operating system: Win XP Pro
PHP version: 5CVS-2005-11-22 (snap)
PHP Bug Type: PHP options/info functions
Bug description: phpinfo() produces invalid CSS
Description:
http://bugs.php.net/35046 reported that for PHP v 5.0.5 on Linux
produces invalid CSS because of
This was supposed to have been fixed two weeks ago in CVS according to the
bug report, but it is still there in PHP v 5.1.0RC7 on my Win XP Pro (just
downloaded and tested). My Firefox javascript console is still
complaining. Since I was not able to reopen that bug, I am filing this
new one.
Csaba Gabor from Vienna
My band aid for this till the fix is:
ob_start();
phpinfo();
$phpinfo = ob_get_contents();
ob_end_clean();
$phpinfo = str_replace("", "", $phpinfo);
print $phpinfo;
--
Edit bug report at http://bugs.php.net/?id=35343&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=35343&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=35343&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=35343&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=35343&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=35343&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=35343&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=35343&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=35343&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=35343&r=support
Expected behavior: http://bugs.php.net/fix.php?id=35343&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=35343&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=35343&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=35343&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35343&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=35343&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=35343&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=35343&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=35343&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=35343&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=35343&r=mysqlcfg
#34470 [NEW]: Open With shows no distinction tween php and php-win
From: csaba at alum dot mit dot edu Operating system: Windows PHP version: 5.1.0RC1 PHP Bug Type: *Compile Issues Bug description: Open With shows no distinction tween php and php-win Description: Quick summary: the Description for php.exe and php-win.exe are the same and this leads to confusion when doing Open With. If (on my Windows XP Pro) I right click a .php file, one of the options is Open With. At this point, I could select Choose Program at the bottom of the list, then select the Browse button, and then navigate to the php directory and select either one of php.exe or php-win.exe (or even php-cgi.exe). If I select one (say php.exe), click Open, then click OK, my PHP script is run (note the dos cmd window flash) - so far so good. Now I go through the same process only select the other one (php-win.exe) and run it (note there is no cmd window flash) - so far still so good. Now I right click that .php file for the third time and pay attention to what is listed under the Open With section. Now it is not so good because I see CLI listed twice, once for php.exe and once for php-win.exe I presume Windows is pulling the name out of the Description field - if you right click either of the two .exe files, you can see that only the Description field has CLI. If would be really good of PHP to update the description field for php-win.exe to something like "Win CLI" to give the user a clue. Csaba Gabor from Vienna -- Edit bug report at http://bugs.php.net/?id=34470&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34470&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=34470&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=34470&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=34470&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=34470&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=34470&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=34470&r=needscript Try newer version: http://bugs.php.net/fix.php?id=34470&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=34470&r=support Expected behavior: http://bugs.php.net/fix.php?id=34470&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=34470&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=34470&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=34470&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34470&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=34470&r=dst IIS Stability: http://bugs.php.net/fix.php?id=34470&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=34470&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=34470&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=34470&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=34470&r=mysqlcfg
#25207 [Com]: multiple auto_prepend_file, auto_append_file
ID: 25207 Comment by: csaba at alum dot mit dot edu Reported By: zeug at delirium dot ch Status: Open Bug Type: Feature/Change Request Operating System: Irrelevant PHP Version: Irrelevant New Comment: I would also find this quite useful as I have some files that I would like to selectively include depending on which virtual host is being accessed. However, I would suggest a semicolon separated list of entries as with the ini setting: include_path Allowing this directive multiple times is not desirable because then it is not overrideable. For example, if your php.ini has a standard set of libraries (.php files) that you use locally, it might make sense to override these in the web server's configuration files (e.g. httpd.conf) Csaba Gabor from Vienna Previous Comments: [2003-08-22 05:29:20] zeug at delirium dot ch Description: Hi Devs I'm referring to bug #3293. Yes, allowing multiple auto_prepend_file/auto_append/file does make sense. Picture this: You have your global configs in a file that's auto prepended. And you want to use a package using auto_prepend_file as well (like my db_auth, see https://www.bitcetera.com/en/project/pear/). You can't include() dbauth to your global config as you don't want to protect all pages. And you don't want to include() your global config in dbauth as this means you have to alter the code of dbauth and trouble arises when new dbauth versions are released. I suggest allowing the following: auto_prepend_file /path/to/inc1.php:/path/to/inc2.php Allowing several auto_prepend_file directires is not a good idea as things would get very messy when using it with .htaccess. Love PHP! -sven -- Edit this bug report at http://bugs.php.net/?id=25207&edit=1
#34463 [Opn->Bgs]: eval/new COM => hang on com_print_typeinfo
ID: 34463
User updated by: csaba at alum dot mit dot edu
Reported By: csaba at alum dot mit dot edu
-Status: Open
+Status: Bogus
Bug Type:Scripting Engine problem
PHP Version: 5CVS-2005-09-11 (snap)
New Comment:
My apologies. When you stare at $newCom and $newCOM they sometimes
look the same, but they aren't.
Csaba
PS. Sniper: now this report is one you could corrupt!
Previous Comments:
[2005-09-11 14:40:50] csaba at alum dot mit dot edu
Description:
If I do eval('$com=new COM("WScript.Shell");');
then gettype($com) is the empty string
while com_print_typeinfo($com) leads to the CLI / Apache error dialog
box asking whether I want to send Microsoft a report about it.
Nevertheless, the $com object is (at least somewhat) valid because I
can subsequently (if I didn't do a com_print_typeinfo) do other things
with it. Thus, gettype is incorrect, and com_print_typeinfo should not
crash PHP.
Csaba Gabor from Vienna
PS. Uncomment any of the 3 new COM lines, and it runs
as expected.
Marked as a Scripting Engine Problem since the
problem seems to start in the eval line.
Reproduce code:
---
\n";
$oEnv = newCOM("WScript.Shell")->Environment("process");
foreach ($oEnv as $idx=>$val) print "$idx: $val\n";
print "";
function newCOM($comSpec) {
$eval = '$newCom = new COM("' . $comSpec . '");';
print ("going to eval: $eval\n");
try { eval($eval); }
catch (Exception $e) {
output("Could not load COM: $comSpec"); return null; }
//$newCOM = new COM("WScript.Shell");
//$newCOM = new COM(&$comSpec);
//$newCOM = new COM($comSpec);
print "newCOM has gettype: " . gettype($newCOM) . "\n";
print " typename: " . typename($newCOM) . "\n\n";
com_print_typeinfo($newCOM);
return $newCom;
}
function typename($objCOM) {
if (is_null($objCOM)) return null;
$oScript = new COM("MSScriptControl.ScriptControl");
$oScript->language = "VBScript";
$oScript->addObject("objCom",$objCOM);
return $oScript->eval("typename(objCom)");
}
?>
Expected result:
After the 'going to eval' line, I expect to see:
newCOM has gettype: object
typename: IWshShell3
Actual result:
--
newCOM has gettype: NULL
typename:
followed by a PHP crash
If you remove the com_print_typeinfo line, the rest of the code
executes as expected. In other words, the COM object functions so the
gettype is still wrong.
--
Edit this bug report at http://bugs.php.net/?id=34463&edit=1
#34463 [NEW]: eval/new COM => hang on com_print_typeinfo
From: csaba at alum dot mit dot edu
Operating system:
PHP version: 5CVS-2005-09-11 (snap)
PHP Bug Type: Scripting Engine problem
Bug description: eval/new COM => hang on com_print_typeinfo
Description:
If I do eval('$com=new COM("WScript.Shell");');
then gettype($com) is the empty string
while com_print_typeinfo($com) leads to the CLI / Apache error dialog box
asking whether I want to send Microsoft a report about it.
Nevertheless, the $com object is (at least somewhat) valid because I can
subsequently (if I didn't do a com_print_typeinfo) do other things with
it. Thus, gettype is incorrect, and com_print_typeinfo should not crash
PHP.
Csaba Gabor from Vienna
PS. Uncomment any of the 3 new COM lines, and it runs
as expected.
Marked as a Scripting Engine Problem since the
problem seems to start in the eval line.
Reproduce code:
---
\n";
$oEnv = newCOM("WScript.Shell")->Environment("process");
foreach ($oEnv as $idx=>$val) print "$idx: $val\n";
print "";
function newCOM($comSpec) {
$eval = '$newCom = new COM("' . $comSpec . '");';
print ("going to eval: $eval\n");
try { eval($eval); }
catch (Exception $e) {
output("Could not load COM: $comSpec"); return null; }
//$newCOM = new COM("WScript.Shell");
//$newCOM = new COM(&$comSpec);
//$newCOM = new COM($comSpec);
print "newCOM has gettype: " . gettype($newCOM) . "\n";
print " typename: " . typename($newCOM) . "\n\n";
com_print_typeinfo($newCOM);
return $newCom;
}
function typename($objCOM) {
if (is_null($objCOM)) return null;
$oScript = new COM("MSScriptControl.ScriptControl");
$oScript->language = "VBScript";
$oScript->addObject("objCom",$objCOM);
return $oScript->eval("typename(objCom)");
}
?>
Expected result:
After the 'going to eval' line, I expect to see:
newCOM has gettype: object
typename: IWshShell3
Actual result:
--
newCOM has gettype: NULL
typename:
followed by a PHP crash
If you remove the com_print_typeinfo line, the rest of the code executes
as expected. In other words, the COM object functions so the gettype is
still wrong.
--
Edit bug report at http://bugs.php.net/?id=34463&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34463&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=34463&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=34463&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=34463&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=34463&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=34463&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=34463&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=34463&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=34463&r=support
Expected behavior: http://bugs.php.net/fix.php?id=34463&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=34463&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=34463&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=34463&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34463&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=34463&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=34463&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=34463&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=34463&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=34463&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=34463&r=mysqlcfg
#34367 [NEW]: strange parsing of auto_prepend_file from CmdPrompt
From: csaba at alum dot mit dot edu
Operating system: Win XP Pro
PHP version: 5CVS-2005-09-04 (CVS)
PHP Bug Type: CGI related
Bug description: strange parsing of auto_prepend_file from CmdPrompt
Description:
In a main script file, or included file, or auto_prepend_file it does not
matter whether doSomething() is before or after function doSomething()
{... does something...}
However, this seems broken when the file is an auto_prepend_file and PHP
is called from the command line in interactive mode.
Specifically, two of the four scenarios below seem incorrect. Scenario 2
is the bug described here, whereas scenario 4 is a separate bug report
(Bug 33430).
Csaba Gabor from Vienna
Reproduce code:
---
Create a file pop.php (test will only work on a windows system because of
the COM component):
Popup($text, 4, $title, 131120);
}
?>
Now from the Cmd Prompt do the following 4 tests:
1. php.exe -d auto_prepend_file=pop.php
2. php.exe -d auto_prepend_file=pop.php -a
3. php.exe -d auto_prepend_file=pop.php pop.php
4. php.exe -d auto_prepend_file=pop.php -r print('Hi');
Expected result:
1,2: I expect to get a single popup and then have PHP wait for input
3: I expect to get a single popup and then PHP should complain about
popup being redifined
4: I should get a single popup and the output should show: Hi
Actual result:
--
1, 3: As expected
2: The reason for this bug report: PHP dies and complains that it
doesn't know what the definition of popup is. Note that if the invocation
of popup is moved below the definition, the popup appears as expected.
4. The only thing that happens is that Hi is printed. The
auto_prepend_file is not loaded so there is no popup. This is a separate
bug report, Bug 33430, at http://bugs.php.net/33430
--
Edit bug report at http://bugs.php.net/?id=34367&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34367&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=34367&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=34367&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=34367&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=34367&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=34367&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=34367&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=34367&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=34367&r=support
Expected behavior: http://bugs.php.net/fix.php?id=34367&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=34367&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=34367&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=34367&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34367&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=34367&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=34367&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=34367&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=34367&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=34367&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=34367&r=mysqlcfg
#33867 [Com]: auto_prepend_file doesn't work in httpd.conf
ID: 33867 Comment by: csaba at alum dot mit dot edu Reported By: t4 at wks dot ch Status: No Feedback Bug Type: *Directory/Filesystem functions Operating System: FreeBSD PHP Version: 4.3.11 New Comment: I have tested this on my system with the 2005 Aug 31 version of PHP 5.0.1 / Apache 2.0.53 / Win XP Pro and cannot reproduce the problem. I can both disable what is in the php.ini with PHP_value auto_prepend_file none or override it with PHP_value auto_prepend_file c:/phplib/prepend_file.php Previous Comments: [2005-08-03 01:00:05] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2005-07-26 17:40:51] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip Can't reproduce it with 4.4.0. [2005-07-26 17:16:51] t4 at wks dot ch Description: Auto_prepend_file in .htaccess works: httpd.conf: AccessFileName .htaccess .htaccess: Php_value auto_prepend_file /absolute_path/prepend_file.php Auto_prepend_file in httpd.conf doesn't work: httpd.conf: httpd.conf: Php_value auto_prepend_file /absolute_path/prepend_file.php httpd.conf: Expected result: The expected result is that /absolute_path/prepend_file.php gets executed. Actual result: -- It does not get executed and there's nothing visibile in the errorlog. -- Edit this bug report at http://bugs.php.net/?id=33867&edit=1
#34297 [Fbk->Opn]: get_object_vars on COM object produces Apache error
ID: 34297
User updated by: csaba at alum dot mit dot edu
Reported By: csaba at alum dot mit dot edu
-Status: Feedback
+Status: Open
Bug Type: COM related
Operating System: Win XP Pro
PHP Version: 5.1.0RC1
New Comment:
I just went to http://snaps.php.net and got the latest binaries:
php5.1-win32-200508310630.zip
The problem still exists for me as originally reported.
Csaba
Previous Comments:
[2005-08-29 16:47:53] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
[2005-08-29 16:22:01] csaba at alum dot mit dot edu
Description:
If I do get_object_vars on a COM object, the code hangs and eventually
I get an Apache HTTP Server error message dialog telling me it's
encountered an error and needs to close and would I like to submit a
report.
If the code should indeed generate an error, shouldn't I be able to
trap for it rather than experience a hang?
Csaba Gabor from Vienna
Reproduce code:
---
\n";
print "gettype of \$oWS: " . gettype($oWS) . "\n";
print " class of \$oWS: " . get_class($oWS) . "\n";
try { print ('(array)$oWS: ');
$Arr = (array)$oWS;
print_r ( $Arr ); }
catch (Exception $e) {
print "(array) casting error.\n"; }
try { print ('get_objectvars($oWS): ');
$Arr = get_object_vars($oWS);
print_r ( $Arr ); }
catch (Exception $e) {
print "get_object_vars error."; }
print "\n";
?>
Expected result:
I expect to get one of:
(1) an array of filled in, accessible properties/values.
(2) an empty array as in the first try block
(3) an error message from the catch block
If you comment out the 5th line, as shown below, then you can see how
it looks when the object is an instance of a class:
// $oWS = new COM("WScript.Shell");
Actual result:
--
The first try/catch block works fine, producing an empty array. It's
the second one that hangs, producing the Apache error dialog (If I use
php.exe I get the same error dialog except with CLI in the title bar).
--
Edit this bug report at http://bugs.php.net/?id=34297&edit=1
#34291 [Opn]: reference comparison: $a isIdenticalTo $b
ID: 34291
User updated by: csaba at alum dot mit dot edu
Reported By: csaba at alum dot mit dot edu
Status: Open
Bug Type:Feature/Change Request
PHP Version: 5.1.0RC1
New Comment:
OK, I was a bit hasty in what I recommended. In particular, there are
two distinct cases: In one case, we want to know whether two
references are the same. In the second, we'd like to know whether the
values of two references are the same. The latter is the same as ===
except for arrays.
So, I have written a function, isIdentical to do both of these. For
the case of arrays and ===, I poke a new element onto one array and see
if it shows up on the other. For the reference checking, I take a
similar approach, except that one has to be careful with arrays,
because any reference pointing to the original array that is poked is
destroyed so this has to be fixed up. That is the reason for the two
foreach loops - it detects self references that were destroyed and
fixes them.
The whole methodology employed in the example below - see what happens
if you poke at it - does not give one the warm fuzzies. I'd still
prefer to see isIdentical implemented as a native PHP function.
function isIdentical(&$ref1, &$ref2, $referencesP=false) {
// if $referencesP is true, isIdentical returns true
// iff $ref1$ref2. That is, if
// $ref2=somethingElse changes $ref1, to
// somethingElse, too (Ie. the same reference)
// if $referencesP is false, isIdentical is the same
// as $ref1===$ref2 for non objects/arrays.
// For objects/arrays $ref1===$ref2 iff a change
// in (a property of) $ref2 is reflected in $ref1
// (ie. the same object/array)
if (gettype($ref1)!=($type=gettype($ref2))) return false;
if ($arrayP=($type=="array")) {
if (count($ref1)!=count($ref2)) return false;
if (!$referencesP) {// are $ref1,$ref2 the same object
$test = "isSameObjectTest";
while (array_key_exists($test, $ref2))
$test .= rand();
if (array_key_exists($test, $ref1)) return false;
$ref2[$test] = 13;
$result = array_key_exists($test,$ref1);
unset ($ref2[$test]);
return $result; }
$aType = array();
foreach ($ref2 as $key=>$val)
$aType[$key] = gettype($val); }
// accounts for objects, too.
elseif (!$referencesP) return $ref1===$ref2;
$tmp = $ref2;
$ref2 = ($type=="string") ? 13 : "fred";
$result = gettype($ref1)!=$type;
// now we must repair the damage
$ref2 = $tmp;
if ($arrayP)
foreach ($ref2 as $key=>&$ref)
if ($aType[$key]!=gettype($ref)) $ref=&$ref2;
return $result;
}
Csaba Gabor from Vienna
references:
//for comparison, see http://php.net/operators.comparison
//http://at2.php.net/manual/en/language.operators.array.php
//http://at2.php.net/manual/en/language.oop5.object-comparison.php
Tested with:
";
print "GLOBALS test " . (isIdentical($GLOBALS,
$GLOBALS["GLOBALS"], true) ? "passed" : "failed");
print "\nDouble test " . (isIdentical($b[1],
$c[1], true) ? "passed\n" : "failed\n");
$c[2] = "test from c";
$b[3] = "test from b";
$a[4] = "test from a";
var_dump($a); print "\n";
var_dump($b); print "\n";
var_dump($c); print "";
?>
Previous Comments:
[2005-08-28 23:02:51] csaba at alum dot mit dot edu
Description:
I would like to recommend a (boolean) operator:
$ref1 isIdenticalTo $ref2
to compare whether two references are identical.
A main use of this is in tree traversal. For example:
$a = array(7);
$a[] = &$a;// we now have a self reference
print $a[1][1][1][0]; // => 7. All is OK
if ($a==$a[1]) print "same"; // Fails
Both $a==$a[1] and $a===$a[1] will fail because the nesting level is
too deep. This is in agreement with the documentation, which says that
values are tested.
If I could do isIdenticalTo however (one could not use with a
straight face), then by placing the references of subarrays encountered
onto an $aVisited array, I could run through them myself and check with
isIdenticalTo and thus avoid exceeding a nesting level.
An example where this (appropriately) happens is with $GLOBALS, since
$GLOBALS["GLOBALS"] isIdenticalTo $GLOBALS.
Thanks for considering this,
Csaba Gabor from Vienna
--
Edit this bug report at http://bugs.php.net/?id=34291&edit=1
#34297 [NEW]: get_object_vars on COM object produces Apache error
From: csaba at alum dot mit dot edu
Operating system: Win XP Pro
PHP version: 5.1.0RC1
PHP Bug Type: COM related
Bug description: get_object_vars on COM object produces Apache error
Description:
If I do get_object_vars on a COM object, the code hangs and eventually I
get an Apache HTTP Server error message dialog telling me it's encountered
an error and needs to close and would I like to submit a report.
If the code should indeed generate an error, shouldn't I be able to trap
for it rather than experience a hang?
Csaba Gabor from Vienna
Reproduce code:
---
\n";
print "gettype of \$oWS: " . gettype($oWS) . "\n";
print " class of \$oWS: " . get_class($oWS) . "\n";
try { print ('(array)$oWS: ');
$Arr = (array)$oWS;
print_r ( $Arr ); }
catch (Exception $e) {
print "(array) casting error.\n"; }
try { print ('get_objectvars($oWS): ');
$Arr = get_object_vars($oWS);
print_r ( $Arr ); }
catch (Exception $e) {
print "get_object_vars error."; }
print "\n";
?>
Expected result:
I expect to get one of:
(1) an array of filled in, accessible properties/values.
(2) an empty array as in the first try block
(3) an error message from the catch block
If you comment out the 5th line, as shown below, then you can see how it
looks when the object is an instance of a class:
// $oWS = new COM("WScript.Shell");
Actual result:
--
The first try/catch block works fine, producing an empty array. It's the
second one that hangs, producing the Apache error dialog (If I use php.exe
I get the same error dialog except with CLI in the title bar).
--
Edit bug report at http://bugs.php.net/?id=34297&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34297&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=34297&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=34297&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=34297&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=34297&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=34297&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=34297&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=34297&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=34297&r=support
Expected behavior: http://bugs.php.net/fix.php?id=34297&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=34297&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=34297&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=34297&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34297&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=34297&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=34297&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=34297&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=34297&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=34297&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=34297&r=mysqlcfg
#34291 [NEW]: reference comparison: $a isIdenticalTo $b
From: csaba at alum dot mit dot edu Operating system: PHP version: 5.1.0RC1 PHP Bug Type: Feature/Change Request Bug description: reference comparison: $a isIdenticalTo $b Description: I would like to recommend a (boolean) operator: $ref1 isIdenticalTo $ref2 to compare whether two references are identical. A main use of this is in tree traversal. For example: $a = array(7); $a[] = &$a;// we now have a self reference print $a[1][1][1][0]; // => 7. All is OK if ($a==$a[1]) print "same"; // Fails Both $a==$a[1] and $a===$a[1] will fail because the nesting level is too deep. This is in agreement with the documentation, which says that values are tested. If I could do isIdenticalTo however (one could not use with a straight face), then by placing the references of subarrays encountered onto an $aVisited array, I could run through them myself and check with isIdenticalTo and thus avoid exceeding a nesting level. An example where this (appropriately) happens is with $GLOBALS, since $GLOBALS["GLOBALS"] isIdenticalTo $GLOBALS. Thanks for considering this, Csaba Gabor from Vienna -- Edit bug report at http://bugs.php.net/?id=34291&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34291&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=34291&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=34291&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=34291&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=34291&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=34291&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=34291&r=needscript Try newer version: http://bugs.php.net/fix.php?id=34291&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=34291&r=support Expected behavior: http://bugs.php.net/fix.php?id=34291&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=34291&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=34291&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=34291&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34291&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=34291&r=dst IIS Stability: http://bugs.php.net/fix.php?id=34291&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=34291&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=34291&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=34291&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=34291&r=mysqlcfg
#34284 [NEW]: CLI phpinfo showing html on _SERVER["argv"]
From: csaba at alum dot mit dot edu Operating system: Win XP Pro PHP version: 5.1.0RC1 PHP Bug Type: CGI related Bug description: CLI phpinfo showing html on _SERVER["argv"] Description: If, from the CMD line of my Win XP Pro, I invoke the CLI php.exe to do: then I see that only the _SERVER["argv"] line has html markup: [0] => - instead of [0] => - That seems incorrect, being at odds with the rest of the output generated, which has no html markup. Csaba Gabor from Vienna Reproduce code: --- php.exe -r "phpinfo();" Expected result: ... [0] => - ... Actual result: -- ... _SERVER["REQUEST_TIME"] => 1125184797 _SERVER["argv"] => Array ( [0] => - ) _SERVER["argc"] => 1 ... -- Edit bug report at http://bugs.php.net/?id=34284&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34284&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=34284&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=34284&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=34284&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=34284&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=34284&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=34284&r=needscript Try newer version: http://bugs.php.net/fix.php?id=34284&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=34284&r=support Expected behavior: http://bugs.php.net/fix.php?id=34284&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=34284&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=34284&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=34284&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34284&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=34284&r=dst IIS Stability: http://bugs.php.net/fix.php?id=34284&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=34284&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=34284&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=34284&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=34284&r=mysqlcfg
#34272 [NEW]: empty array onto COM object blows up
From: csaba at alum dot mit dot edu
Operating system: Win XP
PHP version: 5.1.0RC1
PHP Bug Type: COM related
Bug description: empty array onto COM object blows up
Description:
putting an empty array onto a COM object leads to severe reactions from
the system. Memory usage escalates dramatically (my system showed 1.6G),
the machine slows to a crawl even though system idle does not reflect it,
and it has crashed FF, too, when I had many windows open.
Running this from CLI php.exe produces a noticable delay, but the really
severe reaction comes when running it as a web page.
Csaba Gabor from Vienna
Reproduce code:
---
add('foo', array());
print sizeof($dict['foo']);// bug: large #
$dict->add('bar', array(23));
print " " . sizeof($dict['bar']) . " \n"; // OK: 1
$ie = new COM("InternetExplorer.Application");
$ie->navigate("about:blank"); // to get a document object
$window=$ie->document->parentWindow;
$window->execScript("window.myArray=false"); //placeholder
$window->myArray = array();
print sizeof($window->myArray); // bug: large #
$window->myArray = array(23);
print " " . sizeof($window->myArray); // OK: 1
?>
Expected result:
On the output for the empty arrays, I should get 0 and not some number in
the millions. But especially, running the code above should not lock up
the system.
The last two statements of each of the two code sections are showing
correct behaviour and are not part of the bug.
--
Edit bug report at http://bugs.php.net/?id=34272&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34272&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=34272&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=34272&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=34272&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=34272&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=34272&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=34272&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=34272&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=34272&r=support
Expected behavior: http://bugs.php.net/fix.php?id=34272&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=34272&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=34272&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=34272&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34272&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=34272&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=34272&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=34272&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=34272&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=34272&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=34272&r=mysqlcfg
#34120 [Com]: func_get_arg() can be used function call parameter if used only once
ID: 34120 Comment by: csaba at alum dot mit dot edu Reported By: ondrej at sury dot org Status: Assigned Bug Type: Scripting Engine problem Operating System: * PHP Version: 5CVS, 4CVS (2005-08-013) Assigned To: dmitry New Comment: Note: Because this function depends on the current scope to determine parameter details, it may only appear in the first argument to a function. Thus myfunc1 (myfunc2 (func_get_arg(1), 7)) OK myfunc1 (myfunc2 (7, func_get_arg(0))) Error myfunc1 (7+func_get_arg(0)+func_get_arg(1))OK myfunc2 (func_get_arg(0), func_get_arg(1)) Error If you must pass this value of func_get_arg() not in the first argument, assign the results to a variable, and pass the variable." Csaba Gabor from Vienna Previous Comments: [2005-08-15 23:08:45] [EMAIL PROTECTED] Dmitry, this script should fail for all of those: Expected result: doTitle: 1, doTitle: 2, doTitle: 1, 3 doTitle: 1, 2 Actual result: -- doTitle: 1, doTitle: 2, doTitle: 1, 3 Fatal error: func_get_arg(): Can't be used as a function parameter in /tmp/func_get_arg.php on line 11 -- Edit this bug report at http://bugs.php.net/?id=34120&edit=1
#34094 [Fbk->Opn]: COM hook into PHP class requires class var
ID: 34094
User updated by: csaba at alum dot mit dot edu
Reported By: csaba at alum dot mit dot edu
-Status: Feedback
+Status: Open
Bug Type: Feature/Change Request
Operating System: Windows
PHP Version: 5CVS-2005-08-12 (dev)
New Comment:
I'm sure most of what I'm going to write below is already clear to you,
but better to err with too much info. If it's still lacking, please let
me know. I've only tried this on Win XP Pro, SP 2 and it's to be run
with CLI php. the popup function is so that I get a MsgBox window to
the foreground to help with debugging. The calls to popup in the code
below are there just to illustrate execution order.
The first block of code right after the class definition instantiates
IE and stuffs the web page. It is now set up, except for hooking in
the event handlers.
The next block of 3 lines sets up variable space within IE ($window is
the window object within IE's DOM). Without it, IE doesn't like
foreign apps setting values on its window.varName
The next block sets up the event handlers. The first line where the
class is created is so that IE has a local copy of this PHP object.
(In VB, I would assign an instance of the class that contains the event
handler function to the event handler (eg.
window.document.getElementById('domElemId').onclick=vbClassInstance
When that event is fired, the previously designated default function
within the class (thus I'd need three classes for the three event
handlers) would be called). Trying the same type of assignment that VB
uses did not work however.
Now the hooking up happens in the next three lines (the third one
(escape key detecter) being an extended version for illustrative
purposes of showing what happens with additional arguments).
The first one expands like so:
$window->ExecScript("document.getElementById('btnOK').onclick=function(){window.evtHandler.dummyVar('clickOK')}")
The point of that line is so that the string will execute as javascript
local to the browser. The reason I needed to do that was so I could
assign an anonymous function (the function(){...}) to the event
handler, and the reason I needed to that was so that window.evtHandler
didn't get referenced till an event fired, else it would error or try
to execute code. Thus, I asked IE to do:
document.getElementById('btnOK').onclick=function(){window.evtHandler.dummyVar('clickOK')}
So when the button gets clicked and the .onclick fires, the ... part of
function() {...} is executed in the context of the element clicked on
(that means that 'this' is set to the button element - but we don't
make use of that here)
Thus, when the button is clicked we execute:
window.evtHandler.dummyVar('clickOK')
Now we are at the reason for the bug report. It looks like .dummyVar
is being called like a function (The bug. Furthermore, if I replaced
.dummyVar with .clickOK or any other function from the class I'd get an
error). Instead, the last defined function within the evtHandler's
class is called (this is conceivably correct here since VB uses this
paradigm (and it's not even distressing since I can pass arguments),
but it is an issue in the other bug (33386)), namely __construct.
Furthermore, that 'clickOK' is passed in as an argument (VERY cool. VB
does not let us pass arguments to the default function in this context).
In all the "calls" to dummyVar, my convention is that the first
argument passed is the name of the real function within the evtHandler
class that I want executed. That's really what I would much rather
replace 'dummyVar' with. Ie. I'd rather have
window.evtHandler.clickOK() than window.evtHandler.dummyVar('clickOK')
On the receiving end, __construct is called when the class is first
created, but with no arguments, so we filter out this first invocation
by checking the number of arguments. Every subsequent call from IE,
with the silly .dummyVar style, will have the first argument indicating
the real function that we want to handle the event. The rest of the
arguments (by my convention) are destined for the real intended event
handler function named by the first argument (thus $argsRest). Then
the next line makes the actual call. Note that I use
"".func_get_arg(0) as the name of the function to call. That is
because that 'string' (func_get_arg(0)) is coming from javascript and
PHP views it as an object so I've got to coerce it or else
call_user_func_array is not happy.
Finally, three comments.
(1) The printing of the $ie->hwnd is simply to let me know that PHP is
alive and still in the loop.
(2) The code above works. Run it with php.exe and the browser (IE)
should come up and you should be able to click the buttons and get
popups indicating what you did. This
#34094 [NEW]: COM hook into PHP class requires class var
From: csaba at alum dot mit dot edu
Operating system: Windows
PHP version: 5CVS-2005-08-12 (dev)
PHP Bug Type: COM related
Bug description: COM hook into PHP class requires class var
Description:
This report seems related to http://bugs.php.net/bug.php?id=33386 but as
far as I can tell a distinct phenomenon is occurring. In this report,
there is also only external access to the last function, (but in the VB
analogue, that is OK here as opposed to there) but the access here is
through a var of the class (as opposed to the class itself or a function
of the class) and that seems wrong.
Let me summarize the VB analagous situation, the acutal situation, and
then the distinction between the report above and this one.
1. Summary of the VB situation: In VB, documentation says and testing
confirms that if you connect a DOM event handler directly to a class built
with VB in an .OCX, then if you have marked one of the functions as default
within the class (using Tools / Procedure Attributes / Advanced ... note
that this means one event handler per class), that is the one that will be
executed when the event occurs (note that this differs from the
ScriptControl approach in the prior report where we expect access to all
the class functions). An example connection is made by:
IE.Document.getElementById('elemId').onclick=classInstance
Note also that there is no facility for passing an argument to the class.
2. Summary of actual situation: With PHP in this report, we have to set
a variable in the DOM to the class instance (OK to here) and then to
access the class (here comes the bug:), ===> we must name a var in the
class <=== (as opposed to the class instance itself or the function we
want to access or for that matter (as in the earlier report) any
function). At least we are able to pass arguments.
3. Comparison with prior report: In both reports, we are only able to
access (from an external COM object) the last function in the class, but
in the earlier report that was not expected (in comparison to VB) whereas
it is conceivable here. In the earlier report, to access that last
function any function of the class had to be named whereas here (and the
reason for this report), a var (and not a function) of the class needs to
be named. Frankly, I would expect that other functions are accessible
since some external agent (PHP? COM? javascript?) is discriminating based
on what has been named.
Thanks for considering this,
Csaba Gabor from Vienna
Reproduce code:
---
The code below (watch for possible line wrap) manages to successfully hook
a PHP class to event handlers within the IE DOM (as opposed to event
handlers of the IE COM object). See following section for issues.
Popup($text, $timeout, $title, $style); }
function hookHandler ($wnd, $elemId, $hndlrName) {
$wnd->ExecScript(
"document.getElementById('$elemId')." .
"onclick=function(){window.evtHandler." .
"dummyVar('$hndlrName')}"); }
class evtHandler {
function clickOK(){ popup ("OK was clicked"); }
function clickBtn2() { popup ("Test click"); }
function keyPress($window) {
if ($window->event->keyCode==27) // ESC
$window->doneP=true; }
var $dummyVar;
function __destruct() { popup ("destruction"); }
function __construct() {
if (func_num_args(0)) {
popup("in event handler __construct: ");
$argsRest = array_slice(func_get_args(),1);
call_user_func_array (array(&$this,
"".func_get_arg(0)), $argsRest);
} else popup("initialization __construct");
}
}
$ie = new COM("InternetExplorer.Application");
$ie->visible = true;
$ie->Navigate2("about:blank");
$body ="OK " .
"Test me " .
"" .
"Cancel";
$ie->Document->body->innerHTML .= $body;
$window = $ie->Document->parentWindow;
$window->ExecScript ("window.doneP=false");
$window->ExecScript ("window.evtHandler=false");
$window->evtHandler = new evtHandler();
hookHandler ($window, 'btnOK', 'clickOK');
hookHandler ($window, 'btn2', 'clickBtn2');
$window->ExecScript("document.onkeypress=function(){" .
"window.evtHandler.dummyVar('keyPress',window)}");
try { while (!$window->doneP) {
com_message_pump(600);
print "\n" . $ie->hwnd; }
$ie->Quit(); }
catch (Exception $e) { popup ("IE has gone away"); }
popup("Done with php program");
?>
Expected result:
I expect to name the (non private) function within the class that I'd like
to call for a DOM event handler, and have that function be executed. If it
turns out (because of COM restrictions
#34017 [NEW]: CLI php.exe should allow HTML with phpinfo()
From: csaba at alum dot mit dot edu
Operating system: Windows
PHP version: 5.1.0b3
PHP Bug Type: Feature/Change Request
Bug description: CLI php.exe should allow HTML with phpinfo()
Description:
Using CLI php.exe or php-win.exe on Windows, it is a perfectly reasonable
thing to use COM to bring up Internet Explorer. In fact, it makes a lot
of sense to use it strictly as a graphical output (or I/O) mechanism.
Unfortunately, phpinfo() from these versions of php does not allow the
option of outputting with HTML. Since COM is now supported in PHP5, it
seems that wanting CLI output of phpinfo() to go to a browser will become
more common.
I would therefore like to suggest that either:
(1) phpinfo() respect the html_errors setting or
(2) phpinfo() take a second, optional argument, which, if supplied and non
false, would lead to phpinfo() outputting HTML for CLI php and withholding
the HTML for non CLI php.
Thanks,
Csaba Gabor from Vienna
Note. Running the attached code with php-cgi.exe will illustrate what I
would like: formatted phpinfo() appearing in IE. But I'd like it to work
with php.exe and php-win.exe, too.
Reproduce code:
---
Navigate("about:blank");
$ie->visible = true;
// try to get formatted phpinfo();
ini_set("html_errors", "1");
ob_start();
phpinfo();
$phpinfo = ob_get_contents();
ob_end_clean();
// output it to IE
$ie->Document->Write($phpinfo);
?>
Expected result:
I would expect to get formatted phpinfo() with the supplied code example,
but I only get raw phpinfo().
--
Edit bug report at http://bugs.php.net/?id=34017&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34017&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=34017&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=34017&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=34017&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=34017&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=34017&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=34017&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=34017&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=34017&r=support
Expected behavior: http://bugs.php.net/fix.php?id=34017&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=34017&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=34017&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=34017&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34017&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=34017&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=34017&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=34017&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=34017&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=34017&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=34017&r=mysqlcfg
#34006 [Fbk->Opn]: CLI phpinfo showing html on odbc.default_pw
ID: 34006
User updated by: csaba at alum dot mit dot edu
Reported By: csaba at alum dot mit dot edu
-Status: Feedback
+Status: Open
Bug Type:CGI related
PHP Version: 5.1.0b3
New Comment:
Hi Tony,
I have downloaded from snaps.php.net just now and find that both
issues I reported are still there:
1. the concrete bug report of the () italics are still there when
invoking (CLI) php.exe on the code that I gave (of course, in the code
that I gave you have to search for 'obdc' and then notice that 'no
value' is italicized since the output has gone to the browser). This
is true regardless of whether the ini_set line is invoked or commented
out.
2. The issue that I raised at the end is also not resolved since at
the same time, the output to the browser is otherwise not formatted,
despite having set html_errors to 1
Previous Comments:
[2005-08-05 11:15:33] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
Works just fine here.
[2005-08-05 11:06:51] csaba at alum dot mit dot edu
Description:
If, on my Win XP Pro, I invoke the CLI php.exe or php-win.exe to do:
then I see that only the odbc.default_pw line has html markup:
odbc.default_pw no value no value
That line seems incorrect, being at odds with the rest of the output
generated, which has no html markup.
Expected result:
OK, the reason for this trivial, though real, report is actually to ask
a question, lest I missed something, before filing a suggestion.
A perfectly reasonable thing to do with CLI PHP is to bring up IE and
have it do things, including displaying html formatted phpinfo(), but
the below code will not format it (as is also noted at
http://bugs.php.net/bug.php?id=28405 )
Navigate("about:blank");
$ie->visible = true;
// try to get formatted phpinfo();
ini_set("html_errors", "1");
ob_start();
phpinfo();
$phpinfo = ob_get_contents();
ob_end_clean();
// output it to IE
$ie->Document->Write($phpinfo);
?>
The suggestion that I got at
http://groups-beta.google.com/group/comp.lang.php/browse_frm/thread/8b98f603dcd62123/
was to use the CGI version of PHP. Which works. But that begs the
question of why have the CLI version at all, then.
Thus, my real question is: Wouldn't it make sense to have phpinfo()
respect the html_errors setting, or, have a 2nd, optional argument on
phpinfo() to allow it use the "other" format. Unless it's already
possible or there's a reason not to, I'll presume to file this as a
suggestion.
Thanks,
Csaba Gabor from Vienna
--
Edit this bug report at http://bugs.php.net/?id=34006&edit=1
#34006 [NEW]: CLI phpinfo showing html on odbc.default_pw
From: csaba at alum dot mit dot edu
Operating system:
PHP version: 5.1.0b3
PHP Bug Type: CGI related
Bug description: CLI phpinfo showing html on odbc.default_pw
Description:
If, on my Win XP Pro, I invoke the CLI php.exe or php-win.exe to do:
then I see that only the odbc.default_pw line has html markup:
odbc.default_pw no value no value
That line seems incorrect, being at odds with the rest of the output
generated, which has no html markup.
Expected result:
OK, the reason for this trivial, though real, report is actually to ask a
question, lest I missed something, before filing a suggestion.
A perfectly reasonable thing to do with CLI PHP is to bring up IE and have
it do things, including displaying html formatted phpinfo(), but the below
code will not format it (as is also noted at
http://bugs.php.net/bug.php?id=28405 )
Navigate("about:blank");
$ie->visible = true;
// try to get formatted phpinfo();
ini_set("html_errors", "1");
ob_start();
phpinfo();
$phpinfo = ob_get_contents();
ob_end_clean();
// output it to IE
$ie->Document->Write($phpinfo);
?>
The suggestion that I got at
http://groups-beta.google.com/group/comp.lang.php/browse_frm/thread/8b98f603dcd62123/
was to use the CGI version of PHP. Which works. But that begs the
question of why have the CLI version at all, then.
Thus, my real question is: Wouldn't it make sense to have phpinfo()
respect the html_errors setting, or, have a 2nd, optional argument on
phpinfo() to allow it use the "other" format. Unless it's already
possible or there's a reason not to, I'll presume to file this as a
suggestion.
Thanks,
Csaba Gabor from Vienna
--
Edit bug report at http://bugs.php.net/?id=34006&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34006&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=34006&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=34006&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=34006&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=34006&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=34006&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=34006&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=34006&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=34006&r=support
Expected behavior: http://bugs.php.net/fix.php?id=34006&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=34006&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=34006&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=34006&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34006&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=34006&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=34006&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=34006&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=34006&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=34006&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=34006&r=mysqlcfg
#33386 [Opn]: ScriptControl only sees last function of class
ID: 33386
User updated by: csaba at alum dot mit dot edu
Reported By: csaba at alum dot mit dot edu
Status: Open
Bug Type: COM related
Operating System: Win XP Pro
PHP Version: 5.1.0b1
New Comment:
Sigh...the expected results are actually:
func one
func one
func two
func two
func one
func two
Previous Comments:
[2005-06-17 16:38:14] csaba at alum dot mit dot edu
Description:
When I use a PHP class with the MSScriptControl.ScriptControl object
and want to invoke a function in the class from within the
ScriptControl, I always get the last function from the class regardless
of which one I try to invoke (provided I've used the name of ANY
function in the class - see note on actual result).
If I implement the same thing in VB5 (VBScript with VB5CCE, actually),
this problem does not happen. The code for it is also short and I am
happy to provide it, if it would be useful
Csaba Gabor from Vienna
Reproduce code:
---
Language = "VBScript";
// the object, within the script control, is referred to as tFA
// that final true means that the tFA. may be omitted within the script
control
$oScript->AddObject ("tfA", $ciTF, true);
foreach (array(1,2) as $i) {
$oScript->ExecuteStatement ("tfA.func$i");
$oScript->ExecuteStatement ("func$i");
}
$oScript->AddObject ("tfB", $ciTF);
foreach (array(1,2) as $i)
$oScript->ExecuteStatement ("tfB.func$i");
?>
Expected result:
I expect to see:
func one
func two
func one
func two
func one
func two
Actual result:
--
I see func two repeated 6 times.
In other words, regardless of what function I name, only the last
defined function in the PHP class is executed, which is incorrect.
However, if I attempt to call a function that isn't there, such as
$oScript->ExecuteStatement ("tfA.func3");
then PHP will (correctly) throw an error
This to me says that PHP gets as far as determining whether the
function is there or not, but then it messes up on the indirection.
--
Edit this bug report at http://bugs.php.net/?id=33386&edit=1
#33386 [NEW]: ScriptControl only sees last function of class
From: csaba at alum dot mit dot edu
Operating system: Win XP Pro
PHP version: 5.1.0b1
PHP Bug Type: COM related
Bug description: ScriptControl only sees last function of class
Description:
When I use a PHP class with the MSScriptControl.ScriptControl object and
want to invoke a function in the class from within the ScriptControl, I
always get the last function from the class regardless of which one I try
to invoke (provided I've used the name of ANY function in the class - see
note on actual result).
If I implement the same thing in VB5 (VBScript with VB5CCE, actually),
this problem does not happen. The code for it is also short and I am
happy to provide it, if it would be useful
Csaba Gabor from Vienna
Reproduce code:
---
Language = "VBScript";
// the object, within the script control, is referred to as tFA
// that final true means that the tFA. may be omitted within the script
control
$oScript->AddObject ("tfA", $ciTF, true);
foreach (array(1,2) as $i) {
$oScript->ExecuteStatement ("tfA.func$i");
$oScript->ExecuteStatement ("func$i");
}
$oScript->AddObject ("tfB", $ciTF);
foreach (array(1,2) as $i)
$oScript->ExecuteStatement ("tfB.func$i");
?>
Expected result:
I expect to see:
func one
func two
func one
func two
func one
func two
Actual result:
--
I see func two repeated 6 times.
In other words, regardless of what function I name, only the last defined
function in the PHP class is executed, which is incorrect.
However, if I attempt to call a function that isn't there, such as
$oScript->ExecuteStatement ("tfA.func3");
then PHP will (correctly) throw an error
This to me says that PHP gets as far as determining whether the function
is there or not, but then it messes up on the indirection.
--
Edit bug report at http://bugs.php.net/?id=33386&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33386&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33386&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33386&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33386&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33386&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33386&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33386&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33386&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33386&r=support
Expected behavior: http://bugs.php.net/fix.php?id=33386&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33386&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33386&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33386&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33386&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33386&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33386&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33386&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33386&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33386&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33386&r=mysqlcfg
#31492 [Csd->Opn]: com_event_sink => crash when InternetExplorer.Application navigates away
ID: 31492
User updated by: csaba at alum dot mit dot edu
Reported By: csaba at alum dot mit dot edu
-Status: Closed
+Status: Open
Bug Type: COM related
Operating System: Win XP Pro
-PHP Version: 5.0.3
+PHP Version: 5.0.4
New Comment:
I am sorry to reopen this (and please let me know whether I should have
filed a new bug report on it). However, I have just now realized that
this bug has regressed.
Specifically, the test code in this report was working as expected in
the March 7 (latest) version (which had the intermitent Apache problem
as described earlier). It also works as expected in the latest build
of PHP 5.1.0b1, downloaded today.
However, in both PHP code from March 11 (latest) and 5.0.4 (downloaded
today) the symptoms are the same. If, upon executing the code, I type
google.com into the address bar, I get no output in the DOS window, and
if I then close IE, php.exe remains running. However, there is no
longer a crash.
Csaba Gabor from Vienna
Previous Comments:
[2005-03-09 01:29:01] csaba at alum dot mit dot edu
This is now working pretty spiffy.
The reason that I've taken so long to come back is because of
http://bugs.php.net/bug.php?id=32109&edit=1
Until this bug was fixed, my Apache web server was useless.
Unfortunately, it is now experiencing random intermittent problems
(which is why I don't file a separate problem). The behaviour that I
observe is that apache will report that it has to shut down (Apache
HTTP Server has encountered a problem and needs to close. We are sorry
for the inconvenience.) and ask whether I want to submit a report to
Microsoft. However, I don't actually observe a little red dot in the
icon with the feather in the bottom right of screen and as near as I
can tell apache doesn't die.
The point is that there is some difference between the Feb 19 version
and versions from the Feb 28 onwards that causes the nasty dialog to
appear on my screen. The pages that I'm running are too big, and I
don't have a reliable test case for you at this point.
But anyway, I'm glad to see this bug worked out. Thanks.
[2005-02-28 21:08:35] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
--------
[2005-01-11 16:12:30] csaba at alum dot mit dot edu
Description:
If I run the code below (essentially lifted from
http://www.zend.com/php5/articles/php5-dotnet.php and
http://at2.php.net/manual/en/ref.com.php (superzouz entry from 11 Oct
2003)) then I get the started and com_event_sink lines printed and then
two identical title has changed lines:
title has changed: PHP: Hypertext Preprocessor
So far so good.
If I now go to the IE window and put google.com into the
location bar, and then have it search for something, I may or may not
get additional title has changed messages (sometimes the next one is
even the original php title bar. Ie. when I navigate to Google.com,
the third title has changed line might still be PHP: Hypertext
Preprocessor. But in any case, if I close the window, I will
definitely get an error dialog:
Title: php.exe - Application Error
Text: The instruction at "0x7c911629" referenced memory at
"0x". The memory could not be "written".
Click on OK to terminate the program
Click on CANCEL to debug the program
The actual first location varies, but it has always started with
"0x7c91 The second one is usually all 0s though occasionally it has
low numbers. I have changed the message pump time, and sometimes it
seems like this affects how soon I might get an error, but I haven't
seen anything definitive yet. The problem does not happen if I comment
out the com_event_sink line and the while loop.
I am on Win XP Pro SP2 using IE 6
My antivirus definitions are up to date and Norton Antivirus has found
a clean machine.
If there are other tests that I can do to facilitate tracking this
problem down, please let me know.
My php.ini file is in the same directory as php.exe (I do not have
Apache installed yet and I am running php.exe (from a directory outside
where php.exe lives) from a CMD box.
Possibly related to http://bugs.php.net/bug.php?id=31040&edit=2 ?
Sincerely,
Csaba Gabor from Vienna
Reproduce code:
---
terminated = true;
echo ("Quitting\n");
}
}
$ie = new COM("InternetExplorer.Application");
$ie->Visible = true;
$ie->Navigate("http://www.php.net/";);
$sink = new IESink;
print "started\n";
com_event_sink($ie, $sink, "DW
#31492 [Fbk->Opn]: com_event_sink => crash when InternetExplorer.Application navigates away
ID: 31492
User updated by: csaba at alum dot mit dot edu
Reported By: csaba at alum dot mit dot edu
-Status: Feedback
+Status: Open
Bug Type: COM related
Operating System: Win XP Pro
PHP Version: 5.0.3
New Comment:
This is now working pretty spiffy.
The reason that I've taken so long to come back is because of
http://bugs.php.net/bug.php?id=32109&edit=1
Until this bug was fixed, my Apache web server was useless.
Unfortunately, it is now experiencing random intermittent problems
(which is why I don't file a separate problem). The behaviour that I
observe is that apache will report that it has to shut down (Apache
HTTP Server has encountered a problem and needs to close. We are sorry
for the inconvenience.) and ask whether I want to submit a report to
Microsoft. However, I don't actually observe a little red dot in the
icon with the feather in the bottom right of screen and as near as I
can tell apache doesn't die.
The point is that there is some difference between the Feb 19 version
and versions from the Feb 28 onwards that causes the nasty dialog to
appear on my screen. The pages that I'm running are too big, and I
don't have a reliable test case for you at this point.
But anyway, I'm glad to see this bug worked out. Thanks.
Previous Comments:
[2005-02-28 21:08:35] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
--------
[2005-01-11 17:50:53] csaba at alum dot mit dot edu
Done. This time, I got as far as navigating to Google.com (there were
no additional title has changed lines). Just as I was getting ready to
enter something to search for I got the dreaded error with locations
07c911629 and 006f0044
Clicking OK produced one more error alert with 07c911e58 and
I forgot to mention that the INI file that I used in both cases was the
5.0.3 ini-dist where the only thing I did with it was to uncomment the
first 4 COM entries.
[2005-01-11 16:19:05] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.0-win32-latest.zip
--------
[2005-01-11 16:12:30] csaba at alum dot mit dot edu
Description:
If I run the code below (essentially lifted from
http://www.zend.com/php5/articles/php5-dotnet.php and
http://at2.php.net/manual/en/ref.com.php (superzouz entry from 11 Oct
2003)) then I get the started and com_event_sink lines printed and then
two identical title has changed lines:
title has changed: PHP: Hypertext Preprocessor
So far so good.
If I now go to the IE window and put google.com into the
location bar, and then have it search for something, I may or may not
get additional title has changed messages (sometimes the next one is
even the original php title bar. Ie. when I navigate to Google.com,
the third title has changed line might still be PHP: Hypertext
Preprocessor. But in any case, if I close the window, I will
definitely get an error dialog:
Title: php.exe - Application Error
Text: The instruction at "0x7c911629" referenced memory at
"0x". The memory could not be "written".
Click on OK to terminate the program
Click on CANCEL to debug the program
The actual first location varies, but it has always started with
"0x7c91 The second one is usually all 0s though occasionally it has
low numbers. I have changed the message pump time, and sometimes it
seems like this affects how soon I might get an error, but I haven't
seen anything definitive yet. The problem does not happen if I comment
out the com_event_sink line and the while loop.
I am on Win XP Pro SP2 using IE 6
My antivirus definitions are up to date and Norton Antivirus has found
a clean machine.
If there are other tests that I can do to facilitate tracking this
problem down, please let me know.
My php.ini file is in the same directory as php.exe (I do not have
Apache installed yet and I am running php.exe (from a directory outside
where php.exe lives) from a CMD box.
Possibly related to http://bugs.php.net/bug.php?id=31040&edit=2 ?
Sincerely,
Csaba Gabor from Vienna
Reproduce code:
---
terminated = true;
echo ("Quitting\n");
}
}
$ie = new COM("InternetExplorer.Application");
$ie->Visible = true;
$ie->Navigate("http://www.php.net/";);
$sink = new IESink;
print "started\n";
com_event_sink($ie, $sink, "DW
#31417 [Com]: $HTTP_RAW_POST_DATA but $_POST not populated
ID: 31417 Comment by: csaba at alum dot mit dot edu Reported By: j-spam at starline dot ee Status: Feedback Bug Type: CGI related Operating System: Linux PHP Version: 5.0.3 New Comment: Huge problem. This just started happening on my Win XP Pro (SP 2) machine - checked with both the Feb 28 snapshots and March 1 snapshots. It was not happening on the Feb 19 snapshots, but I think it might be going on since Feb 25 because of: http://bugs.php.net/bug.php?id=32109 I am using Apache 2.0.53 and I have php.ini in c:\windows. Besides that I have the following 4 files in c:\winapps\php.net\latest: php.exe, php-win.exe, php5ts.dll, and php5apache2.dll, a fairly minimalistic setup. Csaba Gabor from Vienna Previous Comments: [2005-02-28 21:07:26] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2005-01-05 16:03:50] j-spam at starline dot ee btw $_GET works. [2005-01-05 15:58:37] j-spam at starline dot ee Typo: "$HTTP_RAW_POST_DATA" not "$_HTTP_RAW_POST_DATA" on Reproduce code, line 2. [2005-01-05 15:55:35] j-spam at starline dot ee Description: $_POST is not populated, however $HTTP_RAW_POST_DATA is. lighttpd 1.3.5 using cgi (not fcgi) CGI-PHP5 5.0.3 Firefox 1.0 Reproduce code: --- $_POST: $HTTP_RAW_POST_DATA: " method="post"> Actual result: -- $_POST: Array ( ) $HTTP_RAW_POST_DATA: bla=asdf&duh=eeca%0D%0Aasdf%0D%0Aasdf -- Edit this bug report at http://bugs.php.net/?id=31417&edit=1
#32109 [Com]: POST data is empty
ID: 32109 Comment by: csaba at alum dot mit dot edu Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Apache2 related Operating System: windows PHP Version: 5CVS-2005-02-25 New Comment: I am also experiencing this problem - I was OK with the Feb 19 PHP snapshot, but by Feb 28, it was not working on my Win XP Pro, SP 2 system (nor was it working with March 1 nor March 3 builds). It happens with both POST data and also when enctype='multipart/form-data'. HOWEVER, as near as I can tell $HTTP_RAW_POST_DATA is populated. I am using Apache 2.0.53 and I have php.ini in c:\windows. Besides that I have the following 4 files in c:\winapps\php.net: php.exe, php-win.exe, php5ts.dll, and php5apache2.dll, a fairly minimalistic setup. My path includes c:\winapps\php.net If you can tell me how I can get the win32 builds for Feb 20-Feb 25, I can test each of them to see when the problem crept in. I couldn't figure this out from http://snaps.php.net/win32 Csaba Gabor from Vienna Note also that http://bugs.php.net/bug.php?id=31417 is very similar Previous Comments: [2005-02-27 17:32:55] [EMAIL PROTECTED] I had apache 2.0.52 and I upgraded it to 2.0.53 and still doesn't work. Any simple script like the above helps to reproduce: '; } ?> [2005-02-27 14:31:36] [EMAIL PROTECTED] Reproduce script? (fyi: works fine here) [2005-02-27 13:54:45] [EMAIL PROTECTED] Sorry Derick, but I don't have any more info. I simply upgraded PHP (that was one or two weeks old) to the most recent CVS version and the POST vars are broken. [2005-02-27 12:32:02] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. [2005-02-25 14:17:59] [EMAIL PROTECTED] Description: The POST form data is always empty, while GET works. In linux with PHP 5.1 built: Feb 20 2005 14:51:15, I don't have any problem. -- Edit this bug report at http://bugs.php.net/?id=32109&edit=1
#28264 [Csd->Opn]: SQLite not doing multiple queries
ID: 28264
User updated by: csaba at alum dot mit dot edu
Reported By: csaba at alum dot mit dot edu
-Status: Closed
+Status: Open
Bug Type: SQLite related
Operating System: Win 2K Pro
PHP Version: 5CVS-2004-05-03 (dev)
New Comment:
This is still behaving in the same way as originally described (just
tested on PHP 5.0.4-dev 11-Mar-2005). Here is slightly nicer code to
show the problem:
Table was created:";
var_dump ($acT);
$aiT = sqlite_array_query ($db, $insertTest, SQLITE_ASSOC);
print "";
if ($aiT)
{print "with rows:"; var_dump ($aiT); }
else print "but nothing was inserted";
?>
Csaba
Previous Comments:
[2004-07-10 15:14:35] [EMAIL PROTECTED]
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
"Fixed" in CVS.
http://cvs.php.net/diff.php/pecl/sqlite/sqlite.c?r1=1.62.2.21&r2=1.62.2.22&ty=u
[2004-05-27 00:15:40] saleh at sfsj dot net
I also want to add that even if you try to use transactions to execute
multiple queries..
I tried to use BEGIN; and BEGIN TRANSACTION; but both of them will not
work and nothing will happen..
------------------------
[2004-05-03 22:41:50] csaba at alum dot mit dot edu
Description:
The sqlite_query page in a prominent box declares that SQLite will
execute multiple queries separated by semicolons, but this seems not to
be the case according to the test below. While I posted a workaround
for this, it is not very efficient because you have to send each query
separately.
I have tested the command line version of SQLite (2.8.13) and it does
accept multiple queries separated by semicolons.
Also, if dealing with this problem, I'd like to suggest that if the
final query is a SELECT or other statement which produces some result
normally destined for the user, that it be returned to the caller that
way. The documentation makes it seems like maybe it will and maybe it
won't, saying it's undefined. In particular, it would be helpful if
SELECT and PRAGMA returned their results. If you indulge me on that,
please extend the functionality to sqlite_array_query.
Thanks,
Csaba Gabor
Reproduce code:
---
$db = sqlite_open(':memory:', 0666, $sqliteerror);
$tbl = "delme";
$multiQuery = "CREATE TABLE $tbl (foo INTEGER PRIMARY KEY, bar TEXT);"
.
"INSERT INTO $tbl VALUES (null, 'Hi Mom');";
$dbRes = sqlite_query ($db, $multiQuery);
$creationTest = "PRAGMA table_info('$tbl');";
$insertTest = "SELECT * FROM $tbl;";
$acT = sqlite_array_query ($db, $creationTest, SQLITE_ASSOC);
var_dump ($acT);
print "Table was created,";
$aiT = sqlite_array_query ($db, $insertTest, SQLITE_ASSOC);
var_dump ($aiT);
print "but nothing was inserted";
Expected result:
I expect to that the SQL INSERT statement was carried out
Actual result:
--
However, SQL statements after the first ';' seem to be ignored. Thus,
the second var_dump only gets an empty array.
--
Edit this bug report at http://bugs.php.net/?id=28264&edit=1
#31493 [Bgs]: navigating to javascript:anything kills IE
ID: 31493
User updated by: csaba at alum dot mit dot edu
Reported By: csaba at alum dot mit dot edu
Status: Bogus
Bug Type: COM related
Operating System: Win XP Pro
PHP Version: 5.0.3
New Comment:
I could only report an observed behaviour. Whether or not the problem
lay with PHP is something I couldn't answer. But since entering the
'uri' manually worked, it was reasonable to report.
For the record, here is the workaround I have found. You should add a
single line, to navigate to about:blank before navigating to a
javascript:protocol. The following will not crash IE:
Navigate("about:blank");
$ie->Visible = true;
$nav = "javascript:alert('hi mom');";
$ie->Navigate($nav);
?>
Previous Comments:
[2005-03-20 23:14:17] [EMAIL PROTECTED]
If IE crashes / doesn't do something, how is it PHP bug? Bogus.
------------------------
[2005-03-18 23:30:06] csaba at alum dot mit dot edu
Visible = true;
$nav = "javascript:alert('hi mom');";
$ie->Navigate($nav);
?>
Fair enough. I mean in the code above IE will vanish and not put up
the alert. If, on the other hand, you put the following line into IE's
address bar, IE will put up the expected alert and not vanish:
javascript:alert('hi mom');
[2005-03-18 19:49:02] [EMAIL PROTECTED]
And with 'original scenario' you mean what? The first example script in
this report? (with the sleep() call?) Or what?
----------------
[2005-03-10 00:59:46] csaba at alum dot mit dot edu
Sorry to reopen this, but I wanted to ensure that this got attention.
I'm not objecting to it being closed, per se, but I don't think it
makes sense to do so without a comment considering that the penultimate
comment says, "Is it working", and the response is "No." Anybody
looking at this in the future (and me looking at it now) is going to
wonder what went on.
It would be good to know whether this is not considered a bug (or is of
the 'not our problem' variety), is a Won't fix situation, or possibly
confused with bug 31492 (since that seems to have already happened
once, but that bug is distinct), or what? But in my most recent
testing, the original scenario still failed.
Csaba
[2005-03-09 01:40:57] csaba at alum dot mit dot edu
I have tried this with the March 7 build and it is still not working in
the same fashion, but I have a bit more information on it. It is tied
to the fact that there is no previous navigation before the
javascript:whatever is hit.
For example,
Hi Mom'";
$nav = "javascript:alert('Hi Mom')";
$ie->Visible = true;
$ie->Navigate($nav);
?>
will vanish IE, but
Hi Mom'";
$nav = "javascript:alert('Hi Mom')";
$ie->Visible = true;
$ie->Navigate("about:blank");
$ie->Navigate($nav);
?>
will keep IE around (you can also use the non alert version). The
point is that the 'pre navigation' to "about:blank" allows the main
navigation to go through somehow.
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/31493
--
Edit this bug report at http://bugs.php.net/?id=31493&edit=1
#31493 [Fbk->Opn]: navigating to javascript:anything kills IE
ID: 31493
User updated by: csaba at alum dot mit dot edu
Reported By: csaba at alum dot mit dot edu
-Status: Feedback
+Status: Open
Bug Type: COM related
Operating System: Win XP Pro
PHP Version: 5.0.3
New Comment:
Visible = true;
$nav = "javascript:alert('hi mom');";
$ie->Navigate($nav);
?>
Fair enough. I mean in the code above IE will vanish and not put up
the alert. If, on the other hand, you put the following line into IE's
address bar, IE will put up the expected alert and not vanish:
javascript:alert('hi mom');
Previous Comments:
[2005-03-18 19:49:02] [EMAIL PROTECTED]
And with 'original scenario' you mean what? The first example script in
this report? (with the sleep() call?) Or what?
--------------------
[2005-03-10 00:59:46] csaba at alum dot mit dot edu
Sorry to reopen this, but I wanted to ensure that this got attention.
I'm not objecting to it being closed, per se, but I don't think it
makes sense to do so without a comment considering that the penultimate
comment says, "Is it working", and the response is "No." Anybody
looking at this in the future (and me looking at it now) is going to
wonder what went on.
It would be good to know whether this is not considered a bug (or is of
the 'not our problem' variety), is a Won't fix situation, or possibly
confused with bug 31492 (since that seems to have already happened
once, but that bug is distinct), or what? But in my most recent
testing, the original scenario still failed.
Csaba
------------------------
[2005-03-09 01:40:57] csaba at alum dot mit dot edu
I have tried this with the March 7 build and it is still not working in
the same fashion, but I have a bit more information on it. It is tied
to the fact that there is no previous navigation before the
javascript:whatever is hit.
For example,
Hi Mom'";
$nav = "javascript:alert('Hi Mom')";
$ie->Visible = true;
$ie->Navigate($nav);
?>
will vanish IE, but
Hi Mom'";
$nav = "javascript:alert('Hi Mom')";
$ie->Visible = true;
$ie->Navigate("about:blank");
$ie->Navigate($nav);
?>
will keep IE around (you can also use the non alert version). The
point is that the 'pre navigation' to "about:blank" allows the main
navigation to go through somehow.
[2005-02-28 21:09:15] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
[2005-01-17 07:46:27] csaba at alum dot mit dot edu
I have replaced the sleep(...) with appropriate com_message_pump(...),
but I still get the same results.
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/31493
--
Edit this bug report at http://bugs.php.net/?id=31493&edit=1
#31493 [Csd->Opn]: navigating to javascript:anything kills IE
ID: 31493
User updated by: csaba at alum dot mit dot edu
Reported By: csaba at alum dot mit dot edu
-Status: Closed
+Status: Open
Bug Type: COM related
Operating System: Win XP Pro
PHP Version: 5.0.3
New Comment:
Sorry to reopen this, but I wanted to ensure that this got attention.
I'm not objecting to it being closed, per se, but I don't think it
makes sense to do so without a comment considering that the penultimate
comment says, "Is it working", and the response is "No." Anybody
looking at this in the future (and me looking at it now) is going to
wonder what went on.
It would be good to know whether this is not considered a bug (or is of
the 'not our problem' variety), is a Won't fix situation, or possibly
confused with bug 31492 (since that seems to have already happened
once, but that bug is distinct), or what? But in my most recent
testing, the original scenario still failed.
Csaba
Previous Comments:
----------------
[2005-03-09 01:40:57] csaba at alum dot mit dot edu
I have tried this with the March 7 build and it is still not working in
the same fashion, but I have a bit more information on it. It is tied
to the fact that there is no previous navigation before the
javascript:whatever is hit.
For example,
Hi Mom'";
$nav = "javascript:alert('Hi Mom')";
$ie->Visible = true;
$ie->Navigate($nav);
?>
will vanish IE, but
Hi Mom'";
$nav = "javascript:alert('Hi Mom')";
$ie->Visible = true;
$ie->Navigate("about:blank");
$ie->Navigate($nav);
?>
will keep IE around (you can also use the non alert version). The
point is that the 'pre navigation' to "about:blank" allows the main
navigation to go through somehow.
[2005-02-28 21:09:15] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
[2005-01-17 07:46:27] csaba at alum dot mit dot edu
I have replaced the sleep(...) with appropriate com_message_pump(...),
but I still get the same results.
[2005-01-17 04:32:22] [EMAIL PROTECTED]
You should never call sleep() in a script that uses COM, as deadlocks
and bad mojo can result. Instead, use com_message_pump() and specify
your delay in milliseconds.
If that doesn't help any, I'll try to look into this problem later in
the week.
[2005-01-17 04:02:24] csaba at alum dot mit dot edu
As a double check, I downloaded, then installed, PHP ver 5.0.4-dev
(cli) (built Jan 17 2005 02:30:00).
Still the same problem. IE goes away (and rings a bell) as soon as the
Navigate is hit.
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/31493
--
Edit this bug report at http://bugs.php.net/?id=31493&edit=1
#31493 [Fbk->Opn]: navigating to javascript:anything kills IE
ID: 31493
User updated by: csaba at alum dot mit dot edu
Reported By: csaba at alum dot mit dot edu
-Status: Feedback
+Status: Open
Bug Type: COM related
Operating System: Win XP Pro
PHP Version: 5.0.3
New Comment:
I have tried this with the March 7 build and it is still not working in
the same fashion, but I have a bit more information on it. It is tied
to the fact that there is no previous navigation before the
javascript:whatever is hit.
For example,
Hi Mom'";
$nav = "javascript:alert('Hi Mom')";
$ie->Visible = true;
$ie->Navigate($nav);
?>
will vanish IE, but
Hi Mom'";
$nav = "javascript:alert('Hi Mom')";
$ie->Visible = true;
$ie->Navigate("about:blank");
$ie->Navigate($nav);
?>
will keep IE around (you can also use the non alert version). The
point is that the 'pre navigation' to "about:blank" allows the main
navigation to go through somehow.
Previous Comments:
[2005-02-28 21:09:15] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
----------------
[2005-01-17 07:46:27] csaba at alum dot mit dot edu
I have replaced the sleep(...) with appropriate com_message_pump(...),
but I still get the same results.
[2005-01-17 04:32:22] [EMAIL PROTECTED]
You should never call sleep() in a script that uses COM, as deadlocks
and bad mojo can result. Instead, use com_message_pump() and specify
your delay in milliseconds.
If that doesn't help any, I'll try to look into this problem later in
the week.
----
[2005-01-17 04:02:24] csaba at alum dot mit dot edu
As a double check, I downloaded, then installed, PHP ver 5.0.4-dev
(cli) (built Jan 17 2005 02:30:00).
Still the same problem. IE goes away (and rings a bell) as soon as the
Navigate is hit.
[2005-01-15 17:35:38] [EMAIL PROTECTED]
You ofcourse need to reboot AFTER you installed 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/31493
--
Edit this bug report at http://bugs.php.net/?id=31493&edit=1
#32038 [NEW]: com_print_typeinfo returning duplicate entries
From: csaba at alum dot mit dot edu
Operating system: Win XP Pro
PHP version: 5CVS-2005-02-20 (dev)
PHP Bug Type: COM related
Bug description: com_print_typeinfo returning duplicate entries
Description:
com_print_typeinfo is often showing duplicate entries for many of the
properties of various COM objects, for example: IWebBrowser2
Reproduce code:
---
Windows();
foreach ($oWins as $oWin) {
com_print_typeinfo($oWin,"IWebBrowser2");
break; }
?>
Expected result:
I expect each property to be listed exactly once
Actual result:
--
Here's part of the printout:
/* DISPID=555 */
/* VT_BOOL [11] */
/* Controls whether address bar is shown */
var $AddressBar;
/* DISPID=555 */
/* Controls whether address bar is shown */
var $AddressBar;
/* DISPID=556 */
/* VT_BOOL [11] */
/* Controls whether the window is resizable */
var $Resizable;
/* DISPID=556 */
/* Controls whether the window is resizable */
var $Resizable;
As you can see, both properties are shown twice. The first of the two
showings always shows the variant type (e.g. VT_BOOL [11]) whereas the
second does not. It seems superfluous to have these shown twice
(especially since the printouts are so voluminous and the second is a
subset of the first). I have not seen this happen with Methods.
Csaba Gabor from Vienna
--
Edit bug report at http://bugs.php.net/?id=32038&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32038&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=32038&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=32038&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=32038&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=32038&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=32038&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=32038&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=32038&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=32038&r=support
Expected behavior: http://bugs.php.net/fix.php?id=32038&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=32038&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=32038&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=32038&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32038&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=32038&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=32038&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=32038&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=32038&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=32038&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=32038&r=mysqlcfg
#32026 [NEW]: Can't call to function with paramArray in arg list definition
From: csaba at alum dot mit dot edu
Operating system: Win XP Pro
PHP version: 5CVS-2005-02-19 (dev)
PHP Bug Type: COM related
Bug description: Can't call to function with paramArray in arg list definition
Description:
If I try to make a call to a function where the function has a paramArray
(a VB construct) in the definition, the call fails with (if the param
array gets at least one argument).
For the unfamiliar, a paramArray in VB is an array (of variants) which
consists of all the remaining arguments to the procedure. As such, it
must be the last declared parameter in the Function declaration.
Csaba Gabor from Vienna
Reproduce code:
---
Here is the PHP test code (menu.php):
ArgCount ("junk", 5, 13);
print $result;
?>
Here is the code for the Menu.OCX file:
Public Function ArgCount(Arg1, ParamArray paArgRest())
'counts the number of arguments passed, excluding Arg1
ArgCount = UBound(paArgRest) + 1 - LBound(paArgRest)
End Function
Notes:
This was built using VB5CCE (the free (while available) VB, Control
Creation Edition)
I have named my control Tool
I have named the Project Menu
I made the OCX into Menu.ocx
In the (VB5CCE) project I went to Project => Menu Properties => Component
tab and set No Compatibility
After I made Menu.OCX, from the directory Menu.ocx resides in, I did:
regsvr32 Menu.ocx
Here is the corresponding VBScript test file (menu.vbs) that works:
Set oTool = CreateObject("Menu.Tool")
result = oTool.ArgCount("junk", 5, 13)
MsgBox result
Expected result:
I expect to see a 2 printed or displayed (since there are two arguments
after "junk")
Actual result:
--
menu.vbs produces the expected 2.
menu.php file fails with:
Cannot pass parameter 2 by reference in C:\Testing\ParamArray\menu.php on
line 3
If the paramArray gets no elements
$result = $oTool->ArgCount ("junk");
then I get the expected 0
I've inserted a
com_print_typeinfo($oTool) and received (there was other code in
menu.ocx):
/* DISPID=1610809344 */
/* VT_VARIANT [12] */
function ArgCount(
/* VT_PTR [26] [in][out] --> VT_VARIANT [12] */ &$Arg1,
/* VT_PTR [26] [in][out] --> ? [27] */ &$paArgRest
)
{
}
--
Edit bug report at http://bugs.php.net/?id=32026&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32026&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=32026&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=32026&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=32026&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=32026&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=32026&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=32026&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=32026&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=32026&r=support
Expected behavior: http://bugs.php.net/fix.php?id=32026&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=32026&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=32026&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=32026&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32026&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=32026&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=32026&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=32026&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=32026&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=32026&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=32026&r=mysqlcfg
#28265 [Fbk->Csd]: Realpath, getcwd not returning true pathname
ID: 28265 User updated by: csaba at alum dot mit dot edu Reported By: csaba at alum dot mit dot edu -Status: Feedback +Status: Closed Bug Type: Directory function related Operating System: Windows - all PHP Version: 5CVS-2004-05-04 (dev) New Comment: Hurrah, hurrah! This looks fixed on my WinXP Pro (SP2)system. I tested with (apache not yet installed): PHP 5.1.0-dev (cli) (built: Jan 26 2005 08:25:49) Thanks, Csaba I tested with: Previous Comments: [2005-01-26 04:52:21] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2004-05-04 00:07:53] csaba at alum dot mit dot edu Description: I am resubmitting this bug report (#17822) since the previous report seems to have been corrupted and all the developer comments gone missing! The bug is still there, too: [18 Jun 2002 6:20pm CEST] csaba at alum dot mit dot edu realpath and getcwd on Windows systems do not actually report the applicable directory, but rather a string that will !strcasecmp() with the true directory: I have a directory name, $dir, on my Win2K system (PHP 4.2.0), but it's in all lower case, and I'd like to get the actual pathname including the capitalizations: Both realpath() and dirname() only muck around with the $dir string and don't hit the file system. Not only that, but getcwd() returns $dir (sans capitalizations) after I've hopped over to it with chdir($dir)! My only solution to this point is to pop up a level and use readdir(...) but this is wasteful, only giving me one level at a time. Isn't there a REAL realpath() for windows? Thanks, Csaba Gabor [27 Jul 2002 11:45am CEST] [EMAIL PROTECTED] Looked into this, it looks possible to implement. Wish me luck :) [10 Oct 2002 10:47pm CEST] [EMAIL PROTECTED] Any news? [27 Oct 2002 7:27pm CET] [EMAIL PROTECTED] This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. [15 Feb 2003 5:38pm CET] csaba at alum dot mit dot edu I have marked this bug as open because of the demonstration below on my PHP 4.3 build date Dec. 20, 2002; Apache 2.0.43 Filter; Win2K Pro system. Here is the test: getcwd Problem " . getcwd(); print "" . realpath(getcwd()); chdir (strtoupper($cwd)); print "" . getcwd(); print "" . realpath(getcwd()); ?> On my system the first 2 directories show in lower case, the last two are in caps. Csaba [15 Feb 2003 7:32pm CET] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip Cannot replicate using latest CVS. [22 Feb 2003 8:03pm CET] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [23 Apr 12:26am CEST] csaba at alum dot mit dot edu I have tested this with the latest snapshot 5.0 RC 2 of April 22 on my Win 2K Pro system and it is still a problem. Here are the outputs that I get (I did an inititial print right after the first cwd() so you can see what windows thinks the directory is): C:\Morph\phpDev\40gNiKU5LQ0C c:\Morph\phpDev\40gniku5lq0c c:\Morph\phpDev\40gniku5lq0c C:\Morph\phpDev\40GNIKU5LQ0C C:\Morph\phpDev\40GNIKU5LQ0C So it appears that the middle part is OK but the drive letter and the final directory need some shoring up. Csaba Gabor Reproduce code: --- getcwd Problem "; chdir (strtolower($cwd)); print "" . getcwd(); print "" . realpath(getcwd()); chdir (strtoupper($cwd)); print "" . getcwd(); print "" . realpath(getcwd()); ?> -- Edit this bug report at http://bugs.php.net/?id=28265&edit=1
#31493 [Fbk->Opn]: navigating to javascript:anything kills IE
ID: 31493 User updated by: csaba at alum dot mit dot edu Reported By: csaba at alum dot mit dot edu -Status: Feedback +Status: Open Bug Type: COM related Operating System: Win XP Pro PHP Version: 5.0.3 New Comment: I have replaced the sleep(...) with appropriate com_message_pump(...), but I still get the same results. Previous Comments: [2005-01-17 04:32:22] [EMAIL PROTECTED] You should never call sleep() in a script that uses COM, as deadlocks and bad mojo can result. Instead, use com_message_pump() and specify your delay in milliseconds. If that doesn't help any, I'll try to look into this problem later in the week. [2005-01-17 04:02:24] csaba at alum dot mit dot edu As a double check, I downloaded, then installed, PHP ver 5.0.4-dev (cli) (built Jan 17 2005 02:30:00). Still the same problem. IE goes away (and rings a bell) as soon as the Navigate is hit. [2005-01-15 17:35:38] [EMAIL PROTECTED] You ofcourse need to reboot AFTER you installed it... [2005-01-14 10:33:59] csaba at alum dot mit dot edu Fair enough. I have just now rebooted, then downloaded and installed PHP ver 5.0.4-dev (cli) (built Jan 14 2005 02:20:54). Still the same problem. IE goes away (and rings a bell) as soon as the Navigate is hit. [2005-01-14 09:09:56] [EMAIL PROTECTED] Reboot... windows sometimes caches DLLs. 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/31493 -- Edit this bug report at http://bugs.php.net/?id=31493&edit=1
#31493 [Fbk->Opn]: navigating to javascript:anything kills IE
ID: 31493 User updated by: csaba at alum dot mit dot edu Reported By: csaba at alum dot mit dot edu -Status: Feedback +Status: Open Bug Type: COM related Operating System: Win XP Pro PHP Version: 5.0.3 New Comment: As a double check, I downloaded, then installed, PHP ver 5.0.4-dev (cli) (built Jan 17 2005 02:30:00). Still the same problem. IE goes away (and rings a bell) as soon as the Navigate is hit. Previous Comments: [2005-01-15 17:35:38] [EMAIL PROTECTED] You ofcourse need to reboot AFTER you installed it... [2005-01-14 10:33:59] csaba at alum dot mit dot edu Fair enough. I have just now rebooted, then downloaded and installed PHP ver 5.0.4-dev (cli) (built Jan 14 2005 02:20:54). Still the same problem. IE goes away (and rings a bell) as soon as the Navigate is hit. [2005-01-14 09:09:56] [EMAIL PROTECTED] Reboot... windows sometimes caches DLLs. [2005-01-14 00:19:52] csaba at alum dot mit dot edu Thanks for looking into this. I downloaded and just now tested with the 13 Jan 04 PHP version 5.0.4.dev and regretably the problem is still there (though I replaced all the files, I did not reboot my PC, however). To ensure it's not a quoting situation, I also tested with: $nav = "javascript:alert(7);"; Csaba [2005-01-13 21:09:17] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.0-win32-latest.zip It's a COM issue... should be fixed in the snapshot 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/31493 -- Edit this bug report at http://bugs.php.net/?id=31493&edit=1
#31493 [Fbk->Opn]: navigating to javascript:anything kills IE
ID: 31493 User updated by: csaba at alum dot mit dot edu Reported By: csaba at alum dot mit dot edu -Status: Feedback +Status: Open Bug Type: COM related Operating System: Win XP Pro PHP Version: 5.0.3 New Comment: Fair enough. I have just now rebooted, then downloaded and installed PHP ver 5.0.4-dev (cli) (built Jan 14 2005 02:20:54). Still the same problem. IE goes away (and rings a bell) as soon as the Navigate is hit. Previous Comments: [2005-01-14 09:09:56] [EMAIL PROTECTED] Reboot... windows sometimes caches DLLs. [2005-01-14 00:19:52] csaba at alum dot mit dot edu Thanks for looking into this. I downloaded and just now tested with the 13 Jan 04 PHP version 5.0.4.dev and regretably the problem is still there (though I replaced all the files, I did not reboot my PC, however). To ensure it's not a quoting situation, I also tested with: $nav = "javascript:alert(7);"; Csaba [2005-01-13 21:09:17] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.0-win32-latest.zip It's a COM issue... should be fixed in the snapshot [2005-01-13 12:30:25] csaba at alum dot mit dot edu I changed this to open since I didn't get a response and thought perhaps it wasn't read. This report was marked duplicate, but I've searched high and low and couldn't find it. Perhaps it was marked duplicate because I submitted the previous (though different) report, too. In any event, if it is a duplicate, it would be exceedingly useful to have a link to the report it duplicates so I can monitor it to see when it's fixed, as this is something I'd use. Csaba Gabor -------------------- [2005-01-11 18:52:44] csaba at alum dot mit dot edu It was certainly not my intention to submit a duplicate bug report - that's a waste of everyone's time. Before starting my writeup, I searched for a similar report, but didn't find one. When I pressed the submit button upon finishing my writeup, PHP searched, but did not find one. And now once again I have searched (scanned about 130 "javascript:" and Navigate reports) but still did not see it. It would be very nice if you would post a link to the report that you reference. Thanks, Csaba Gabor 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/31493 -- Edit this bug report at http://bugs.php.net/?id=31493&edit=1
#31493 [Fbk->Opn]: navigating to javascript:anything kills IE
ID: 31493
User updated by: csaba at alum dot mit dot edu
Reported By: csaba at alum dot mit dot edu
-Status: Feedback
+Status: Open
Bug Type: COM related
Operating System: Win XP Pro
PHP Version: 5.0.3
New Comment:
Thanks for looking into this. I downloaded and just now
tested with the 13 Jan 04 PHP version 5.0.4.dev
and regretably the problem is still there (though I
replaced all the files, I did not reboot my PC, however).
To ensure it's not a quoting situation, I also tested with:
$nav = "javascript:alert(7);";
Csaba
Previous Comments:
[2005-01-13 21:09:17] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.0-win32-latest.zip
It's a COM issue... should be fixed in the snapshot
[2005-01-13 12:30:25] csaba at alum dot mit dot edu
I changed this to open since I didn't get a response and thought
perhaps it wasn't read. This report was marked duplicate, but I've
searched high and low and couldn't find it. Perhaps it was marked
duplicate because I submitted the previous (though different) report,
too.
In any event, if it is a duplicate, it would be exceedingly useful to
have a link to the report it duplicates so I can monitor it to see when
it's fixed, as this is something I'd use.
Csaba Gabor
--------------------
[2005-01-11 18:52:44] csaba at alum dot mit dot edu
It was certainly not my intention to submit a duplicate bug report -
that's a waste of everyone's time. Before starting my writeup, I
searched for a similar report, but didn't find one. When I pressed the
submit button upon finishing my writeup, PHP searched, but did not find
one. And now once again I have searched (scanned about 130
"javascript:" and Navigate reports) but still did not see it.
It would be very nice if you would post a link to the report that you
reference.
Thanks,
Csaba Gabor
[2005-01-11 18:16:12] [EMAIL PROTECTED]
Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same.
Thank you for your interest in PHP.
.
------------------------
[2005-01-11 16:58:26] csaba at alum dot mit dot edu
Description:
If I do
$ie = new COM("InternetExplorer.Application");
$nav = "javascript:alert('hi mom');";
$ie->Navigate($nav);
IE vanishes, but fast
Note, this is run using PHP.exe (CLI) from a CMD box
on a Win XP Pro SP2 machine with IE 6
Thanks,
Csaba Gabor from Vienna
Reproduce code:
---
Visible = true;
$nav = "javascript:document.open();document.write('Hi mom');document.close();";
print "$nav\n";
sleep(3);
$ie->Navigate($nav);
sleep(5);
print "finished!\n";
?>
Expected result:
I expect to see a browser which displays a 'Ready' alert box and 'Hi
Mom' in the browser window.
Actual result:
--
As soon as the $ie->Navigate is called, the bell clinks and IE is gone.
The PHP program continues to run without error.
It doesn't seem to matter what is after the javascript:
It could be as simple as
$nav = "javascript:alert('hi mom');";
or you could get rid of the onload part from $nav in the example I
supplied.
By the way, you can see that IE accepts $nav directly just fine (but
get rid of the backslashes except one each before the inner single
quotes, and of course remove the first " and the trailing "; - In
other words, use what is printed to the CMD screen) by manually copying
it in to the location bar and pressing enter yourself.
--
Edit this bug report at http://bugs.php.net/?id=31493&edit=1
#31493 [Bgs->Opn]: navigating to javascript:anything kills IE
ID: 31493
User updated by: csaba at alum dot mit dot edu
Reported By: csaba at alum dot mit dot edu
-Status: Bogus
+Status: Open
Bug Type: COM related
Operating System: Win XP Pro
PHP Version: 5.0.3
New Comment:
I changed this to open since I didn't get a response and thought
perhaps it wasn't read. This report was marked duplicate, but I've
searched high and low and couldn't find it. Perhaps it was marked
duplicate because I submitted the previous (though different) report,
too.
In any event, if it is a duplicate, it would be exceedingly useful to
have a link to the report it duplicates so I can monitor it to see when
it's fixed, as this is something I'd use.
Csaba Gabor
Previous Comments:
----
[2005-01-11 18:52:44] csaba at alum dot mit dot edu
It was certainly not my intention to submit a duplicate bug report -
that's a waste of everyone's time. Before starting my writeup, I
searched for a similar report, but didn't find one. When I pressed the
submit button upon finishing my writeup, PHP searched, but did not find
one. And now once again I have searched (scanned about 130
"javascript:" and Navigate reports) but still did not see it.
It would be very nice if you would post a link to the report that you
reference.
Thanks,
Csaba Gabor
[2005-01-11 18:16:12] [EMAIL PROTECTED]
Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same.
Thank you for your interest in PHP.
.
------------------------
[2005-01-11 16:58:26] csaba at alum dot mit dot edu
Description:
If I do
$ie = new COM("InternetExplorer.Application");
$nav = "javascript:alert('hi mom');";
$ie->Navigate($nav);
IE vanishes, but fast
Note, this is run using PHP.exe (CLI) from a CMD box
on a Win XP Pro SP2 machine with IE 6
Thanks,
Csaba Gabor from Vienna
Reproduce code:
---
Visible = true;
$nav = "javascript:document.open();document.write('Hi mom');document.close();";
print "$nav\n";
sleep(3);
$ie->Navigate($nav);
sleep(5);
print "finished!\n";
?>
Expected result:
I expect to see a browser which displays a 'Ready' alert box and 'Hi
Mom' in the browser window.
Actual result:
--
As soon as the $ie->Navigate is called, the bell clinks and IE is gone.
The PHP program continues to run without error.
It doesn't seem to matter what is after the javascript:
It could be as simple as
$nav = "javascript:alert('hi mom');";
or you could get rid of the onload part from $nav in the example I
supplied.
By the way, you can see that IE accepts $nav directly just fine (but
get rid of the backslashes except one each before the inner single
quotes, and of course remove the first " and the trailing "; - In
other words, use what is printed to the CMD screen) by manually copying
it in to the location bar and pressing enter yourself.
--
Edit this bug report at http://bugs.php.net/?id=31493&edit=1
#31516 [Fbk->Opn]: Clear screen or ScreenSize
ID: 31516
User updated by: csaba at alum dot mit dot edu
Reported By: csaba at alum dot mit dot edu
-Status: Feedback
+Status: Open
Bug Type: Feature/Change Request
Operating System: Windows
PHP Version: 5.0.3
New Comment:
Thanks Derick, this is exactly the kind of thing that I was looking
for. Unfortunately, as I make it out, there is a problem (and I here
document the steps):
For this to work ANSI.sys must be a driver for the command prompt, but
this will only work under COMMAND.COM. To do this, as described at
http://www.evergreen.edu/biophysics/technotes/program/ansi_esc.htm
and http://support.microsoft.com/default.aspx?scid=kb;en-us;Q101875
I first edit my \windows\system32\CONFIG.NT file by adding to the three
existing lines:
dos=high, umb
device=%SystemRoot%\system32\himem.sys
files=4
the following two lines:
DEVICEhigh=%systemroot%\system32\ANSI.SYS
dosonly
and save it as CONFIGDS.NT
Now I create a new shortcut in windows and point it to
\windows\system32\COMMAND.COM In the advanced section under the
Program tab, for Config filename I put:
%SystemRoot%\SYSTEM32\CONFIGDS.NT
For testing, I make a batch file with a one line entry:
echo {ESC}[2J
where that {ESC} is the escape character (hex 1B)
If I run the batch file, the screen is reset to my expectations.
UNFORTUNATELY, when I try to run PHP, I get the following message:
This program cannot be run in DOS mode.
Unless I've missed something in seems like PHP and the ANSI control
codes are mutually exclusive on Win XP and Win 2K.
Csaba
Previous Comments:
[2005-01-12 16:29:22] [EMAIL PROTECTED]
almost ;-)
[2005-01-12 16:26:58] [EMAIL PROTECTED]
Just send the appropriate escape sequence, afaik this should work:
echo chr(27), "[2H";
[2005-01-12 14:26:03] csaba at alum dot mit dot edu
Description:
>From a command line php.exe invoked from a cmd prompt under Win XP Pro,
I'd like to be able to blank the screen and/or determine the screen
height.
Motivation:
I have a program that takes several hours to run and it shows several
lines of progress statistics, which are periodically updated. I'd like
to keep this presentation professional.
I could simulate what I'm asking by interspersing 1000 "\n" whenever
I'm printing an updated set of stats. However, this puts the info at
the bottom of the screen. If I could programatically determine the
height (since it might be changed/stretched/shrunk by the user) of the
DOS (CMD) screen in lines then I could compensate for it (and if you
give me that, I'd like to know the width, too, please).
Alternately, if there was a simple way to blank the screen with the
cursor starting off at the top left, that might be another way to go
(sort of a PHP issued CLS).
Thanks for considering whether this is possible/reasonable,
Csaba Gabor from Vienna
Note: This is distinct from http://bugs.php.net/bug.php?id=24109
because (1) as I understand it, ncurses does not apply here because it
does not work for DOS/cmd prompts. (2) I want to reuse the current
window.
Apropos: Perhaps an alternate approach (Ie. feature request) is to ask
PHP to return a handle to its parent process. Perhaps it is possible to
query that (using Windows APIs) for its properties.
--
Edit this bug report at http://bugs.php.net/?id=31516&edit=1
#31516 [NEW]: Clear screen or ScreenSize
From: csaba at alum dot mit dot edu Operating system: Windows PHP version: 5.0.3 PHP Bug Type: Feature/Change Request Bug description: Clear screen or ScreenSize Description: >From a command line php.exe invoked from a cmd prompt under Win XP Pro, I'd like to be able to blank the screen and/or determine the screen height. Motivation: I have a program that takes several hours to run and it shows several lines of progress statistics, which are periodically updated. I'd like to keep this presentation professional. I could simulate what I'm asking by interspersing 1000 "\n" whenever I'm printing an updated set of stats. However, this puts the info at the bottom of the screen. If I could programatically determine the height (since it might be changed/stretched/shrunk by the user) of the DOS (CMD) screen in lines then I could compensate for it (and if you give me that, I'd like to know the width, too, please). Alternately, if there was a simple way to blank the screen with the cursor starting off at the top left, that might be another way to go (sort of a PHP issued CLS). Thanks for considering whether this is possible/reasonable, Csaba Gabor from Vienna Note: This is distinct from http://bugs.php.net/bug.php?id=24109 because (1) as I understand it, ncurses does not apply here because it does not work for DOS/cmd prompts. (2) I want to reuse the current window. Apropos: Perhaps an alternate approach (Ie. feature request) is to ask PHP to return a handle to its parent process. Perhaps it is possible to query that (using Windows APIs) for its properties. -- Edit bug report at http://bugs.php.net/?id=31516&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31516&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=31516&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=31516&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=31516&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=31516&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=31516&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=31516&r=needscript Try newer version: http://bugs.php.net/fix.php?id=31516&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=31516&r=support Expected behavior: http://bugs.php.net/fix.php?id=31516&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=31516&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=31516&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=31516&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31516&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=31516&r=dst IIS Stability: http://bugs.php.net/fix.php?id=31516&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=31516&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=31516&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=31516&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=31516&r=mysqlcfg
#31493 [Bgs]: navigating to javascript:anything kills IE
ID: 31493
User updated by: csaba at alum dot mit dot edu
Reported By: csaba at alum dot mit dot edu
Status: Bogus
Bug Type: COM related
Operating System: Win XP Pro
PHP Version: 5.0.3
New Comment:
It was certainly not my intention to submit a duplicate bug report -
that's a waste of everyone's time. Before starting my writeup, I
searched for a similar report, but didn't find one. When I pressed the
submit button upon finishing my writeup, PHP searched, but did not find
one. And now once again I have searched (scanned about 130
"javascript:" and Navigate reports) but still did not see it.
It would be very nice if you would post a link to the report that you
reference.
Thanks,
Csaba Gabor
Previous Comments:
[2005-01-11 18:16:12] [EMAIL PROTECTED]
Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same.
Thank you for your interest in PHP.
.
----
[2005-01-11 16:58:26] csaba at alum dot mit dot edu
Description:
If I do
$ie = new COM("InternetExplorer.Application");
$nav = "javascript:alert('hi mom');";
$ie->Navigate($nav);
IE vanishes, but fast
Note, this is run using PHP.exe (CLI) from a CMD box
on a Win XP Pro SP2 machine with IE 6
Thanks,
Csaba Gabor from Vienna
Reproduce code:
---
Visible = true;
$nav = "javascript:document.open();document.write('Hi mom');document.close();";
print "$nav\n";
sleep(3);
$ie->Navigate($nav);
sleep(5);
print "finished!\n";
?>
Expected result:
I expect to see a browser which displays a 'Ready' alert box and 'Hi
Mom' in the browser window.
Actual result:
--
As soon as the $ie->Navigate is called, the bell clinks and IE is gone.
The PHP program continues to run without error.
It doesn't seem to matter what is after the javascript:
It could be as simple as
$nav = "javascript:alert('hi mom');";
or you could get rid of the onload part from $nav in the example I
supplied.
By the way, you can see that IE accepts $nav directly just fine (but
get rid of the backslashes except one each before the inner single
quotes, and of course remove the first " and the trailing "; - In
other words, use what is printed to the CMD screen) by manually copying
it in to the location bar and pressing enter yourself.
--
Edit this bug report at http://bugs.php.net/?id=31493&edit=1
#31492 [Fbk->Opn]: com_event_sink => crash when InternetExplorer.Application navigates away
ID: 31492
User updated by: csaba at alum dot mit dot edu
Reported By: csaba at alum dot mit dot edu
-Status: Feedback
+Status: Open
Bug Type: Reproducible crash
Operating System: Win XP Pro
PHP Version: 5.0.3
New Comment:
Done. This time, I got as far as navigating to Google.com (there were
no additional title has changed lines). Just as I was getting ready to
enter something to search for I got the dreaded error with locations
07c911629 and 006f0044
Clicking OK produced one more error alert with 07c911e58 and
I forgot to mention that the INI file that I used in both cases was the
5.0.3 ini-dist where the only thing I did with it was to uncomment the
first 4 COM entries.
Previous Comments:
[2005-01-11 16:19:05] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.0-win32-latest.zip
[2005-01-11 16:12:30] csaba at alum dot mit dot edu
Description:
If I run the code below (essentially lifted from
http://www.zend.com/php5/articles/php5-dotnet.php and
http://at2.php.net/manual/en/ref.com.php (superzouz entry from 11 Oct
2003)) then I get the started and com_event_sink lines printed and then
two identical title has changed lines:
title has changed: PHP: Hypertext Preprocessor
So far so good.
If I now go to the IE window and put google.com into the
location bar, and then have it search for something, I may or may not
get additional title has changed messages (sometimes the next one is
even the original php title bar. Ie. when I navigate to Google.com,
the third title has changed line might still be PHP: Hypertext
Preprocessor. But in any case, if I close the window, I will
definitely get an error dialog:
Title: php.exe - Application Error
Text: The instruction at "0x7c911629" referenced memory at
"0x". The memory could not be "written".
Click on OK to terminate the program
Click on CANCEL to debug the program
The actual first location varies, but it has always started with
"0x7c91 The second one is usually all 0s though occasionally it has
low numbers. I have changed the message pump time, and sometimes it
seems like this affects how soon I might get an error, but I haven't
seen anything definitive yet. The problem does not happen if I comment
out the com_event_sink line and the while loop.
I am on Win XP Pro SP2 using IE 6
My antivirus definitions are up to date and Norton Antivirus has found
a clean machine.
If there are other tests that I can do to facilitate tracking this
problem down, please let me know.
My php.ini file is in the same directory as php.exe (I do not have
Apache installed yet and I am running php.exe (from a directory outside
where php.exe lives) from a CMD box.
Possibly related to http://bugs.php.net/bug.php?id=31040&edit=2 ?
Sincerely,
Csaba Gabor from Vienna
Reproduce code:
---
terminated = true;
echo ("Quitting\n");
}
}
$ie = new COM("InternetExplorer.Application");
$ie->Visible = true;
$ie->Navigate("http://www.php.net/";);
$sink = new IESink;
print "started\n";
com_event_sink($ie, $sink, "DWebBrowserEvents2");
print "com_event_sink called\n";
while (!$sink->terminated) {
com_message_pump(1000);
}
print "finished!\n";
?>
--
Edit this bug report at http://bugs.php.net/?id=31492&edit=1
#31493 [NEW]: navigating to javascript:anything kills IE
From: csaba at alum dot mit dot edu
Operating system: Win XP Pro
PHP version: 5.0.3
PHP Bug Type: COM related
Bug description: navigating to javascript:anything kills IE
Description:
If I do
$ie = new COM("InternetExplorer.Application");
$nav = "javascript:alert('hi mom');";
$ie->Navigate($nav);
IE vanishes, but fast
Note, this is run using PHP.exe (CLI) from a CMD box
on a Win XP Pro SP2 machine with IE 6
Thanks,
Csaba Gabor from Vienna
Reproduce code:
---
Visible = true;
$nav = "javascript:document.open();document.write('Hi mom');document.close();";
print "$nav\n";
sleep(3);
$ie->Navigate($nav);
sleep(5);
print "finished!\n";
?>
Expected result:
I expect to see a browser which displays a 'Ready' alert box and 'Hi Mom'
in the browser window.
Actual result:
--
As soon as the $ie->Navigate is called, the bell clinks and IE is gone.
The PHP program continues to run without error.
It doesn't seem to matter what is after the javascript:
It could be as simple as
$nav = "javascript:alert('hi mom');";
or you could get rid of the onload part from $nav in the example I
supplied.
By the way, you can see that IE accepts $nav directly just fine (but get
rid of the backslashes except one each before the inner single quotes, and
of course remove the first " and the trailing "; - In other words, use
what is printed to the CMD screen) by manually copying it in to the
location bar and pressing enter yourself.
--
Edit bug report at http://bugs.php.net/?id=31493&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31493&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=31493&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=31493&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=31493&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=31493&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=31493&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=31493&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=31493&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=31493&r=support
Expected behavior: http://bugs.php.net/fix.php?id=31493&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=31493&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=31493&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=31493&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31493&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=31493&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=31493&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=31493&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=31493&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=31493&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=31493&r=mysqlcfg
#31492 [NEW]: com_event_sink => crash when InternetExplorer.Application navigates away
From: csaba at alum dot mit dot edu
Operating system: Win XP Pro
PHP version: 5.0.3
PHP Bug Type: Reproducible crash
Bug description: com_event_sink => crash when InternetExplorer.Application
navigates away
Description:
If I run the code below (essentially lifted from
http://www.zend.com/php5/articles/php5-dotnet.php and
http://at2.php.net/manual/en/ref.com.php (superzouz entry from 11 Oct
2003)) then I get the started and com_event_sink lines printed and then
two identical title has changed lines:
title has changed: PHP: Hypertext Preprocessor
So far so good.
If I now go to the IE window and put google.com into the location
bar, and then have it search for something, I may or may not get
additional title has changed messages (sometimes the next one is even the
original php title bar. Ie. when I navigate to Google.com, the third
title has changed line might still be PHP: Hypertext Preprocessor. But in
any case, if I close the window, I will definitely get an error dialog:
Title: php.exe - Application Error
Text: The instruction at "0x7c911629" referenced memory at "0x".
The memory could not be "written".
Click on OK to terminate the program
Click on CANCEL to debug the program
The actual first location varies, but it has always started with "0x7c91
The second one is usually all 0s though occasionally it has low numbers.
I have changed the message pump time, and sometimes it seems like this
affects how soon I might get an error, but I haven't seen anything
definitive yet. The problem does not happen if I comment out the
com_event_sink line and the while loop.
I am on Win XP Pro SP2 using IE 6
My antivirus definitions are up to date and Norton Antivirus has found a
clean machine.
If there are other tests that I can do to facilitate tracking this problem
down, please let me know.
My php.ini file is in the same directory as php.exe (I do not have Apache
installed yet and I am running php.exe (from a directory outside where
php.exe lives) from a CMD box.
Possibly related to http://bugs.php.net/bug.php?id=31040&edit=2 ?
Sincerely,
Csaba Gabor from Vienna
Reproduce code:
---
terminated = true;
echo ("Quitting\n");
}
}
$ie = new COM("InternetExplorer.Application");
$ie->Visible = true;
$ie->Navigate("http://www.php.net/";);
$sink = new IESink;
print "started\n";
com_event_sink($ie, $sink, "DWebBrowserEvents2");
print "com_event_sink called\n";
while (!$sink->terminated) {
com_message_pump(1000);
}
print "finished!\n";
?>
--
Edit bug report at http://bugs.php.net/?id=31492&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31492&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=31492&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=31492&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=31492&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=31492&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=31492&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=31492&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=31492&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=31492&r=support
Expected behavior: http://bugs.php.net/fix.php?id=31492&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=31492&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=31492&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=31492&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31492&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=31492&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=31492&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=31492&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=31492&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=31492&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=31492&r=mysqlcfg
#28265 [Bgs->Opn]: Realpath, getcwd not returning true pathname
ID: 28265 User updated by: csaba at alum dot mit dot edu Reported By: csaba at alum dot mit dot edu -Status: Bogus +Status: Open Bug Type: Directory function related Operating System: Windows - all -PHP Version: 5CVS-2004-05-03 (dev) +PHP Version: 5CVS-2004-05-04 (dev) New Comment: This problem is still happening on the latest snapshot of PHP I just downloaded today (2004-May-04). If I run the code I included below on my Win 2000 Pro system, I get three sections, each with distinct capitalization (mixed, lower case, upper case) of the drive letter and trailing directory (the inner parts all match up with mixed case). All 5 lines should appear identical (in mixed case). This is expecially noticable on a browser page where you have proportional fonts. Csaba Gabor Also, that old bug report (17822) functionally does not exist - it's been lost (at least large parts of it). If google can't see it, and I can't find it by searching, and PHP can't find it by searching (when I submit almost the same report), I'd call that lost. So in my book, it's not a duplicate report. And what should I do then? Previous Comments: [2004-05-04 08:55:57] [EMAIL PROTECTED] Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Thank you for your interest in PHP. It\'s also fixed. -------- [2004-05-04 00:07:53] csaba at alum dot mit dot edu Description: I am resubmitting this bug report (#17822) since the previous report seems to have been corrupted and all the developer comments gone missing! The bug is still there, too: [18 Jun 2002 6:20pm CEST] csaba at alum dot mit dot edu realpath and getcwd on Windows systems do not actually report the applicable directory, but rather a string that will !strcasecmp() with the true directory: I have a directory name, $dir, on my Win2K system (PHP 4.2.0), but it's in all lower case, and I'd like to get the actual pathname including the capitalizations: Both realpath() and dirname() only muck around with the $dir string and don't hit the file system. Not only that, but getcwd() returns $dir (sans capitalizations) after I've hopped over to it with chdir($dir)! My only solution to this point is to pop up a level and use readdir(...) but this is wasteful, only giving me one level at a time. Isn't there a REAL realpath() for windows? Thanks, Csaba Gabor [27 Jul 2002 11:45am CEST] [EMAIL PROTECTED] Looked into this, it looks possible to implement. Wish me luck :) [10 Oct 2002 10:47pm CEST] [EMAIL PROTECTED] Any news? [27 Oct 2002 7:27pm CET] [EMAIL PROTECTED] This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. [15 Feb 2003 5:38pm CET] csaba at alum dot mit dot edu I have marked this bug as open because of the demonstration below on my PHP 4.3 build date Dec. 20, 2002; Apache 2.0.43 Filter; Win2K Pro system. Here is the test: getcwd Problem " . getcwd(); print "" . realpath(getcwd()); chdir (strtoupper($cwd)); print "" . getcwd(); print "" . realpath(getcwd()); ?> On my system the first 2 directories show in lower case, the last two are in caps. Csaba [15 Feb 2003 7:32pm CET] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip Cannot replicate using latest CVS. [22 Feb 2003 8:03pm CET] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [23 Apr 12:26am CEST] csaba at alum dot mit dot edu I have tested this with the latest snapshot 5.0 RC 2 of April 22 on my Win 2K Pro system and it is still a problem. Here are the outputs that I get (I did an inititial print right after the first cwd() so you can see what windows thinks the directory is): C:\Morph\phpDev\40gNiKU5LQ0C c:\Morph\phpDev\40gniku5lq0c c:\Morph\phpDev\40gniku5lq0c C:\Morph\phpDev\40GNIKU5LQ0C C:\Morph
#28264 [NEW]: SQLite not doing multiple queries
From: csaba at alum dot mit dot edu
Operating system: Win 2K Pro
PHP version: 5CVS-2004-05-03 (dev)
PHP Bug Type: SQLite related
Bug description: SQLite not doing multiple queries
Description:
The sqlite_query page in a prominent box declares that SQLite will execute
multiple queries separated by semicolons, but this seems not to be the
case according to the test below. While I posted a workaround for this,
it is not very efficient because you have to send each query separately.
I have tested the command line version of SQLite (2.8.13) and it does
accept multiple queries separated by semicolons.
Also, if dealing with this problem, I'd like to suggest that if the final
query is a SELECT or other statement which produces some result normally
destined for the user, that it be returned to the caller that way. The
documentation makes it seems like maybe it will and maybe it won't, saying
it's undefined. In particular, it would be helpful if SELECT and PRAGMA
returned their results. If you indulge me on that, please extend the
functionality to sqlite_array_query.
Thanks,
Csaba Gabor
Reproduce code:
---
$db = sqlite_open(':memory:', 0666, $sqliteerror);
$tbl = "delme";
$multiQuery = "CREATE TABLE $tbl (foo INTEGER PRIMARY KEY, bar TEXT);" .
"INSERT INTO $tbl VALUES (null, 'Hi Mom');";
$dbRes = sqlite_query ($db, $multiQuery);
$creationTest = "PRAGMA table_info('$tbl');";
$insertTest = "SELECT * FROM $tbl;";
$acT = sqlite_array_query ($db, $creationTest, SQLITE_ASSOC);
var_dump ($acT);
print "Table was created,";
$aiT = sqlite_array_query ($db, $insertTest, SQLITE_ASSOC);
var_dump ($aiT);
print "but nothing was inserted";
Expected result:
I expect to that the SQL INSERT statement was carried out
Actual result:
--
However, SQL statements after the first ';' seem to be ignored. Thus, the
second var_dump only gets an empty array.
--
Edit bug report at http://bugs.php.net/?id=28264&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28264&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28264&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=28264&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=28264&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=28264&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=28264&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=28264&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=28264&r=support
Expected behavior: http://bugs.php.net/fix.php?id=28264&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=28264&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=28264&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=28264&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28264&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=28264&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=28264&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=28264&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=28264&r=float
#27990 [NoF->Opn]: sqlite_open() crashing Apache on non sqlite databases
ID: 27990
User updated by: csaba at alum dot mit dot edu
Reported By: csaba at alum dot mit dot edu
-Status: No Feedback
+Status: Open
Bug Type: SQLite related
Operating System: Win 2K
-PHP Version: 5.0.0RC1
+PHP Version: 5CVS-2004-05-03 (dev)
New Comment:
The good news is that the behaviour is markedly better. This time
instead of failing disastrously every other time, it only fails
petulantly every third time.
I tested this both as you asked with the CLI version and also running
PHP as a module. With the CLI version, testing on my small three file
directory, I got behaviour as expected: I got warnings on files SQLITE
didn't like and when I supressed them with the @ in front of
sqlite_open, the result was that I got a report of the single sqlite
database file in the directory. Very nice.
Thus encouraged, I went back to the original scenario and ran the same
file through a browser. Two out of three times, I get the same
behaviour as above. The third time around, however, I get the
following variable error message:
Fatal error: Unknown function: 8å() in C:\Morph\phpDev\php.php on line
28
There are two things I'd like to mention. The first is that the "text"
between the ': ' and ' in' seems to always be garbage characters, and
always different
For the second, I have to clear my throat a bit and mutter something
about Heisenberg's uncertainty principle. The only thing on that line
28 the error message is referring to is the function
sqlite_escape_string. (Ahem. Whenever I test, I submit the PHP code
through a preprocessor that logs the submission. This has been very
stable. The submission is stuffed into a temporary file and after the
logging is done, the browser gets back a header("Location: ...") to the
temporary file. (The directory that I was doing this sqlite testing on
is in a separate tree)).
Therefore, I also created a separate file with just the code I
submitted (surrounded in appropriate tags). The results there were not
so encouraging. Apache is still crashing, and PHP complains about
trivial things like it can't find this or that variable, always in the
dirList function on different lines. Let me know if you need more
info.
The good news is that I deal with this by opening up all the files I
find and scanning their header to see if they're SQLite files, and this
is working fine for me. Why can't SQLite do that? So, although this
problem isn't affecting me cause of my workaround, I figured you'd like
to know the current status of it on my machine.
Csaba Gabor
Previous Comments:
[2004-04-29 15:16:53] [EMAIL PROTECTED]
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.
[2004-04-22 23:30:25] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
What you're trying to do will probably end in tears;
libsqlite has a tendency to clobber files that are not valid sqlite
databases (this is not a PHP problem).
It is possible that PHP is overly sensitive to such a problem, so could
you please try to reproduce this using
the CLI version of PHP?
Use a snapshot from the link above.
------------------------
[2004-04-22 23:10:32] csaba at alum dot mit dot edu
I have tested this with the latest release (April 22 RC 2 beta), and it
still crashes Apache. However, I can be a bit more specific about the
symptoms. I tested on a directory with a small sqlite database log.db
(48K) and a log.php file (6K). Both files were required to produce the
crashing effect.
If I ran the code below (with or without an @ in front of the
sqlite_open) the first time I would get a warning about: database disk
image is malformed ...
(if the @ was not present, as with the code below).
The NEXT Time I invoked the same code is when the Apache would give me
the error message about restarting (and sometimes die). This happens
regardless of whether I remove log.php from the directory tree before
running the test the second time.
Csaba Gabor
[2004-04-21 00:15:23] [EMAIL PROTECTED]
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that
#28265 [NEW]: Realpath, getcwd not returning true pathname
From: csaba at alum dot mit dot edu Operating system: Windows - all PHP version: 5CVS-2004-05-03 (dev) PHP Bug Type: Directory function related Bug description: Realpath, getcwd not returning true pathname Description: I am resubmitting this bug report (#17822) since the previous report seems to have been corrupted and all the developer comments gone missing! The bug is still there, too: [18 Jun 2002 6:20pm CEST] csaba at alum dot mit dot edu realpath and getcwd on Windows systems do not actually report the applicable directory, but rather a string that will !strcasecmp() with the true directory: I have a directory name, $dir, on my Win2K system (PHP 4.2.0), but it's in all lower case, and I'd like to get the actual pathname including the capitalizations: Both realpath() and dirname() only muck around with the $dir string and don't hit the file system. Not only that, but getcwd() returns $dir (sans capitalizations) after I've hopped over to it with chdir($dir)! My only solution to this point is to pop up a level and use readdir(...) but this is wasteful, only giving me one level at a time. Isn't there a REAL realpath() for windows? Thanks, Csaba Gabor [27 Jul 2002 11:45am CEST] [EMAIL PROTECTED] Looked into this, it looks possible to implement. Wish me luck :) [10 Oct 2002 10:47pm CEST] [EMAIL PROTECTED] Any news? [27 Oct 2002 7:27pm CET] [EMAIL PROTECTED] This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. [15 Feb 2003 5:38pm CET] csaba at alum dot mit dot edu I have marked this bug as open because of the demonstration below on my PHP 4.3 build date Dec. 20, 2002; Apache 2.0.43 Filter; Win2K Pro system. Here is the test: getcwd Problem " . getcwd(); print "" . realpath(getcwd()); chdir (strtoupper($cwd)); print "" . getcwd(); print "" . realpath(getcwd()); ?> On my system the first 2 directories show in lower case, the last two are in caps. Csaba [15 Feb 2003 7:32pm CET] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip Cannot replicate using latest CVS. [22 Feb 2003 8:03pm CET] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [23 Apr 12:26am CEST] csaba at alum dot mit dot edu I have tested this with the latest snapshot 5.0 RC 2 of April 22 on my Win 2K Pro system and it is still a problem. Here are the outputs that I get (I did an inititial print right after the first cwd() so you can see what windows thinks the directory is): C:\Morph\phpDev\40gNiKU5LQ0C c:\Morph\phpDev\40gniku5lq0c c:\Morph\phpDev\40gniku5lq0c C:\Morph\phpDev\40GNIKU5LQ0C C:\Morph\phpDev\40GNIKU5LQ0C So it appears that the middle part is OK but the drive letter and the final directory need some shoring up. Csaba Gabor Reproduce code: --- getcwd Problem "; chdir (strtolower($cwd)); print "" . getcwd(); print "" . realpath(getcwd()); chdir (strtoupper($cwd)); print "" . getcwd(); print "" . realpath(getcwd()); ?> -- Edit bug report at http://bugs.php.net/?id=28265&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28265&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28265&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28265&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28265&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28265&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28265&r=needscript Try newer version: http://bugs.php.net/fix.php?id=28265&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28265&r=support Expected behavior: http://bugs.php.net/fix.php?id=28265&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28265&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28265&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28265&r=globals PHP 3 support discontinued: http://bugs.php.net/fi
#28266 [NEW]: Bug Report 17822 has been corrupted
From: csaba at alum dot mit dot edu Operating system: N/A PHP version: Irrelevant PHP Bug Type: Unknown/Other Function Bug description: Bug Report 17822 has been corrupted Description: I submitted bug report 17822 a while back (18 Jun 2002). I came back to it this April and made an update to indicate that it is still a bug. The bug report (not the bug) subsequently desintegrated. In particular, it seems to have been reclassified, but of greater concern is that the developer's comments disappeared, the search page does not locate it under my name 'Csaba' (which is how I find my prior bug reports) NOR did it find it when I resubmitted the entire text under bug report 28265. You can get to the old (corrupted) report by http://bugs.php.net/17822 and the new (reposted) one by http://bugs.php.net/28265 Google is down to a single cached version of the earlier bug report (with all the original comments), so I had to act. I am filing this separately, since this report doesn't concern the substance of the bug. Csaba Gabor from Budapest -- Edit bug report at http://bugs.php.net/?id=28266&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28266&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28266&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28266&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28266&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28266&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28266&r=needscript Try newer version: http://bugs.php.net/fix.php?id=28266&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28266&r=support Expected behavior: http://bugs.php.net/fix.php?id=28266&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28266&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28266&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28266&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28266&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28266&r=dst IIS Stability: http://bugs.php.net/fix.php?id=28266&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28266&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28266&r=float
#17822 [NoF->Opn]: Realpath, getcwd not returning true pathname
ID: 17822 User updated by: csaba at alum dot mit dot edu Reported By: csaba at alum dot mit dot edu -Status: No Feedback +Status: Open Bug Type: Directory function related Operating System: Windows - all PHP Version: 4.3.0 Assigned To: sfox New Comment: I have tested this with the latest snapshot 5.0 RC 2 of April 22 on my Win 2K Pro system and it is still a problem. Here are the outputs that I get (I did an inititial print right after the first cwd() so you can see what windows thinks the directory is): C:\Morph\phpDev\40gNiKU5LQ0C c:\Morph\phpDev\40gniku5lq0c c:\Morph\phpDev\40gniku5lq0c C:\Morph\phpDev\40GNIKU5LQ0C C:\Morph\phpDev\40GNIKU5LQ0C So it appears that the middle part is OK but the drive letter and the final directory need some shoring up. Csaba Gabor Previous Comments: [2003-02-22 20:03:34] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2003-02-15 19:32:04] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip Cannot replicate using latest CVS. [2003-02-15 17:38:53] csaba at alum dot mit dot edu I have marked this bug as open because of the demonstration below on my PHP 4.3 build date Dec. 20, 2002; Apache 2.0.43 Filter; Win2K Pro system. Here is the test: getcwd Problem " . getcwd(); print "" . realpath(getcwd()); chdir (strtoupper($cwd)); print "" . getcwd(); print "" . realpath(getcwd()); ?> On my system the first 2 directories show in lower case, the last two are in caps. Csaba [2002-10-27 19:27:57] [EMAIL PROTECTED] This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. [2002-10-10 22:47:54] [EMAIL PROTECTED] Any news? 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/17822 -- Edit this bug report at http://bugs.php.net/?id=17822&edit=1
#28112 [NEW]: sqlite_query() crashing apache on malformed query
From: csaba at alum dot mit dot edu
Operating system: Win 2K Pro
PHP version: 5CVS-2004-04-22 (dev)
PHP Bug Type: SQLite related
Bug description: sqlite_query() crashing apache on malformed query
Description:
apache dies on an empty query (Apache.exe has generated errors and will be
closed by Windows ...).
Note that it does not die if the second line in the code below is missing
[sqlite_query ($db, "create table frob ..." ]. Also, sqlite_query did
OK.
Csaba Gabor
PS. Note that this appears similar to bug 25502 at
http://bugs.php.net/bug.php?id=25502
Reproduce code:
---
if (!($db = sqlite_open(":memory:", 666, $error))) die ("Couldn't open the
database");
sqlite_query($db, "create table frob (foo INTEGER PRIMARY KEY, bar
text);");
$res = sqlite_array_query($db, "");
print "passed";
Expected result:
I wouldn't expect more than a warning. Taking the entire server down
seems extreme.
--
Edit bug report at http://bugs.php.net/?id=28112&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28112&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28112&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=28112&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=28112&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=28112&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=28112&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=28112&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=28112&r=support
Expected behavior: http://bugs.php.net/fix.php?id=28112&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=28112&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=28112&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=28112&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28112&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=28112&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=28112&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=28112&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=28112&r=float
#28112 [Opn]: sqlite_query() crashing apache on malformed query
ID: 28112
User updated by: csaba at alum dot mit dot edu
Reported By: csaba at alum dot mit dot edu
Status: Open
Bug Type: SQLite related
Operating System: Win 2K Pro
PHP Version: 5CVS-2004-04-22 (dev)
New Comment:
Doggone it. The title was supposed to be sqlite_array_query() crashing
apache on malformed query.
Previous Comments:
[2004-04-23 00:10:10] csaba at alum dot mit dot edu
Description:
apache dies on an empty query (Apache.exe has generated errors and will
be closed by Windows ...).
Note that it does not die if the second line in the code below is
missing [sqlite_query ($db, "create table frob ..." ]. Also,
sqlite_query did OK.
Csaba Gabor
PS. Note that this appears similar to bug 25502 at
http://bugs.php.net/bug.php?id=25502
Reproduce code:
---
if (!($db = sqlite_open(":memory:", 666, $error))) die ("Couldn't open
the database");
sqlite_query($db, "create table frob (foo INTEGER PRIMARY KEY, bar
text);");
$res = sqlite_array_query($db, "");
print "passed";
Expected result:
I wouldn't expect more than a warning. Taking the entire server down
seems extreme.
--
Edit this bug report at http://bugs.php.net/?id=28112&edit=1
#27990 [NoF->Opn]: sqlite_open() crashing Apache on non sqlite databases
ID: 27990
User updated by: csaba at alum dot mit dot edu
Reported By: csaba at alum dot mit dot edu
-Status: No Feedback
+Status: Open
Bug Type: SQLite related
Operating System: Win 2K
PHP Version: 5.0.0RC1
New Comment:
I have tested this with the latest release (April 22 RC 2 beta), and it
still crashes Apache. However, I can be a bit more specific about the
symptoms. I tested on a directory with a small sqlite database log.db
(48K) and a log.php file (6K). Both files were required to produce the
crashing effect.
If I ran the code below (with or without an @ in front of the
sqlite_open) the first time I would get a warning about: database disk
image is malformed ...
(if the @ was not present, as with the code below).
The NEXT Time I invoked the same code is when the Apache would give me
the error message about restarting (and sometimes die). This happens
regardless of whether I remove log.php from the directory tree before
running the test the second time.
Csaba Gabor
Previous Comments:
[2004-04-21 00:15:23] [EMAIL PROTECTED]
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.
[2004-04-14 10:08:49] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
I think this was fixed just recently.
[2004-04-14 07:45:06] csaba at alum dot mit dot edu
Description:
I want to get a list of all SQLite databases under my root directory so
I figured I'd get a list of all the files, open each one using
sqlite_open, and assume those that didn't result in warnings/errors
were keepers.
sqlite_open is extremely unhappy about this and apache 2.0.48 dies.
Reproduce code:
---
$root = "c:\\Your\\Path\\Here";
$aFiles = dirList($root, 2, 1);
for ($i=sizeof($aFiles);$i--;) {
if (!($db=sqlite_open($aFiles[$i],0666,$sqliteerror))) unset
($aFiles[$i]);
else {
if (!sqlite_array_query($db,"SELECT * FROM sqlite_master;",
SQLITE_ASSOC))
unset ($aFiles[$i]);
sqlite_close($db);
}
}
var_dump ($aFiles);
function dirList($path=NULL, $types=2, $levels=1) {
// returns an array of the specified files/directories
// Note that directories are prefixed with a '*'
// This can be eliminated from the line above the return
// $path defaults to the current working directory
// $types: 2 => files; 1 => directories; 3 => both;
// $levels: 1 => look in the $path only; 2 => $path and all children;
// 3 => $path, children, grandchildren; 0 => $path and all
descendants;
// less than 0 => complement of -$levels: everything starting
-$levels down
//e.g. -1 => everthing except $path; -2 => all
descendants except $path + children
$pathSep = strstr(PHP_OS, "WIN") ? "\\" : "/";
if ([EMAIL PROTECTED]) $path = getcwd();
$aRes = array();// result
$aAcc=array(); // accumulate
$aDir = array(realpath($path));
for
($i=$levels>0?$levels++:-1;$i--&&$aDir;$aDir=$aAcc,$aAcc=array())
while ($dir = array_shift($aDir))
foreach (scandir ($dir) as $fileOrDir)
if ($fileOrDir!="." && $fileOrDir!="..") {
if ($isDir = is_dir ($rp="$dir$pathSep$fileOrDir"))
$aAcc[] = $rp;
if ($i<$levels-1 && ($types & (2-$isDir))) $aRes[]
= ($isDir?"*":"") . $rp; }
return $aRes;
}
Expected result:
I expect to get a list of sqlite database files. I expect to be able
to use @sqlite_open and have it fail gracefully (silently) without
taking PHP and Apache with it.
Actual result:
--
The above variant on my system with three files in the directory
(dbFile.db, index.php, index.php~) produced two warnings:
Warning: sqlite_open() [function.sqlite-open]: database disk image is
malformed in .../test.php on sqlite_open line
and showed the dbFile.db as OK
Every other variant crashes apache, such as doing a print of
$aFiles[$i] within the else, or inserting ' || $sqliteerror' as the
second half of the first if, or putting an '@' in front of
sqlite_open.
Thanks,
Csaba Gabor
--
Edit this bug report at http://bugs.php.net/?id=27990&edit=1
#27990 [NEW]: sqlite_open crashing Apache on non sqlite databases
From: csaba at alum dot mit dot edu
Operating system: Win 2K
PHP version: 5.0.0RC1
PHP Bug Type: SQLite related
Bug description: sqlite_open crashing Apache on non sqlite databases
Description:
I want to get a list of all SQLite databases under my root directory so I
figured I'd get a list of all the files, open each one using sqlite_open,
and assume those that didn't result in warnings/errors were keepers.
sqlite_open is extremely unhappy about this and apache 2.0.48 dies.
Reproduce code:
---
$root = "c:\\Your\\Path\\Here";
$aFiles = dirList($root, 2, 1);
for ($i=sizeof($aFiles);$i--;) {
if (!($db=sqlite_open($aFiles[$i],0666,$sqliteerror))) unset
($aFiles[$i]);
else {
if (!sqlite_array_query($db,"SELECT * FROM sqlite_master;",
SQLITE_ASSOC))
unset ($aFiles[$i]);
sqlite_close($db);
}
}
var_dump ($aFiles);
function dirList($path=NULL, $types=2, $levels=1) {
// returns an array of the specified files/directories
// Note that directories are prefixed with a '*'
// This can be eliminated from the line above the return
// $path defaults to the current working directory
// $types: 2 => files; 1 => directories; 3 => both;
// $levels: 1 => look in the $path only; 2 => $path and all children;
// 3 => $path, children, grandchildren; 0 => $path and all
descendants;
// less than 0 => complement of -$levels: everything starting
-$levels down
//e.g. -1 => everthing except $path; -2 => all descendants
except $path + children
$pathSep = strstr(PHP_OS, "WIN") ? "\\" : "/";
if ([EMAIL PROTECTED]) $path = getcwd();
$aRes = array();// result
$aAcc=array(); // accumulate
$aDir = array(realpath($path));
for ($i=$levels>0?$levels++:-1;$i--&&$aDir;$aDir=$aAcc,$aAcc=array())
while ($dir = array_shift($aDir))
foreach (scandir ($dir) as $fileOrDir)
if ($fileOrDir!="." && $fileOrDir!="..") {
if ($isDir = is_dir ($rp="$dir$pathSep$fileOrDir"))
$aAcc[] = $rp;
if ($i<$levels-1 && ($types & (2-$isDir))) $aRes[] =
($isDir?"*":"") . $rp; }
return $aRes;
}
Expected result:
I expect to get a list of sqlite database files. I expect to be able to
use @sqlite_open and have it fail gracefully (silently) without taking PHP
and Apache with it.
Actual result:
--
The above variant on my system with three files in the directory
(dbFile.db, index.php, index.php~) produced two warnings:
Warning: sqlite_open() [function.sqlite-open]: database disk image is
malformed in .../test.php on sqlite_open line
and showed the dbFile.db as OK
Every other variant crashes apache, such as doing a print of $aFiles[$i]
within the else, or inserting ' || $sqliteerror' as the second half of the
first if, or putting an '@' in front of sqlite_open.
Thanks,
Csaba Gabor
--
Edit bug report at http://bugs.php.net/?id=27990&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27990&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27990&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=27990&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=27990&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=27990&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=27990&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=27990&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=27990&r=support
Expected behavior: http://bugs.php.net/fix.php?id=27990&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=27990&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=27990&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=27990&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27990&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=27990&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=27990&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=27990&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=27990&r=float
#27911 [Opn->Csd]: ATTACH DATABASE not working
ID: 27911
User updated by: csaba at alum dot mit dot edu
Reported By: csaba at alum dot mit dot edu
-Status: Open
+Status: Closed
Bug Type: SQLite related
Operating System: Win 2K
PHP Version: 5.0.0RC1
New Comment:
I've been thinking about :memory: as a shared memory object on a per
PHP script basis, but it seems that it is non shared memory on a per
connection basis. So the notion of dumping a database into :memory:
from one connection and being able to transfer that into the :memory:
of another connection is not going to fly.
Csaba
Previous Comments:
[2004-04-14 06:22:55] csaba at alum dot mit dot edu
Thanks for your comments (and sorry about the name typo). The complete
path name has done the trick on my system (and NOT the close database).
I would suppose that what is happening is that in the sqlite_open PHP
is looking in the appropriate directory but the ATTACH is passed to
sqlite which doesn't know what search path PHP is using.
I tested this by inserting the full path into the ATTACH DATABASE line,
doing an insert into the ATTACHED db4.Tab1, and then doing a query on
the original $db1 database connection (without a close of $db1).
But IF it is the case that a sqlite_close is not necessary, then using
':memory:' in place of 'Delme.db1' on the first line and on the ATTACH
DATABASE line should allow the database in memory to be seen. However,
in the subsequent sqlite_array_query I still get: no such table:
db4.Tab1
If it was the case that the database must be closed per your second
comments, then the behaviour with ':memory:' is understandable (since
it's gone).
Csaba Gabor
PS. I just wanted to ensure this got reviewed (since it seems to me
like the case with ':memory:' is not working if your first comments,
per my testing, are correct), so apologies if it was inappropriate to
change status to Open (and in that case please let me know what my
action should have been).
[2004-04-08 04:40:17] [EMAIL PROTECTED]
bah, that's what happens when you get interrupted.
OK, you can't ATTACH a database that you already have
opened elsewhere (like inside PHP); close it first.
[2004-04-08 04:37:42] [EMAIL PROTECTED]
Please try using the full path to the file in your
ATTACH SQL.
PS: it's SQLite, not mysqlite
------------------------
[2004-04-07 17:29:27] csaba at alum dot mit dot edu
Description:
I've been using mysqlite regularly for the past two weeks, no
complaints. However, I cannot seem to do a SQLite ATTACH DATABASE at
all. Variations I have tried: sqlite_popen in place of sqlite_open
(especially when $db1 was ':memory:', closing $db1 before attaching,
using ':memory:' in place of either 'Delme1.db1' or 'Delme2.db1'. I
have also tried this
with and without open_basedir set to "." in my Apache 2.0.48
Csaba Gabor
Reproduce code:
---
$db1 = sqlite_open('Delme.db1', 0666, $sqliteerror);
sqlite_query ($db1, 'DROP TABLE Tab1;');
sqlite_query($db1, "CREATE TABLE Tab1 (Id INTEGER PRIMARY KEY, Fld1
VARCHAR(16));");
sqlite_query ($db1, "INSERT INTO Tab1 VALUES (NULL, 'foo1');");
print "Rows: in DB1: " . sqlite_fetch_single (sqlite_query($db1,
"SELECT COUNT(*) FROM Tab1;"));
$db2 = sqlite_open('Delme.db2', 0666, $sqliteerror);
sqlite_query ($db2, 'DROP TABLE Tab2;');
sqlite_query($db2, "CREATE TABLE Tab2 (Id2 INTEGER PRIMARY KEY, Fld2
VARCHAR(8));");
sqlite_query ($db2, "INSERT INTO Tab2 VALUES (NULL, 'bar2');");
sqlite_query ($db2, "INSERT INTO Tab2 VALUES (NULL, 'bar3');");
print "Rows in DB2: " . sqlite_fetch_single (sqlite_query($db2,
"SELECT COUNT(*) FROM Tab2;"));
@sqlite_query ($db2, "DETACH DATABASE db;");
sqlite_query ($db2, "ATTACH DATABASE 'Delme.db1' AS db4;");
$aRes = sqlite_array_query ($db2, "SELECT * FROM db4.Tab1;");
Expected result:
I expect that I can use the attached database as described at SQLite's
homepage.
Actual result:
--
Instead, in pretty much all the variants that I tried, I get the
following error on the ATTACH DATABASE line:
Warning: sqlite_query() [function.sqlite-query]: cannot attach empty
database: db4 in MyPHPFilesDir/myPHPCode.php on line 15
The following (last) line also gets a complaint but by then the damage
has already been done.
At some point, when I was testing using db3 (in place of where db4 n
#27911 [Bgs->Opn]: ATTACH DATABASE not working
ID: 27911
User updated by: csaba at alum dot mit dot edu
Reported By: csaba at alum dot mit dot edu
-Status: Bogus
+Status: Open
Bug Type: SQLite related
Operating System: Win 2K
PHP Version: 5.0.0RC1
New Comment:
Thanks for your comments (and sorry about the name typo). The complete
path name has done the trick on my system (and NOT the close database).
I would suppose that what is happening is that in the sqlite_open PHP
is looking in the appropriate directory but the ATTACH is passed to
sqlite which doesn't know what search path PHP is using.
I tested this by inserting the full path into the ATTACH DATABASE line,
doing an insert into the ATTACHED db4.Tab1, and then doing a query on
the original $db1 database connection (without a close of $db1).
But IF it is the case that a sqlite_close is not necessary, then using
':memory:' in place of 'Delme.db1' on the first line and on the ATTACH
DATABASE line should allow the database in memory to be seen. However,
in the subsequent sqlite_array_query I still get: no such table:
db4.Tab1
If it was the case that the database must be closed per your second
comments, then the behaviour with ':memory:' is understandable (since
it's gone).
Csaba Gabor
PS. I just wanted to ensure this got reviewed (since it seems to me
like the case with ':memory:' is not working if your first comments,
per my testing, are correct), so apologies if it was inappropriate to
change status to Open (and in that case please let me know what my
action should have been).
Previous Comments:
[2004-04-08 04:40:17] [EMAIL PROTECTED]
bah, that's what happens when you get interrupted.
OK, you can't ATTACH a database that you already have
opened elsewhere (like inside PHP); close it first.
[2004-04-08 04:37:42] [EMAIL PROTECTED]
Please try using the full path to the file in your
ATTACH SQL.
PS: it's SQLite, not mysqlite
------------------------
[2004-04-07 17:29:27] csaba at alum dot mit dot edu
Description:
I've been using mysqlite regularly for the past two weeks, no
complaints. However, I cannot seem to do a SQLite ATTACH DATABASE at
all. Variations I have tried: sqlite_popen in place of sqlite_open
(especially when $db1 was ':memory:', closing $db1 before attaching,
using ':memory:' in place of either 'Delme1.db1' or 'Delme2.db1'. I
have also tried this
with and without open_basedir set to "." in my Apache 2.0.48
Csaba Gabor
Reproduce code:
---
$db1 = sqlite_open('Delme.db1', 0666, $sqliteerror);
sqlite_query ($db1, 'DROP TABLE Tab1;');
sqlite_query($db1, "CREATE TABLE Tab1 (Id INTEGER PRIMARY KEY, Fld1
VARCHAR(16));");
sqlite_query ($db1, "INSERT INTO Tab1 VALUES (NULL, 'foo1');");
print "Rows: in DB1: " . sqlite_fetch_single (sqlite_query($db1,
"SELECT COUNT(*) FROM Tab1;"));
$db2 = sqlite_open('Delme.db2', 0666, $sqliteerror);
sqlite_query ($db2, 'DROP TABLE Tab2;');
sqlite_query($db2, "CREATE TABLE Tab2 (Id2 INTEGER PRIMARY KEY, Fld2
VARCHAR(8));");
sqlite_query ($db2, "INSERT INTO Tab2 VALUES (NULL, 'bar2');");
sqlite_query ($db2, "INSERT INTO Tab2 VALUES (NULL, 'bar3');");
print "Rows in DB2: " . sqlite_fetch_single (sqlite_query($db2,
"SELECT COUNT(*) FROM Tab2;"));
@sqlite_query ($db2, "DETACH DATABASE db;");
sqlite_query ($db2, "ATTACH DATABASE 'Delme.db1' AS db4;");
$aRes = sqlite_array_query ($db2, "SELECT * FROM db4.Tab1;");
Expected result:
I expect that I can use the attached database as described at SQLite's
homepage.
Actual result:
--
Instead, in pretty much all the variants that I tried, I get the
following error on the ATTACH DATABASE line:
Warning: sqlite_query() [function.sqlite-query]: cannot attach empty
database: db4 in MyPHPFilesDir/myPHPCode.php on line 15
The following (last) line also gets a complaint but by then the damage
has already been done.
At some point, when I was testing using db3 (in place of where db4 now
is), I got the complaint that the database (db3) was already in use. I
don't know how that complaint started originating, nor could I get rid
of it. Going to db4 got me back to the usual complaint I indicated
above.
--
Edit this bug report at http://bugs.php.net/?id=27911&edit=1
#27911 [NEW]: ATTACH DATABASE not working
From: csaba at alum dot mit dot edu
Operating system: Win 2K
PHP version: 5.0.0RC1
PHP Bug Type: SQLite related
Bug description: ATTACH DATABASE not working
Description:
I've been using mysqlite regularly for the past two weeks, no complaints.
However, I cannot seem to do a SQLite ATTACH DATABASE at all. Variations
I have tried: sqlite_popen in place of sqlite_open (especially when $db1
was ':memory:', closing $db1 before attaching, using ':memory:' in place
of either 'Delme1.db1' or 'Delme2.db1'. I have also tried this
with and without open_basedir set to "." in my Apache 2.0.48
Csaba Gabor
Reproduce code:
---
$db1 = sqlite_open('Delme.db1', 0666, $sqliteerror);
sqlite_query ($db1, 'DROP TABLE Tab1;');
sqlite_query($db1, "CREATE TABLE Tab1 (Id INTEGER PRIMARY KEY, Fld1
VARCHAR(16));");
sqlite_query ($db1, "INSERT INTO Tab1 VALUES (NULL, 'foo1');");
print "Rows: in DB1: " . sqlite_fetch_single (sqlite_query($db1,
"SELECT COUNT(*) FROM Tab1;"));
$db2 = sqlite_open('Delme.db2', 0666, $sqliteerror);
sqlite_query ($db2, 'DROP TABLE Tab2;');
sqlite_query($db2, "CREATE TABLE Tab2 (Id2 INTEGER PRIMARY KEY, Fld2
VARCHAR(8));");
sqlite_query ($db2, "INSERT INTO Tab2 VALUES (NULL, 'bar2');");
sqlite_query ($db2, "INSERT INTO Tab2 VALUES (NULL, 'bar3');");
print "Rows in DB2: " . sqlite_fetch_single (sqlite_query($db2,
"SELECT COUNT(*) FROM Tab2;"));
@sqlite_query ($db2, "DETACH DATABASE db;");
sqlite_query ($db2, "ATTACH DATABASE 'Delme.db1' AS db4;");
$aRes = sqlite_array_query ($db2, "SELECT * FROM db4.Tab1;");
Expected result:
I expect that I can use the attached database as described at SQLite's
homepage.
Actual result:
--
Instead, in pretty much all the variants that I tried, I get the following
error on the ATTACH DATABASE line:
Warning: sqlite_query() [function.sqlite-query]: cannot attach empty
database: db4 in MyPHPFilesDir/myPHPCode.php on line 15
The following (last) line also gets a complaint but by then the damage has
already been done.
At some point, when I was testing using db3 (in place of where db4 now
is), I got the complaint that the database (db3) was already in use. I
don't know how that complaint started originating, nor could I get rid of
it. Going to db4 got me back to the usual complaint I indicated above.
--
Edit bug report at http://bugs.php.net/?id=27911&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27911&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27911&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=27911&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=27911&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=27911&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=27911&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=27911&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=27911&r=support
Expected behavior: http://bugs.php.net/fix.php?id=27911&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=27911&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=27911&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=27911&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27911&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=27911&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=27911&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=27911&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=27911&r=float
#24095 [Com]: phpinfo styles override page styles and damage appearance
ID: 24095 Comment by: csaba at alum dot mit dot edu Reported By: generic at thetahat dot com Status: Open Bug Type: Feature/Change Request Operating System: Windows XP SP1 PHP Version: 4.3.2 New Comment: Yes, phpinfo is a super function, but it should also be a nice player and please not hog the styles on my previously generated elements. Here's an example that illustrates this (tried on IE6 on Win2K with PHP 5.0.0RC1). The TEXTAREA element is supposed to fill the first (multi rowspan) TD element. if you uncomment the phpinfo line at the bottom, then you'll see that the TEXTAREA element nearly disappears. This is because the style sheet genereated by phpinfo sets the TD style to have vertical-align:baseline. Notice that the body color changes for similar reasons. And the links would change, too, if I had them. Csaba Gabor PHP output result page This should ALREADY fill the cell One Two Three Previous Comments: [2003-06-09 08:52:30] generic at thetahat dot com I'm all for using styles on the phpinfo output but since it's redefining basic page elements it's difficult to include phpinfo output on a page when debugging. The choice of style names are all that need to change. For instance, instead of redefining "table", use a class name like #phpinfotable and instead of a basic names like ".e" use ".phpinfocell", instead of "h1" use "h1.phpinfo", "a:link#phpinfo", etc. -- Edit this bug report at http://bugs.php.net/?id=24095&edit=1
#27494 [Bgs]: Multiple clients messing up file reading
ID: 27494
User updated by: csaba at alum dot mit dot edu
Reported By: csaba at alum dot mit dot edu
Status: Bogus
Bug Type: Output Control
Operating System: Win2K
PHP Version: 4.3.4
New Comment:
Thanks for the feedback, you are correct. I'm adding this in case
anyone wanders into this and wanders about it:
The problem was due to javascript. By replacing the line which
continues to reset the javascript (...scripts[0].src = ...) source with
a "timeout" construct the problem was resolved. Evidently, multiple
browsers did not like initiating a replace until the prior javascript
had finished loading.
Csaba
Previous Comments:
[2004-03-06 13:33:30] [EMAIL PROTECTED]
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.
Thank you for your interest in PHP.
Support request are to be addressed of PHP's general
mailing list, not the bug system.
[2004-03-04 08:48:19] csaba at alum dot mit dot edu
Description:
I'm way sorry for posting this here since the culprit is unclear, but
you guys have the best response. I've written a (non polling) script
to simulate sockets on localhost. Web page A at
http://localhost/test/In.php is a page that the user enters some text
with and it gets written into a file.
Meanwhile, web page B at http://localhost/test/Out.php is looking at
this file and when it changes, it will update web page B with the new
text. This is working fine.
Now introduce web page C at the same http://localhost/test/Out.php In
this case, the second page of B and C to be user refreshed/invoked will
notice the change from page A, and after that it stops refreshing,
too.
Something is clearly wrong, but is it PHP 4.3, Apache 2.0.43, IE 5.5,
or (gasp) my code? I have also coded file_get_contents manually with
the same results.
Reproduce code:
---
In the test directory have 3 files:
In.php:
Input page
Enter a word:
Out.php:
Output page
function openSocket() { document.scripts[0].src = "socket.php"; }
Your output word is:
Socket.php
http://localhost/test/Out.php that they will all update right
away when In.php changes the contents of myWord.txt
Actual result:
--
Only the latter of the two Out.php windows is updated a single time.
--
Edit this bug report at http://bugs.php.net/?id=27494&edit=1
#27494 [NEW]: Multiple clients messing up file reading
From: csaba at alum dot mit dot edu
Operating system: Win2K
PHP version: 4.3.4
PHP Bug Type: Output Control
Bug description: Multiple clients messing up file reading
Description:
I'm way sorry for posting this here since the culprit is unclear, but you
guys have the best response. I've written a (non polling) script to
simulate sockets on localhost. Web page A at http://localhost/test/In.php
is a page that the user enters some text with and it gets written into a
file.
Meanwhile, web page B at http://localhost/test/Out.php is looking at this
file and when it changes, it will update web page B with the new text.
This is working fine.
Now introduce web page C at the same http://localhost/test/Out.php In
this case, the second page of B and C to be user refreshed/invoked will
notice the change from page A, and after that it stops refreshing, too.
Something is clearly wrong, but is it PHP 4.3, Apache 2.0.43, IE 5.5, or
(gasp) my code? I have also coded file_get_contents manually with the
same results.
Reproduce code:
---
In the test directory have 3 files:
In.php:
Input page
Enter a word:
Out.php:
Output page
function openSocket() { document.scripts[0].src = "socket.php"; }
Your output word is:
Socket.php
http://localhost/test/Out.php that they will all update right
away when In.php changes the contents of myWord.txt
Actual result:
--
Only the latter of the two Out.php windows is updated a single time.
--
Edit bug report at http://bugs.php.net/?id=27494&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27494&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27494&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=27494&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=27494&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=27494&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=27494&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=27494&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=27494&r=support
Expected behavior: http://bugs.php.net/fix.php?id=27494&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=27494&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=27494&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=27494&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27494&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=27494&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=27494&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=27494&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=27494&r=float
#22366 [NEW]: PREG_OFFSET_CAPTURE produces error with preg_match_all
From: csaba at alum dot mit dot edu Operating system: Win 2K PHP version: 4.3.0 PHP Bug Type: PCRE related Bug description: PREG_OFFSET_CAPTURE produces error with preg_match_all The following code gives me an error message of: Wrong value for parameter 4 in call to preg_match_all() ... if I replace the PREG_OFFSET_CAPTURE with either PREG_OFFSET_CAPTURE | PREG_SET_ORDER or PREG_OFFSET_CAPTURE | PREG_PATTERN_ORDER then it works as advertised. This contradicts the documentation statement: If no order flag is given, PREG_PATTERN_ORDER is assumed $page = "" . "" . "" . ""; $regexp = "/]*(value=[^>]*)>/"; if (!preg_match_all($regexp, $page, $mtch, PREG_OFFSET_CAPTURE)) print "Could not match"; else print "Found matches"; This is on my PHP 4.3.0 / Apache 2.0.43 / Win 2K Pro system Csaba Gabor from New York -- Edit bug report at http://bugs.php.net/?id=22366&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=22366&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=22366&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=22366&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=22366&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=22366&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=22366&r=support Expected behavior: http://bugs.php.net/fix.php?id=22366&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=22366&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=22366&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=22366&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22366&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=22366&r=dst IIS Stability: http://bugs.php.net/fix.php?id=22366&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=22366&r=gnused
