Bug #12212 Updated: iSilo PDB documentation seems to be broken
ID: 12212 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Assigned +Status: Closed Bug Type: Documentation problem Operating System: FreeBSD 4.3-RELEASE PHP Version: 4.0.6 Assigned To: jmcastagnetto New Comment: File looks OK now Previous Comments: [2001-08-07 14:04:02] [EMAIL PROTECTED] will check this and remake archive if needed [2001-07-17 14:06:55] [EMAIL PROTECTED] hello ! I just tried to install the PDB formatted documentation for iSilo onto my PALM m505 PDA, but the sync tool returned an error. It says cannot install manual_isilo.pdb - corrupted file. Can you please check this, since i really wanted to have the documentation on my PDA. Regards Frank Altpeter -- Edit this bug report at http://bugs.php.net/?id=12212edit=1
Bug #17009 Updated: no work with where clause in quey
ID: 17009 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: MySQL related Operating System: Redhat 7.2 PHP Version: 4.2.0 New Comment: I have tried php4.1.2, nothing change for my programm, but everything is OK. by the way, thanks for your answer, I'll try it out. thanks Anna Zhao Previous Comments: [2002-05-05 00:18:23] [EMAIL PROTECTED] Turn on register_globals in your php.ini file [2002-05-05 00:08:46] [EMAIL PROTECTED] if so, how can I solve it? [2002-05-05 00:03:39] [EMAIL PROTECTED] I upgrade my webserver hardware, then migrate all Mysql database and entire web site content to new server. I have tested Mysql from mysql databases server, every thing is OK, I can use command line like this: select * from content where id=2230 can get the data output correctly. but: when I test to get data by http://192.168.0.4/reader/content.php?id=2230 get error: no data found the content.php code contain: select * from content where id=$id - if the code only contain select id, title from content then it works fine, (without where clause) in brife: the where clause no work in new php version 4.2 in the old server, I setup it with mysql 3.23.22, php 4.1, apache 1.3.19, redhat 7.0, all the programm is coded and tested, of couse worked on this platform the new server, I setup it with mysql 3.23.49a, php 4.2.0, apache 1.3.20, (still no work with where clause) the configure line is: './configure' '--with-mysql' '--with-xml' '--enable-track-vars' '--with-apache=../apache_1.3.20' ** I think I should change back to old php version please let me know if this is realy a php bug. thanks a lot have good day Anna Zhao -- Edit this bug report at http://bugs.php.net/?id=17009edit=1
Bug #17010: not clearly documented import_request_variables
From: [EMAIL PROTECTED] Operating system: n/a PHP version: 4.2.0 PHP Bug Type: Documentation problem Bug description: not clearly documented import_request_variables The prefix argument in import_request_variables is not clearly documented. From a short note one may think (and someone actually did, that's why I'm reporting this) that prefix is used to specify which variables to import (starting with prefix...). -- Edit bug report at http://bugs.php.net/?id=17010edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=17010r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=17010r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=17010r=needtrace Try newer version: http://bugs.php.net/fix.php?id=17010r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=17010r=support Expected behavior: http://bugs.php.net/fix.php?id=17010r=notwrong Not enough info: http://bugs.php.net/fix.php?id=17010r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=17010r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=17010r=globals
Bug #17008 Updated: htmlentities() doesn't encode em or en dash
ID: 17008 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Analyzed Bug Type: *General Issues Operating System: WinXP / Apache 1.3.24 PHP Version: 4.2.0 New Comment: The code in ext/standard/html.c seems to only support entities found in the first 8 bits of a given charset, including utf-8. Windows code page 1252 is the only character set that has em and en dashes in this 8-bit area. Hence it is the only character set that will work like you expect it to. In other words, you need to use cp1252 as the third argument to htmlentities() and make sure that your input string is in cp1252 as well. Support for full utf-8 entities might be coming in a future release. Meanwhile, you can convert utf-8 to HTML's numeric character references with PHP's mbstring extension and this piece of code: $f = 0x; $convmap = array( /* !ENTITY % HTMLlat1 PUBLIC -//W3C//ENTITIES Latin 1//EN//HTML %HTMLlat1; */ 160, 255, 0, $f, /* !ENTITY % HTMLsymbol PUBLIC -//W3C//ENTITIES Symbols//EN//HTML %HTMLsymbol; */ 402, 402, 0, $f, 913, 929, 0, $f, 931, 937, 0, $f, 945, 969, 0, $f, 977, 978, 0, $f, 982, 982, 0, $f, 8226, 8226, 0, $f, 8230, 8230, 0, $f, 8242, 8243, 0, $f, 8254, 8254, 0, $f, 8260, 8260, 0, $f, 8465, 8465, 0, $f, 8472, 8472, 0, $f, 8476, 8476, 0, $f, 8482, 8482, 0, $f, 8501, 8501, 0, $f, 8592, 8596, 0, $f, 8629, 8629, 0, $f, 8656, 8660, 0, $f, 8704, 8704, 0, $f, 8706, 8707, 0, $f, 8709, 8709, 0, $f, 8711, 8713, 0, $f, 8715, 8715, 0, $f, 8719, 8719, 0, $f, 8721, 8722, 0, $f, 8727, 8727, 0, $f, 8730, 8730, 0, $f, 8733, 8734, 0, $f, 8736, 8736, 0, $f, 8743, 8747, 0, $f, 8756, 8756, 0, $f, 8764, 8764, 0, $f, 8773, 8773, 0, $f, 8776, 8776, 0, $f, 8800, 8801, 0, $f, 8804, 8805, 0, $f, 8834, 8836, 0, $f, 8838, 8839, 0, $f, 8853, 8853, 0, $f, 8855, 8855, 0, $f, 8869, 8869, 0, $f, 8901, 8901, 0, $f, 8968, 8971, 0, $f, 9001, 9002, 0, $f, 9674, 9674, 0, $f, 9824, 9824, 0, $f, 9827, 9827, 0, $f, 9829, 9830, 0, $f, /* !ENTITY % HTMLspecial PUBLIC -//W3C//ENTITIES Special//EN//HTML %HTMLspecial; */ /* These ones are excluded to enable HTML: 34, 38, 60, 62 * / 338, 339, 0, $f, 352, 353, 0, $f, 376, 376, 0, $f, 710, 710, 0, $f, 732, 732, 0, $f, 8194, 8195, 0, $f, 8201, 8201, 0, $f, 8204, 8207, 0, $f, 8211, 8212, 0, $f, 8216, 8218, 0, $f, 8218, 8218, 0, $f, 8220, 8222, 0, $f, 8224, 8225, 0, $f, 8240, 8240, 0, $f, 8249, 8250, 0, $f, 8364, 8364, 0, $f); echo mb_encode_numericentity($html, $convmap, UTF-8); Previous Comments: [2002-05-04 23:10:19] [EMAIL PROTECTED] if i'm not wrong this function is supposed to encode all those special characters, right? well, em or en dashes are not encoded. the whole list of characters that should be encoded can be found here: http://selfhtml.teamone.de/html/referenz/zeichen.htm#benannte_interpunktion it's in german, but i guess you can see what i mean. -- Edit this bug report at http://bugs.php.net/?id=17008edit=1
Bug #16680 Updated: socket_read() does not have the described behaviour ...
ID: 16680
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: Sockets related
Operating System: Windows 9x
PHP Version: 4.2.0
New Comment:
i ran your script and connected with teraterm pro from my win2000 box
(local):
i typed 'hello world' ans then disconnected.
this is the output i got:
D:\Apache\htdocsd:\php\php-cli -q -f d:\apache\htdocs\testje.php
string(1) h
string(1) e
string(1) l
string(1) l
string(1) o
string(1)
string(1) w
string(1) o
string(1) r
string(1) l
string(1) d
ring(2)
i guess this should have been a single line, right?
i couldn't test it at this moment with a connection from my linux box
since i'm in a NAT'ed network.
i will try later though.
Previous Comments:
[2002-05-04 19:37:46] [EMAIL PROTECTED]
How did you test sending data to your php script which received the
data? I've noticed that the telnet version shipped with windows does by
default transmit every character immidiately over the line (hence
resulting only in single characters sent). If I telnet from a linux
host to the script running under win32 I recevied the whole data only
after I pressed return.
I've tested it with this simple script:
?
error_reporting(E_ALL);
if (false === ($s = socket_create(AF_INET, SOCK_STREAM, SOL_TCP)))
exit;
if (false === socket_bind($s, '0.0.0.0', 8765))
exit;
if (false === socket_listen($s, 10))
exit;
if (false === ($t = socket_accept($s)))
exit;
while ($data = socket_read($t, 1024)) {
var_dump($data);
}
?
[2002-05-04 19:07:35] [EMAIL PROTECTED]
Please try with CVS HEAD and report back.
[2002-05-04 13:19:44] [EMAIL PROTECTED]
i have exactly the same problem with win2000.
it closes the connection immidiatly after the first received char.
that little scriptlet upthere seems to be be a way around this.
is this a bug or is it suppost to work like this?
[2002-04-18 09:57:00] [EMAIL PROTECTED]
In the documentation, it's written that socket_read() reads data from
the socket until a \n, \t, \0 or until the end of the buffer.
But under win32 it reads only 1 char.
This would be fixed.
Just use instead :
$buf=;
while (substr($buf,-1)!=\n) {
$buf.=socket_read($socket,1);
}
I've put 1 here, but you can write 16777216 it'll continue to give back
only 1 char.
--
Edit this bug report at http://bugs.php.net/?id=16680edit=1
Bug #17012: releasing IDispatch interface too many times (putprop issue)
From: [EMAIL PROTECTED]
Operating system: WinNT 2000
PHP version: 4.2.0
PHP Bug Type: COM related
Bug description: releasing IDispatch interface too many times (putprop issue)
hello
I wrote a script to access ADO database:
$conn = new COM('ADODB.Connection');
$hr = $conn-Open('Provider=Microsoft.Jet.OLEDB.4.0;Data
Source=test.mdb',, , 0);
$oCmd = new COM('ADODB.Command');
$oCmd-ActiveConnection = $conn;
$oCmd-CommandText = INSERT INTO config(storage) VALUES('testowa
wartosc');
$oCmd-CommandType = 1;
$rs = $oCmd-Execute();
in line
$oCmd-ActiveConnection = $conn;
there is created a zendval variable (result from assigning IDispatch $conn
to property) but $conn is not AddRef-ed...
When this invisible variable is destroyed it calls Release on IDispatch
from $conn - But this dispatch is already 0-referenced.
I isolated the code in file COM.c in line 1142 (function do_COM_propput):
---
if (SUCCEEDED(hr)) {
php_variant_to_pval(var_result, return_value, codepage TSRMLS_CC);
} else {
--
and changed to:
---
if (SUCCEEDED(hr)) {
if ( var_result-vt == VT_DISPATCH )
var_result-pdispVal-lpVtbl-AddRef(var_result-pdispVal);
php_variant_to_pval(var_result, return_value, codepage TSRMLS_CC);
} else {
Is it a good solution? Or maybe I don't understand something?
Tristan Rybak
--
Edit bug report at http://bugs.php.net/?id=17012edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=17012r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=17012r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=17012r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=17012r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=17012r=support
Expected behavior: http://bugs.php.net/fix.php?id=17012r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=17012r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=17012r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=17012r=globals
Bug #17013: sleep function doesnt work correctly
From: [EMAIL PROTECTED] Operating system: win ME PHP version: 4.2.0 PHP Bug Type: Reproducible crash Bug description: sleep function doesnt work correctly The time limit doesnt work correctly when PHP sleeps this time IS included when determining the maximum time that the script has been running the manual states: The set_time_limit() function and the configuration directive max_execution_time only affect the execution time of the script itself. Any time spent on activity that happens outside the execution of the script such as system calls using system(), the sleep() function, database queries, etc. is not included when determining the maximum time that the script has been running. if you want to reproduce the problem just run this few lines and you will see it never never echos after sleep ?php echo before sleep; set_time_limit(5); sleep(6); echo after sleep; ? -- Edit bug report at http://bugs.php.net/?id=17013edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=17013r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=17013r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=17013r=needtrace Try newer version: http://bugs.php.net/fix.php?id=17013r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=17013r=support Expected behavior: http://bugs.php.net/fix.php?id=17013r=notwrong Not enough info: http://bugs.php.net/fix.php?id=17013r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=17013r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=17013r=globals
Bug #17013 Updated: sleep function doesnt work correctly
ID: 17013 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Reproducible crash Operating System: win ME PHP Version: 4.2.0 New Comment: please read http://www.php.net/manual/en/function.set-time-limit.php no bug, no documantation problem - bogus Previous Comments: [2002-05-05 09:06:33] [EMAIL PROTECTED] The time limit doesnt work correctly when PHP sleeps this time IS included when determining the maximum time that the script has been running the manual states: The set_time_limit() function and the configuration directive max_execution_time only affect the execution time of the script itself. Any time spent on activity that happens outside the execution of the script such as system calls using system(), the sleep() function, database queries, etc. is not included when determining the maximum time that the script has been running. if you want to reproduce the problem just run this few lines and you will see it never never echos after sleep ?php echo before sleep; set_time_limit(5); sleep(6); echo after sleep; ? -- Edit this bug report at http://bugs.php.net/?id=17013edit=1
Bug #17014: pcntl_wexitstatus does not return exit status
From: [EMAIL PROTECTED]
Operating system: RedHat7.2 and RedHat7.1
PHP version: 4.1.2
PHP Bug Type: Unknown/Other Function
Bug description: pcntl_wexitstatus does not return exit status
On Red Hat 7.2 and Red Hat 7.1,
pcntl_wexitstatus does not return exit status,
pcntl_wexitstatus returns 0.
when child process call [exit(1);]
and when father process run:
pcntl_waitpid($pid,$status,WNOHANG);
if(pcntl_wifexited($status)){
$exitstatus=pcntl_wexitstatus($status);
}
--
Edit bug report at http://bugs.php.net/?id=17014edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=17014r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=17014r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=17014r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=17014r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=17014r=support
Expected behavior: http://bugs.php.net/fix.php?id=17014r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=17014r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=17014r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=17014r=globals
Bug #17015: Ora_Error/Ora_ErrorCode
From: [EMAIL PROTECTED] Operating system: HP-Unix 11.X PHP version: 4.1.2 PHP Bug Type: Oracle related Bug description: Ora_Error/Ora_ErrorCode When checking for errors after Ora_Do, if the table is empty, neither of them (ora_error/ora_errorcode) return 1403 (no data found). Following is sample code: $query = select * from test_table ; $qCursor = Ora_Do($oraConn, $query); $qError = Ora_ErrorCode($query); // $qError = Ora_Error($query); echo Error = .$qError. \n; -- Edit bug report at http://bugs.php.net/?id=17015edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=17015r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=17015r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=17015r=needtrace Try newer version: http://bugs.php.net/fix.php?id=17015r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=17015r=support Expected behavior: http://bugs.php.net/fix.php?id=17015r=notwrong Not enough info: http://bugs.php.net/fix.php?id=17015r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=17015r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=17015r=globals
Bug #17016: function juliantojd and reverse jdtojulian wrong output
From: [EMAIL PROTECTED]
Operating system: linux/windows
PHP version: 4.1.2
PHP Bug Type: *Calendar problems
Bug description: function juliantojd and reverse jdtojulian wrong output
in function juliantojd (and reverse jdtojulian) the wrong calendar rules
are implemented.
the output of function for the date 1/1/1985 is 2446080 but
the correct julian date is 2446067 (for example).
below the rules to convert a julian date into jd as a php-script:
?php
$a=$year;
$m=$month;
$t=$day;
$j=$a;
IF ($a0){$j=$j+1;}
IF ($m3){
$m=$m+12;
$j=$j-1;
}
$juldat=0;
IF (($a+$m/100+$tag/1)1582.1005){
$juldat= floor($j/100);
$juldat=2-$juldat+ floor($juldat/4);
}
IF ($a=0){
$juldat=- floor(.75-365.25*$j)+ floor(30.6001*($m+1))+$t+1720995;
}
ELSE{
$juldat=$juldat+ floor(365.25*$j)+ floor(30.6001*($m+1))+$t+1720995;
}
?
--
Edit bug report at http://bugs.php.net/?id=17016edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=17016r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=17016r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=17016r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=17016r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=17016r=support
Expected behavior: http://bugs.php.net/fix.php?id=17016r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=17016r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=17016r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=17016r=globals
Bug #17002 Updated: Unable to load php_oci8.dll ONLY in command line mode
ID: 17002 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: OCI8 related Operating System: Win98 PHP Version: 4.2.0 New Comment: Of course, it is NOT a bug of php. Previous Comments: [2002-05-05 12:01:11] [EMAIL PROTECTED] After failed many times, I happened to find the cause. I think it maybe helpful for many people who reported or asked the same question that I have seen on www.php.net . It is the PATH has not been correctly set. When loading php_oci8.dll, this DLL file search for the other DLL file oci.dll in current directory, PATH environment and %SYSTEM%(on Windows). If oci.dll can not be found, the OS will tell you Unable to load dynamic library : php_oci8.dll. If you installed Oracle RDBMS on your system, then the file oci.dll is in Oralce Home directory. So you must include Oracle Home Directory in PATH environment, on my computer it is D:\Oracle\ora81\Bin. Perhaps, the same problem on different platform can be solved in same way, try it. I am lucky to find the cause in almost ten days, I hope people will not be worried about this problem any longer. Dong Peng Lanzhou Railway Universiy China 2002-5-6 00:06 [2002-05-04 05:15:29] [EMAIL PROTECTED] The bug system is not the appropriate forum for asking support questions. For a list of a range of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php [2002-05-04 05:00:24] [EMAIL PROTECTED] Unable to load php_oci8.dll ONLY in command line mode I have just installed php 4.2.0 for win32 on my computer. I found the same bug as php (4.1.2). There is nothing wrong when I use php in ISAPI mode, and I can connect to Oracle 8i(8.1.7 Personal Edition) successfully and manipulate data too. but when I use php in command line mode to process some task which can only run once, the system show a message box with the text below : 'Unable to load dynamic library c:\php420\extensions\php_oci8.dll. ' The extension file php_oci8.dll does exist in the above directory, and can work correctly in ISAPI mode. So I considered that there is a bug in php.exe on loading dynamic library. Is it? Please help me. Dong Peng 2002-5-4 -- Edit this bug report at http://bugs.php.net/?id=17002edit=1
Bug #16475 Updated: segfault at startup with Apache 2.0.35
ID: 16475 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Apache2 related Operating System: Linux 2.4.x PHP Version: 4.2.0RC2-4 New Comment: This is a new bug. Please resubmit (and please report if it happens if you don't use SSL). Thanks for using Apache and PHP (and glad the original bug seems to have been fixed)! Previous Comments: [2002-05-04 16:51:29] [EMAIL PROTECTED] The version 1.74 enables the Apache 2.0.35 server to start with PHP 4.2.0 However after a bin/apachectl restart all http calls will fail: child pid 31308 exit signal Segmentation fault (11) A full stop and startssl of Apache is needed. Jan P. Sorensen [2002-04-24 16:00:38] [EMAIL PROTECTED] Hi folks, great work :-) Apache 2.0.35 works now fine for me even with php4.3-dev (I took it from snaps.php.net). Again let me know when I should retry any other version of php... Thanks + bye, Sebastian [2002-04-23 20:59:35] [EMAIL PROTECTED] This bug has been fixed in CVS. I just committed a fix for this in sapi/apache2filter/sapi_apache2.c version 1.74 (from CVS HEAD). If you are still seeing the problem after trying this version please reopen this bug. Thank you for using Apache/PHP! [2002-04-23 16:12:24] [EMAIL PROTECTED] Hi, try submitting a backtrace. See http://bugs.php.net/bugs-generating-backtrace.php to create it - it's quite simple but helps the developers a lot. Did you compile apache with the option --with-apxs2? Just gimme a hint when I should try to compile apache with php on my system again... Bye, Sebastian [2002-04-23 14:55:29] [EMAIL PROTECTED] Well, this is probably not much help, but with gcc-2.95.3, linux-2.4.18, apache 2.0.35 and PHP 4.2.0 I see the same behavior, namely, httpd -X crashes with a segmentation fault whenever I access ANY page on the server, PHP or not. This only happens AFTER the PHP module is loaded. With the vanilla apache (no php) I have no problems, whatsoever. Also, configuration of both apache and php is minimal. 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/16475 -- Edit this bug report at http://bugs.php.net/?id=16475edit=1
Bug #17002 Updated: Unable to load php_oci8.dll ONLY in command line mode
ID: 17002 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Open -Bug Type: OCI8 related +Bug Type: Documentation problem Operating System: Win98 PHP Version: 4.2.0 New Comment: Hm... it seems to me a good idea to note somewhere in the manual that PHP (or Windows) searches for DLL's in %PATH% and %SYSTEM%. Reopening as a documentation problem. Previous Comments: [2002-05-05 12:04:48] [EMAIL PROTECTED] Of course, it is NOT a bug of php. [2002-05-05 12:01:11] [EMAIL PROTECTED] After failed many times, I happened to find the cause. I think it maybe helpful for many people who reported or asked the same question that I have seen on www.php.net . It is the PATH has not been correctly set. When loading php_oci8.dll, this DLL file search for the other DLL file oci.dll in current directory, PATH environment and %SYSTEM%(on Windows). If oci.dll can not be found, the OS will tell you Unable to load dynamic library : php_oci8.dll. If you installed Oracle RDBMS on your system, then the file oci.dll is in Oralce Home directory. So you must include Oracle Home Directory in PATH environment, on my computer it is D:\Oracle\ora81\Bin. Perhaps, the same problem on different platform can be solved in same way, try it. I am lucky to find the cause in almost ten days, I hope people will not be worried about this problem any longer. Dong Peng Lanzhou Railway Universiy China 2002-5-6 00:06 [2002-05-04 05:15:29] [EMAIL PROTECTED] The bug system is not the appropriate forum for asking support questions. For a list of a range of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php [2002-05-04 05:00:24] [EMAIL PROTECTED] Unable to load php_oci8.dll ONLY in command line mode I have just installed php 4.2.0 for win32 on my computer. I found the same bug as php (4.1.2). There is nothing wrong when I use php in ISAPI mode, and I can connect to Oracle 8i(8.1.7 Personal Edition) successfully and manipulate data too. but when I use php in command line mode to process some task which can only run once, the system show a message box with the text below : 'Unable to load dynamic library c:\php420\extensions\php_oci8.dll. ' The extension file php_oci8.dll does exist in the above directory, and can work correctly in ISAPI mode. So I considered that there is a bug in php.exe on loading dynamic library. Is it? Please help me. Dong Peng 2002-5-4 -- Edit this bug report at http://bugs.php.net/?id=17002edit=1
Bug #17017 Updated: Variable superglobal variable not recognised within function and method
ID: 17017
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Duplicate
Bug Type: Variables related
Operating System: Linux
PHP Version: 4.2.0
New Comment:
Known limitation.
I don't know yet if this has been documented already, there's another
report about this issue though.
Marking as duplicate for now.
Previous Comments:
[2002-05-05 12:58:27] [EMAIL PROTECTED]
Hello :-)
The definition of a variable variable as superglobal works fine when
put in the main coding (i.e. not within a function or method).
Example:
?php
$aVariable = 'GET';
echo ${_{$aVariable}};
?
The system output is: Array
In the next example however, where the same code is put into a
function, the resulting output is a error message instead:
?php
function aFunction()
{
$aVariable = 'GET';
echo ${_{$aVariable}};
}
aFunction();
?
The system output is: Notice: Undefined variable: _GET in Bestand.php
on line 6.
Also when $_GET has been defined as global (which should not be
necessary) this malfunction remains.
Suggested intermediate solution:
?php
function aFunction()
{
$aVariable = 'GET';
echo $GLOBALS[_{$aVariable}];
}
aFunction();
?
--
Edit this bug report at http://bugs.php.net/?id=17017edit=1
Bug #17018: simple example does not work
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.2.0 PHP Bug Type: *General Issues Bug description: simple example does not work I am using simple script with ? echo $HTTP_HOST ?, it does echo nothing when installing version 4.2.0, it works as expected with 4.1.2 that i installed after (i am using mod-perl, so i tried apache 1.3.24 with/without mod-perl(1.26), same effect so i got earlier version of php) am i missing something (it is the first time i try php) sorry if my mistake and if you are wasting time on it b.w r. -- Edit bug report at http://bugs.php.net/?id=17018edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=17018r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=17018r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=17018r=needtrace Try newer version: http://bugs.php.net/fix.php?id=17018r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=17018r=support Expected behavior: http://bugs.php.net/fix.php?id=17018r=notwrong Not enough info: http://bugs.php.net/fix.php?id=17018r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=17018r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=17018r=globals
Bug #17018 Updated: simple example does not work
ID: 17018 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Open Bug Type: *General Issues Operating System: Linux PHP Version: 4.2.0 New Comment: The bug system is not the appropriate forum for asking support questions. For a list of a range of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php It's called $HTTP_POST_VARS Previous Comments: [2002-05-05 13:29:02] [EMAIL PROTECTED] I am using simple script with ? echo $HTTP_HOST ?, it does echo nothing when installing version 4.2.0, it works as expected with 4.1.2 that i installed after (i am using mod-perl, so i tried apache 1.3.24 with/without mod-perl(1.26), same effect so i got earlier version of php) am i missing something (it is the first time i try php) sorry if my mistake and if you are wasting time on it b.w r. -- Edit this bug report at http://bugs.php.net/?id=17018edit=1
Bug #17018 Updated: simple example does not work
ID: 17018 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: *General Issues Operating System: Linux PHP Version: 4.2.0 New Comment: Er.. It's still a support question, anyway start looking in $_SERVER (use phpinfo() to find such things quick). Previous Comments: [2002-05-05 13:31:00] [EMAIL PROTECTED] The bug system is not the appropriate forum for asking support questions. For a list of a range of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php It's called $HTTP_POST_VARS [2002-05-05 13:29:02] [EMAIL PROTECTED] I am using simple script with ? echo $HTTP_HOST ?, it does echo nothing when installing version 4.2.0, it works as expected with 4.1.2 that i installed after (i am using mod-perl, so i tried apache 1.3.24 with/without mod-perl(1.26), same effect so i got earlier version of php) am i missing something (it is the first time i try php) sorry if my mistake and if you are wasting time on it b.w r. -- Edit this bug report at http://bugs.php.net/?id=17018edit=1
Bug #17019: problem
From: [EMAIL PROTECTED] Operating system: win XP PHP version: 4.2.0 PHP Bug Type: Unknown/Other Function Bug description: problem How come I am not able to see a webpage that is made with the PHP system??? -- Edit bug report at http://bugs.php.net/?id=17019edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=17019r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=17019r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=17019r=needtrace Try newer version: http://bugs.php.net/fix.php?id=17019r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=17019r=support Expected behavior: http://bugs.php.net/fix.php?id=17019r=notwrong Not enough info: http://bugs.php.net/fix.php?id=17019r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=17019r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=17019r=globals
Bug #17019 Updated: problem
ID: 17019 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Unknown/Other Function Operating System: win XP PHP Version: 4.2.0 New Comment: The bug system is not the appropriate forum for asking support questions. For a list of a range of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php Previous Comments: [2002-05-05 15:07:21] [EMAIL PROTECTED] How come I am not able to see a webpage that is made with the PHP system??? -- Edit this bug report at http://bugs.php.net/?id=17019edit=1
Bug #17020: Servlet sapi native code problems
From: [EMAIL PROTECTED] Operating system: Linux - 2.4.18 PHP version: 4.2.0 PHP Bug Type: Servlet related Bug description: Servlet sapi native code problems Native code problems with the current servlet sapi. I've had this problem for over a year. No one reports that they have been successfull getting the servlet sapit to work. Please help me get PHP to be better. php-4.2.0 tomcat 4.0.3 j2sdk-1.4.0 info.php ? phpinfo(); ? javax.servlet.ServletException: bailout at net.php.servlet.send(Native Method) at net.php.servlet.service(servlet.java:188) at net.php.servlet.service(servlet.java:212) at javax.servlet.http.HttpServlet.service(HttpServlet.java) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:243) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:190) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566) at org.apache.catalina.valves.CertificatesValve.invoke(CertificatesValve.java:246) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2343) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566) at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:170) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:170) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:468) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java:1012) at org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:1107) at java.lang.Thread.run(Thread.java:536) -- Edit bug report at http://bugs.php.net/?id=17020edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=17020r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=17020r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=17020r=needtrace Try newer version: http://bugs.php.net/fix.php?id=17020r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=17020r=support Expected behavior: http://bugs.php.net/fix.php?id=17020r=notwrong Not enough info: http://bugs.php.net/fix.php?id=17020r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=17020r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=17020r=globals
Bug #17021: PHP_SELF Displays nothing
From: [EMAIL PROTECTED] Operating system: Windows XP Pro PHP version: 4.2.0 PHP Bug Type: PHP options/info functions Bug description: PHP_SELF Displays nothing I am on an Xitami Server V2.4d9 running Windows XP PRO with PHP Version 4.20. I am a script called PHPAdsNew and it uses the ?php echo basename($PHP_SELF);? PHP command to get the name of the file so, it can submit forms. Example: form action=?php echo basename($PHP_SELF);? But, it will not work.. It stays EMPTY. PHP will not write the name of the file. It would be way to hard to change the script around with over 80 files, no way! Thanks David -- Edit bug report at http://bugs.php.net/?id=17021edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=17021r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=17021r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=17021r=needtrace Try newer version: http://bugs.php.net/fix.php?id=17021r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=17021r=support Expected behavior: http://bugs.php.net/fix.php?id=17021r=notwrong Not enough info: http://bugs.php.net/fix.php?id=17021r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=17021r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=17021r=globals
Bug #16517 Updated: strtotime no longer converts output of UNIX command 'date'
ID: 16517 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Date/time related Operating System: Solaris PHP Version: 4.1.2 New Comment: - Linux Test Script -- echo strtotime(2002 Fri Apr 26 16:40:13); echo strtotime(Fri Apr 26 16:40:13 EDT 2002); echo strtotime(Fri Apr 26 16:40:13 2002); -- Yields -- -1 -1 -1 PHP Info PHP Version 4.1.1 System Linux 2.4.18-preempt-1 Server API Apache Previous Comments: [2002-04-09 14:24:42] [EMAIL PROTECTED] After reviewing the details of other open bugs, seems similar to Bug #13142 and Bug #15123. [2002-04-09 13:42:32] [EMAIL PROTECTED] Test Script $testTS = 'Tue Apr 9 11:37:21 MDT 2002'; # Output of UNIX command 'date' print strtotime ($testTS); Yields -1 PHP Info PHP Version 4.1.2 System SunOS slc-sun4 5.7 Generic_106541-15 sun4u sparc SUNW,Ultra-Enterprise Build Date Apr 2 2002 Configure Command 'configure' '--with-jpeg-dir=/usr/local' '--with-gd=/usr/local' '--with-ibm-db2=/home/slcd0005/sqllib' '--with-apache=/home/tc2876a/stage/apache/apache_1.3.12' Server API Apache Virtual Directory Support disabled Configuration File (php.ini) Path /usr/local/lib/php.ini ZEND_DEBUG disabled Thread Safety disabled Notes Worked in 4.0.2 -- Edit this bug report at http://bugs.php.net/?id=16517edit=1
Bug #17021 Updated: PHP_SELF Displays nothing
ID: 17021 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: PHP options/info functions Operating System: Windows XP Pro PHP Version: 4.2.0 New Comment: In PHP 4.2.0, the 'register_globals' setting default changed to be off. See http://www.php.net/release_4_2_0.php for more info. Previous Comments: [2002-05-05 15:54:31] [EMAIL PROTECTED] I am on an Xitami Server V2.4d9 running Windows XP PRO with PHP Version 4.20. I am a script called PHPAdsNew and it uses the ?php echo basename($PHP_SELF);? PHP command to get the name of the file so, it can submit forms. Example: form action=?php echo basename($PHP_SELF);? But, it will not work.. It stays EMPTY. PHP will not write the name of the file. It would be way to hard to change the script around with over 80 files, no way! Thanks David -- Edit this bug report at http://bugs.php.net/?id=17021edit=1
Bug #17021 Updated: PHP_SELF Displays nothing
ID: 17021 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Open Bug Type: PHP options/info functions Operating System: Windows XP Pro PHP Version: 4.2.0 New Comment: No, I set it so, register_globals is on. David Previous Comments: [2002-05-05 16:06:33] [EMAIL PROTECTED] In PHP 4.2.0, the 'register_globals' setting default changed to be off. See http://www.php.net/release_4_2_0.php for more info. [2002-05-05 15:54:31] [EMAIL PROTECTED] I am on an Xitami Server V2.4d9 running Windows XP PRO with PHP Version 4.20. I am a script called PHPAdsNew and it uses the ?php echo basename($PHP_SELF);? PHP command to get the name of the file so, it can submit forms. Example: form action=?php echo basename($PHP_SELF);? But, it will not work.. It stays EMPTY. PHP will not write the name of the file. It would be way to hard to change the script around with over 80 files, no way! Thanks David -- Edit this bug report at http://bugs.php.net/?id=17021edit=1
Bug #17021 Updated: PHP_SELF Displays nothing
ID: 17021 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: PHP options/info functions Operating System: Windows XP Pro PHP Version: 4.2.0 New Comment: What's the output of $PHP_SELF ? Previous Comments: [2002-05-05 16:12:18] [EMAIL PROTECTED] No, I set it so, register_globals is on. David [2002-05-05 16:06:33] [EMAIL PROTECTED] In PHP 4.2.0, the 'register_globals' setting default changed to be off. See http://www.php.net/release_4_2_0.php for more info. [2002-05-05 15:54:31] [EMAIL PROTECTED] I am on an Xitami Server V2.4d9 running Windows XP PRO with PHP Version 4.20. I am a script called PHPAdsNew and it uses the ?php echo basename($PHP_SELF);? PHP command to get the name of the file so, it can submit forms. Example: form action=?php echo basename($PHP_SELF);? But, it will not work.. It stays EMPTY. PHP will not write the name of the file. It would be way to hard to change the script around with over 80 files, no way! Thanks David -- Edit this bug report at http://bugs.php.net/?id=17021edit=1
Bug #17021 Updated: PHP_SELF Displays nothing
ID: 17021 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: PHP options/info functions Operating System: Windows XP Pro PHP Version: 4.2.0 New Comment: NOTHING. It doesn't output anything. Stays blank, on a Redhat Linux, using Apache 1.3 it works. It displays PHP_SELF. Thanks David Previous Comments: [2002-05-05 16:26:12] [EMAIL PROTECTED] What's the output of $PHP_SELF ? [2002-05-05 16:12:18] [EMAIL PROTECTED] No, I set it so, register_globals is on. David [2002-05-05 16:06:33] [EMAIL PROTECTED] In PHP 4.2.0, the 'register_globals' setting default changed to be off. See http://www.php.net/release_4_2_0.php for more info. [2002-05-05 15:54:31] [EMAIL PROTECTED] I am on an Xitami Server V2.4d9 running Windows XP PRO with PHP Version 4.20. I am a script called PHPAdsNew and it uses the ?php echo basename($PHP_SELF);? PHP command to get the name of the file so, it can submit forms. Example: form action=?php echo basename($PHP_SELF);? But, it will not work.. It stays EMPTY. PHP will not write the name of the file. It would be way to hard to change the script around with over 80 files, no way! Thanks David -- Edit this bug report at http://bugs.php.net/?id=17021edit=1
Bug #17021 Updated: PHP_SELF Displays nothing
ID: 17021
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Feedback
Bug Type: PHP options/info functions
Operating System: Windows XP Pro
PHP Version: 4.2.0
New Comment:
No, echo $PHP_SELF or var_dump(${PHP_SELF) *cannot* display PHP_SELF
unless you disabled php parsing or whatever.
Anyway, what does phpinfo() output say about PHP_SELF, does it show
anywhere up in the page? If so, where (paste the appropriate table
line) ?
And, also double check the register_globals ini setting in your
phpinfo() output. I still think you have it disabled.
Previous Comments:
[2002-05-05 16:31:38] [EMAIL PROTECTED]
NOTHING. It doesn't output anything. Stays blank, on a Redhat Linux,
using Apache 1.3 it works. It displays PHP_SELF.
Thanks
David
[2002-05-05 16:26:12] [EMAIL PROTECTED]
What's the output of $PHP_SELF ?
[2002-05-05 16:12:18] [EMAIL PROTECTED]
No, I set it so, register_globals is on.
David
[2002-05-05 16:06:33] [EMAIL PROTECTED]
In PHP 4.2.0, the 'register_globals' setting default changed to
be off. See http://www.php.net/release_4_2_0.php for more info.
[2002-05-05 15:54:31] [EMAIL PROTECTED]
I am on an Xitami Server V2.4d9 running Windows XP PRO with PHP
Version 4.20. I am a script called PHPAdsNew and it uses the ?php echo
basename($PHP_SELF);? PHP command to get the name of the file so, it
can submit forms.
Example: form action=?php echo basename($PHP_SELF);?
But, it will not work.. It stays EMPTY. PHP will not write the name of
the file.
It would be way to hard to change the script around with over 80 files,
no way!
Thanks
David
--
Edit this bug report at http://bugs.php.net/?id=17021edit=1
Bug #17021 Updated: PHP_SELF Displays nothing
ID: 17021
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: PHP options/info functions
Operating System: Windows XP Pro
PHP Version: 4.2.0
New Comment:
The script doesn't show anything. Just says _SERVER[PHP_SELF] in
the first column and nothing in the second column.
See for your self. http://www.dgtechnology.com/server.php
Make sure to keep the www..
Thanks
David
Previous Comments:
[2002-05-05 16:39:51] [EMAIL PROTECTED]
No, echo $PHP_SELF or var_dump(${PHP_SELF) *cannot* display PHP_SELF
unless you disabled php parsing or whatever.
Anyway, what does phpinfo() output say about PHP_SELF, does it show
anywhere up in the page? If so, where (paste the appropriate table
line) ?
And, also double check the register_globals ini setting in your
phpinfo() output. I still think you have it disabled.
[2002-05-05 16:31:38] [EMAIL PROTECTED]
NOTHING. It doesn't output anything. Stays blank, on a Redhat Linux,
using Apache 1.3 it works. It displays PHP_SELF.
Thanks
David
[2002-05-05 16:26:12] [EMAIL PROTECTED]
What's the output of $PHP_SELF ?
[2002-05-05 16:12:18] [EMAIL PROTECTED]
No, I set it so, register_globals is on.
David
[2002-05-05 16:06:33] [EMAIL PROTECTED]
In PHP 4.2.0, the 'register_globals' setting default changed to
be off. See http://www.php.net/release_4_2_0.php for more info.
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/17021
--
Edit this bug report at http://bugs.php.net/?id=17021edit=1
Bug #17021 Updated: PHP_SELF Displays nothing
ID: 17021
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Analyzed
Bug Type: Other web server
Operating System: Windows XP Pro
PHP Version: 4.2.0
New Comment:
Upon closer inspectation of the CGI code I it seems your webserver
doesn't properly set the environment varaibles needed for PHP to
construct the PHP_SELF variable.
CGI needs to have either PATH_INFO or SCRIPT_NAME to be set via the
environment. That's the only possibility why PHP_SELF is simply empty.
Since I'm not that familiar with Xitami I can't say if it's a bug
there, but you might want to check in Xitami related forums to get a
quicker answer.
Previous Comments:
[2002-05-05 17:04:25] [EMAIL PROTECTED]
Changing category.
Seems to be a Xitami or CGI issue then (sorry I seem to have misread
you were using Xitami).
[2002-05-05 16:52:28] [EMAIL PROTECTED]
The script doesn't show anything. Just says _SERVER[PHP_SELF] in
the first column and nothing in the second column.
See for your self. http://www.dgtechnology.com/server.php
Make sure to keep the www..
Thanks
David
[2002-05-05 16:39:51] [EMAIL PROTECTED]
No, echo $PHP_SELF or var_dump(${PHP_SELF) *cannot* display PHP_SELF
unless you disabled php parsing or whatever.
Anyway, what does phpinfo() output say about PHP_SELF, does it show
anywhere up in the page? If so, where (paste the appropriate table
line) ?
And, also double check the register_globals ini setting in your
phpinfo() output. I still think you have it disabled.
[2002-05-05 16:31:38] [EMAIL PROTECTED]
NOTHING. It doesn't output anything. Stays blank, on a Redhat Linux,
using Apache 1.3 it works. It displays PHP_SELF.
Thanks
David
[2002-05-05 16:26:12] [EMAIL PROTECTED]
What's the output of $PHP_SELF ?
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/17021
--
Edit this bug report at http://bugs.php.net/?id=17021edit=1
Bug #17008 Updated: htmlentities() doesn't encode em or en dash
ID: 17008 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Analyzed Bug Type: *General Issues Operating System: WinXP / Apache 1.3.24 PHP Version: 4.2.0 New Comment: The docs also say that iso-8859-1 charset is assumed; there are no em or en dash characters in that charset. But you are correct in that the docs are not up to date with regards to which charsets and to what extent they are supported. Previous Comments: [2002-05-05 13:41:14] [EMAIL PROTECTED] well, then the it's not a bug, but then the documetation is a bit confusing: This function is identical to htmlspecialchars() in all ways, except that ALL characters which have HTML character entity equivalents are translated into these entities. and for em-dash for example there's a mdash; since html 4.0 [2002-05-05 05:23:39] [EMAIL PROTECTED] The code in ext/standard/html.c seems to only support entities found in the first 8 bits of a given charset, including utf-8. Windows code page 1252 is the only character set that has em and en dashes in this 8-bit area. Hence it is the only character set that will work like you expect it to. In other words, you need to use cp1252 as the third argument to htmlentities() and make sure that your input string is in cp1252 as well. Support for full utf-8 entities might be coming in a future release. Meanwhile, you can convert utf-8 to HTML's numeric character references with PHP's mbstring extension and this piece of code: $f = 0x; $convmap = array( /* !ENTITY % HTMLlat1 PUBLIC -//W3C//ENTITIES Latin 1//EN//HTML %HTMLlat1; */ 160, 255, 0, $f, /* !ENTITY % HTMLsymbol PUBLIC -//W3C//ENTITIES Symbols//EN//HTML %HTMLsymbol; */ 402, 402, 0, $f, 913, 929, 0, $f, 931, 937, 0, $f, 945, 969, 0, $f, 977, 978, 0, $f, 982, 982, 0, $f, 8226, 8226, 0, $f, 8230, 8230, 0, $f, 8242, 8243, 0, $f, 8254, 8254, 0, $f, 8260, 8260, 0, $f, 8465, 8465, 0, $f, 8472, 8472, 0, $f, 8476, 8476, 0, $f, 8482, 8482, 0, $f, 8501, 8501, 0, $f, 8592, 8596, 0, $f, 8629, 8629, 0, $f, 8656, 8660, 0, $f, 8704, 8704, 0, $f, 8706, 8707, 0, $f, 8709, 8709, 0, $f, 8711, 8713, 0, $f, 8715, 8715, 0, $f, 8719, 8719, 0, $f, 8721, 8722, 0, $f, 8727, 8727, 0, $f, 8730, 8730, 0, $f, 8733, 8734, 0, $f, 8736, 8736, 0, $f, 8743, 8747, 0, $f, 8756, 8756, 0, $f, 8764, 8764, 0, $f, 8773, 8773, 0, $f, 8776, 8776, 0, $f, 8800, 8801, 0, $f, 8804, 8805, 0, $f, 8834, 8836, 0, $f, 8838, 8839, 0, $f, 8853, 8853, 0, $f, 8855, 8855, 0, $f, 8869, 8869, 0, $f, 8901, 8901, 0, $f, 8968, 8971, 0, $f, 9001, 9002, 0, $f, 9674, 9674, 0, $f, 9824, 9824, 0, $f, 9827, 9827, 0, $f, 9829, 9830, 0, $f, /* !ENTITY % HTMLspecial PUBLIC -//W3C//ENTITIES Special//EN//HTML %HTMLspecial; */ /* These ones are excluded to enable HTML: 34, 38, 60, 62 * / 338, 339, 0, $f, 352, 353, 0, $f, 376, 376, 0, $f, 710, 710, 0, $f, 732, 732, 0, $f, 8194, 8195, 0, $f, 8201, 8201, 0, $f, 8204, 8207, 0, $f, 8211, 8212, 0, $f, 8216, 8218, 0, $f, 8218, 8218, 0, $f, 8220, 8222, 0, $f, 8224, 8225, 0, $f, 8240, 8240, 0, $f, 8249, 8250, 0, $f, 8364, 8364, 0, $f); echo mb_encode_numericentity($html, $convmap, UTF-8); [2002-05-04 23:10:19] [EMAIL PROTECTED] if i'm not wrong this function is supposed to encode all those special characters, right? well, em or en dashes are not encoded. the whole list of characters that should be encoded can be found here: http://selfhtml.teamone.de/html/referenz/zeichen.htm#benannte_interpunktion it's in german, but i guess you can see what i mean. -- Edit this bug report at http://bugs.php.net/?id=17008edit=1
Bug #16807 Updated: Sessions not working
ID: 16807 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Session related Operating System: Windows 2000 SP2 PHP Version: 4.2.0 New Comment: The error I receive (again, 4.2.0, IIS, and Win 2k) is that it is unable to open the session folder. May or may not be related, but I'm also experiencing problems with POST variables. David Previous Comments: [2002-05-03 23:53:28] [EMAIL PROTECTED] [EMAIL PROTECTED]/other mail addresses who comment on this/ [2002-05-03 23:52:02] [EMAIL PROTECTED] [EMAIL PROTECTED] report is not about register globals issue. Please do not add any more comments about register globals... [2002-05-01 20:24:11] [EMAIL PROTECTED] I'm having a similar issue - every since switching to PHP 4.2 I've got sh#tloads of viewers reporting login problems to our forums (vBulletin), they keep getting prompted to login. Weird part is it's not everyone, I and others have no problems at all. Reverting back to PHP 4.1.x solves it, upgrading to PHP 4.2 brings it back. register_globals is ON [2002-04-30 16:45:24] [EMAIL PROTECTED] The 'solution' above is not valid for this case. PHP should not generate the 'headers already sent' message at all in this case. [2002-04-30 14:27:10] [EMAIL PROTECTED] Can someone please fix this, since it is not a configuration problem. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/16807 -- Edit this bug report at http://bugs.php.net/?id=16807edit=1
Bug #17008 Updated: htmlentities() doesn't encode em or en dash
ID: 17008 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Analyzed +Status: Closed Bug Type: *General Issues Operating System: WinXP / Apache 1.3.24 PHP Version: 4.2.0 New Comment: I've committed a fix that adds support for the remaining html4 entities to the CVS HEAD. You need to be using the utf-8 encoding for these characters to be detected/converted. This change will be in 4.3.0 Previous Comments: [2002-05-05 17:46:11] [EMAIL PROTECTED] The docs also say that iso-8859-1 charset is assumed; there are no em or en dash characters in that charset. But you are correct in that the docs are not up to date with regards to which charsets and to what extent they are supported. [2002-05-05 13:41:14] [EMAIL PROTECTED] well, then the it's not a bug, but then the documetation is a bit confusing: This function is identical to htmlspecialchars() in all ways, except that ALL characters which have HTML character entity equivalents are translated into these entities. and for em-dash for example there's a mdash; since html 4.0 [2002-05-05 05:23:39] [EMAIL PROTECTED] The code in ext/standard/html.c seems to only support entities found in the first 8 bits of a given charset, including utf-8. Windows code page 1252 is the only character set that has em and en dashes in this 8-bit area. Hence it is the only character set that will work like you expect it to. In other words, you need to use cp1252 as the third argument to htmlentities() and make sure that your input string is in cp1252 as well. Support for full utf-8 entities might be coming in a future release. Meanwhile, you can convert utf-8 to HTML's numeric character references with PHP's mbstring extension and this piece of code: $f = 0x; $convmap = array( /* !ENTITY % HTMLlat1 PUBLIC -//W3C//ENTITIES Latin 1//EN//HTML %HTMLlat1; */ 160, 255, 0, $f, /* !ENTITY % HTMLsymbol PUBLIC -//W3C//ENTITIES Symbols//EN//HTML %HTMLsymbol; */ 402, 402, 0, $f, 913, 929, 0, $f, 931, 937, 0, $f, 945, 969, 0, $f, 977, 978, 0, $f, 982, 982, 0, $f, 8226, 8226, 0, $f, 8230, 8230, 0, $f, 8242, 8243, 0, $f, 8254, 8254, 0, $f, 8260, 8260, 0, $f, 8465, 8465, 0, $f, 8472, 8472, 0, $f, 8476, 8476, 0, $f, 8482, 8482, 0, $f, 8501, 8501, 0, $f, 8592, 8596, 0, $f, 8629, 8629, 0, $f, 8656, 8660, 0, $f, 8704, 8704, 0, $f, 8706, 8707, 0, $f, 8709, 8709, 0, $f, 8711, 8713, 0, $f, 8715, 8715, 0, $f, 8719, 8719, 0, $f, 8721, 8722, 0, $f, 8727, 8727, 0, $f, 8730, 8730, 0, $f, 8733, 8734, 0, $f, 8736, 8736, 0, $f, 8743, 8747, 0, $f, 8756, 8756, 0, $f, 8764, 8764, 0, $f, 8773, 8773, 0, $f, 8776, 8776, 0, $f, 8800, 8801, 0, $f, 8804, 8805, 0, $f, 8834, 8836, 0, $f, 8838, 8839, 0, $f, 8853, 8853, 0, $f, 8855, 8855, 0, $f, 8869, 8869, 0, $f, 8901, 8901, 0, $f, 8968, 8971, 0, $f, 9001, 9002, 0, $f, 9674, 9674, 0, $f, 9824, 9824, 0, $f, 9827, 9827, 0, $f, 9829, 9830, 0, $f, /* !ENTITY % HTMLspecial PUBLIC -//W3C//ENTITIES Special//EN//HTML %HTMLspecial; */ /* These ones are excluded to enable HTML: 34, 38, 60, 62 * / 338, 339, 0, $f, 352, 353, 0, $f, 376, 376, 0, $f, 710, 710, 0, $f, 732, 732, 0, $f, 8194, 8195, 0, $f, 8201, 8201, 0, $f, 8204, 8207, 0, $f, 8211, 8212, 0, $f, 8216, 8218, 0, $f, 8218, 8218, 0, $f, 8220, 8222, 0, $f, 8224, 8225, 0, $f, 8240, 8240, 0, $f, 8249, 8250, 0, $f, 8364, 8364, 0, $f); echo mb_encode_numericentity($html, $convmap, UTF-8); [2002-05-04 23:10:19] [EMAIL PROTECTED] if i'm not wrong this function is supposed to encode all those special characters, right? well, em or en dashes are not encoded. the whole list of characters that should be encoded can be found here: http://selfhtml.teamone.de/html/referenz/zeichen.htm#benannte_interpunktion it's in german, but i guess you can see what i mean. -- Edit this bug report at http://bugs.php.net/?id=17008edit=1
Bug #17023: mysql_query: whitespace after ';' causes sql syntax error
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.2.0 PHP Bug Type: MySQL related Bug description: mysql_query: whitespace after ';' causes sql syntax error Note the trailing whitespace in query: ? mysql_select_db(test); mysql_query(select * from tab; ); echo mysql_error(); ? Result: You have an error in your SQL syntax near '; ' at line 1 Again, note the trailing whitespace. Without it, it's OK. It's particullary annoying with heredoc syntax. -- Edit bug report at http://bugs.php.net/?id=17023edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=17023r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=17023r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=17023r=needtrace Try newer version: http://bugs.php.net/fix.php?id=17023r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=17023r=support Expected behavior: http://bugs.php.net/fix.php?id=17023r=notwrong Not enough info: http://bugs.php.net/fix.php?id=17023r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=17023r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=17023r=globals
Bug #17008 Updated: htmlentities() doesn't encode em or en dash
ID: 17008 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: *General Issues Operating System: WinXP / Apache 1.3.24 PHP Version: 4.2.0 New Comment: great. thanks for putting it from the buglist to the wishlist :-) Previous Comments: [2002-05-05 19:08:06] [EMAIL PROTECTED] I've committed a fix that adds support for the remaining html4 entities to the CVS HEAD. You need to be using the utf-8 encoding for these characters to be detected/converted. This change will be in 4.3.0 [2002-05-05 17:46:11] [EMAIL PROTECTED] The docs also say that iso-8859-1 charset is assumed; there are no em or en dash characters in that charset. But you are correct in that the docs are not up to date with regards to which charsets and to what extent they are supported. [2002-05-05 13:41:14] [EMAIL PROTECTED] well, then the it's not a bug, but then the documetation is a bit confusing: This function is identical to htmlspecialchars() in all ways, except that ALL characters which have HTML character entity equivalents are translated into these entities. and for em-dash for example there's a mdash; since html 4.0 [2002-05-05 05:23:39] [EMAIL PROTECTED] The code in ext/standard/html.c seems to only support entities found in the first 8 bits of a given charset, including utf-8. Windows code page 1252 is the only character set that has em and en dashes in this 8-bit area. Hence it is the only character set that will work like you expect it to. In other words, you need to use cp1252 as the third argument to htmlentities() and make sure that your input string is in cp1252 as well. Support for full utf-8 entities might be coming in a future release. Meanwhile, you can convert utf-8 to HTML's numeric character references with PHP's mbstring extension and this piece of code: $f = 0x; $convmap = array( /* !ENTITY % HTMLlat1 PUBLIC -//W3C//ENTITIES Latin 1//EN//HTML %HTMLlat1; */ 160, 255, 0, $f, /* !ENTITY % HTMLsymbol PUBLIC -//W3C//ENTITIES Symbols//EN//HTML %HTMLsymbol; */ 402, 402, 0, $f, 913, 929, 0, $f, 931, 937, 0, $f, 945, 969, 0, $f, 977, 978, 0, $f, 982, 982, 0, $f, 8226, 8226, 0, $f, 8230, 8230, 0, $f, 8242, 8243, 0, $f, 8254, 8254, 0, $f, 8260, 8260, 0, $f, 8465, 8465, 0, $f, 8472, 8472, 0, $f, 8476, 8476, 0, $f, 8482, 8482, 0, $f, 8501, 8501, 0, $f, 8592, 8596, 0, $f, 8629, 8629, 0, $f, 8656, 8660, 0, $f, 8704, 8704, 0, $f, 8706, 8707, 0, $f, 8709, 8709, 0, $f, 8711, 8713, 0, $f, 8715, 8715, 0, $f, 8719, 8719, 0, $f, 8721, 8722, 0, $f, 8727, 8727, 0, $f, 8730, 8730, 0, $f, 8733, 8734, 0, $f, 8736, 8736, 0, $f, 8743, 8747, 0, $f, 8756, 8756, 0, $f, 8764, 8764, 0, $f, 8773, 8773, 0, $f, 8776, 8776, 0, $f, 8800, 8801, 0, $f, 8804, 8805, 0, $f, 8834, 8836, 0, $f, 8838, 8839, 0, $f, 8853, 8853, 0, $f, 8855, 8855, 0, $f, 8869, 8869, 0, $f, 8901, 8901, 0, $f, 8968, 8971, 0, $f, 9001, 9002, 0, $f, 9674, 9674, 0, $f, 9824, 9824, 0, $f, 9827, 9827, 0, $f, 9829, 9830, 0, $f, /* !ENTITY % HTMLspecial PUBLIC -//W3C//ENTITIES Special//EN//HTML %HTMLspecial; */ /* These ones are excluded to enable HTML: 34, 38, 60, 62 * / 338, 339, 0, $f, 352, 353, 0, $f, 376, 376, 0, $f, 710, 710, 0, $f, 732, 732, 0, $f, 8194, 8195, 0, $f, 8201, 8201, 0, $f, 8204, 8207, 0, $f, 8211, 8212, 0, $f, 8216, 8218, 0, $f, 8218, 8218, 0, $f, 8220, 8222, 0, $f, 8224, 8225, 0, $f, 8240, 8240, 0, $f, 8249, 8250, 0, $f, 8364, 8364, 0, $f); echo mb_encode_numericentity($html, $convmap, UTF-8); [2002-05-04 23:10:19] [EMAIL PROTECTED] if i'm not wrong this function is supposed to encode all those special characters, right? well, em or en dashes are not encoded. the whole list of characters that should be encoded can be found here: http://selfhtml.teamone.de/html/referenz/zeichen.htm#benannte_interpunktion it's in german, but i guess you can see what i mean. -- Edit this bug report at http://bugs.php.net/?id=17008edit=1
Bug #14076 Updated: fopen() and touch() fail to create file under safe mode
ID: 14076 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: No Feedback +Status: Open Bug Type: *Directory/Filesystem functions Operating System: Linux PHP Version: 4.0.6 Previous Comments: [2002-05-04 03:55:59] [EMAIL PROTECTED] I don't seem to be able to change the status to Open... How do I do it?! [2002-05-04 03:53:18] [EMAIL PROTECTED] Erm... Hajo provided feedback. [2002-05-04 00:00:04] [EMAIL PROTECTED] No feedback was provided for this bug for over a month, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2002-04-17 03:35:34] [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I could not reproduce this issue. Here's my layout for the virtual server (from httpd.conf) The symlink has to be *within* path_to_site, e.g.: /var/www/ = symlink to /mnt/sda1/www /var/www/domain.com = apache document_root = php open_basedir Please see my posting from 16 Jan 1:21pm for details ( http://bugs.php.net/bug.php?id=14076 ). Hajo [2002-04-16 07:33:57] [EMAIL PROTECTED] I could not reproduce this issue. Here's my layout for the virtual server (from httpd.conf): DocumentRoot /path_to_site/html Options FollowSymLinks php_admin_value open_basedir path_to_sitephp_admin_value doc_root path_to_site php_admin_value safe_mode_include_dir path_to_site safe_mode=on in php.ini PHP version: both 4.0.6 and 4.2.0RC2 create PHP-script at path_to_site/html/scriptname create directory path_to_site/html/test writable by the apache user, then make symlink path_to_site/html/test2 to that directory ? $fh=fopen($DOCUMENT_ROOT/test2/1.txt, w); fwrite($fh, test\n); echo $fh,\n; fclose($fh); mkdir($DOCUMENT_ROOT/test2/xxx/,770); ? lynx http://sitename/scriptname gives Resource id#1 No errors found in php_error_log, looked at path_to_site/html/test2/ and saw there both 1.txt contained test and xxx subdirectory. 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/14076 -- Edit this bug report at http://bugs.php.net/?id=14076edit=1
Bug #17021 Updated: PHP_SELF Displays nothing
ID: 17021
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Analyzed
Bug Type: Other web server
Operating System: Windows XP Pro
PHP Version: 4.2.0
New Comment:
quite frankly, xitami gives extremely strange results, for lots of
issues.
have you considered using another server, such as apache for windows?
Previous Comments:
[2002-05-05 17:19:55] [EMAIL PROTECTED]
Upon closer inspectation of the CGI code I it seems your webserver
doesn't properly set the environment varaibles needed for PHP to
construct the PHP_SELF variable.
CGI needs to have either PATH_INFO or SCRIPT_NAME to be set via the
environment. That's the only possibility why PHP_SELF is simply empty.
Since I'm not that familiar with Xitami I can't say if it's a bug
there, but you might want to check in Xitami related forums to get a
quicker answer.
[2002-05-05 17:04:25] [EMAIL PROTECTED]
Changing category.
Seems to be a Xitami or CGI issue then (sorry I seem to have misread
you were using Xitami).
[2002-05-05 16:52:28] [EMAIL PROTECTED]
The script doesn't show anything. Just says _SERVER[PHP_SELF] in
the first column and nothing in the second column.
See for your self. http://www.dgtechnology.com/server.php
Make sure to keep the www..
Thanks
David
[2002-05-05 16:39:51] [EMAIL PROTECTED]
No, echo $PHP_SELF or var_dump(${PHP_SELF) *cannot* display PHP_SELF
unless you disabled php parsing or whatever.
Anyway, what does phpinfo() output say about PHP_SELF, does it show
anywhere up in the page? If so, where (paste the appropriate table
line) ?
And, also double check the register_globals ini setting in your
phpinfo() output. I still think you have it disabled.
[2002-05-05 16:31:38] [EMAIL PROTECTED]
NOTHING. It doesn't output anything. Stays blank, on a Redhat Linux,
using Apache 1.3 it works. It displays PHP_SELF.
Thanks
David
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/17021
--
Edit this bug report at http://bugs.php.net/?id=17021edit=1
Bug #17024: Unexpected blocking
From: [EMAIL PROTECTED]
Operating system: W2K Server
PHP version: 4.2.0
PHP Bug Type: ODBC related
Bug description: Unexpected blocking
I am seeing some unexpected blocking of PHP/ODBC scripts. I'm running the
two scripts in two separate browser windows. If the first PHP script is
running, and the second PHP script is started, the second script won't run
until the first one completes. I've isolated this down to either apache
or php blocking. I'm unable to trace any further, but willing to assist,
and grant access to my server.
My platform is W2K Server w/SP2, SQL Server 2000 8.00.194, Apache, and php
4.2.0 (binary distribution). I'm embarassed to say I don't know how to
determine the exact version of apache I've installed, but it is 1.3.x.
I have two scipts and one C++ program that illustrate the issue; you'll
need VC++ to compile this (or I can send the EXE file to you).
---helloA.php-
?
session_start();
system(phpbug.exe);
?
--
---helloB.php-
?
session_start();
$db = odbc_connect(ehp,ehp,ehp);
$query = select 'Hello, beautiful world';
$result = odbc_exec($db,$query);
odbc_result_all($result);
?
--
---phpbug.cpp-
#include winsock2.h
#include windows.h
#include list
#include string
#include utility
#include sqltypes.h
#include sql.h
#include sqlext.h
#include tapeUtilNonOverlapped.h
#define createSqlStmtHandle(connectionHandle, newStmtHandle) { \
SQLRETURN rc; \
if ((rc = SQLAllocHandle(SQL_HANDLE_STMT, connectionHandle,
newStmtHandle))!=SQL_SUCCESS) { \
char mySQLState[10]; \
long myNativeError; \
char myMsgText[300]; \
short lengthOfMyMsgText; \
SQLGetDiagRec(SQL_HANDLE_STMT, newStmtHandle, 1, (unsigned char *)
mySQLState, myNativeError, (unsigned char *) myMsgText, 300,
lengthOfMyMsgText); \
exit(5011); \
} \
}
void ehpSqlPrepare(SQLHSTMT handle, std::string sqlCmd) {
SQLRETURN rc = SQLPrepare(handle, (unsigned char *)
sqlCmd.c_str(),SQL_NTS);
if (rc!=SQL_SUCCESS) {
char mySQLState[10];
long myNativeError;
char myMsgText[300];
short lengthOfMyMsgText;
rc = SQLGetDiagRec( SQL_HANDLE_STMT, handle, 1, (unsigned char *)
mySQLState, myNativeError, (unsigned char *) myMsgText, 300,
lengthOfMyMsgText);
std::string err = ehpSqlPrepare: couldn't prepare handle: ;
err.append(myMsgText, lengthOfMyMsgText);
exit(5010);
}
}
main(int argc,char * argv[]) {
SQLHENV myEnvHandle;// odbc environment handle
SQLHDBC myDbcHandle;// obdc connection handle
SQLHSTMT myStmtHandle;
int rc; // return code for various system
calls
std::string myDSN = ehp; // DSN to connect using
std::string myUserName = ehp; // login to use when connecting
std::string myPassWord = ehp; // password to use when connecting
std::string myQuery = select 'Hello, World';
// set up an ODBC environment handle, request ODBC V3, set up an ODBC
connector handle
if ((rc=SQLAllocHandle(SQL_HANDLE_ENV, SQL_NULL_HANDLE,
myEnvHandle))!=SQL_SUCCESS) {
exit(5001);
}
if ((rc=SQLSetEnvAttr(myEnvHandle, SQL_ATTR_ODBC_VERSION, (SQLPOINTER)
SQL_OV_ODBC3,0))!=SQL_SUCCESS) {
exit(5002);
}
if ((rc=SQLAllocHandle(SQL_HANDLE_DBC, myEnvHandle,
myDbcHandle))!=SQL_SUCCESS) {
exit(5003);
}
// connect the ODBC connector handle to DSN
rc = SQLConnect(myDbcHandle, (SQLCHAR *) myDSN.c_str(), (SQLSMALLINT)
myDSN.size()+1, (SQLCHAR *) myUserName.c_str(),
(SQLSMALLINT) myUserName.size()+1, (SQLCHAR *) myPassWord.c_str(),
(SQLSMALLINT) myPassWord.size()+1);
if ((rc!=SQL_SUCCESS)(rc!=SQL_SUCCESS_WITH_INFO)) {
exit(5020);
}
int SCV=SQL_CONCUR_VALUES;
// set the connection attributes for server-side cursors
if ((SQLSetConnectAttr(myDbcHandle,SQL_ATTR_CONCURRENCY,(void *)
SQL_CONCUR_VALUES,0))!=SQL_SUCCESS) {
exit(5021);
}
// create a statment handle
if ((SQLAllocHandle(SQL_HANDLE_STMT, myDbcHandle,
myStmtHandle))!=SQL_SUCCESS) {
exit(5011);
}
// prepare a statement
if((SQLPrepare(myStmtHandle, (unsigned char *)
myQuery.c_str(),SQL_NTS))!=SQL_SUCCESS) {
exit(5044);
}
// note that no query actually gets executed
// this is where the long-running activities occur,
Bug #17025: Missing dll's
From: [EMAIL PROTECTED] Operating system: Win2k PHP version: 4.2.0 PHP Bug Type: *Configuration Issues Bug description: Missing dll's Hi, the distribution of PHP 4.2.0 for Apache/Win2k seems incomplete. Two files for extensions are missing (even a search for files didn't find them: *imap*.dll and *snmp*.dll): php_imap.dll and php_snmp.dll [EMAIL PROTECTED] (Please check out my other post on php_gd.dll - php_gd2.dll - same topic) -- Edit bug report at http://bugs.php.net/?id=17025edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=17025r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=17025r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=17025r=needtrace Try newer version: http://bugs.php.net/fix.php?id=17025r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=17025r=support Expected behavior: http://bugs.php.net/fix.php?id=17025r=notwrong Not enough info: http://bugs.php.net/fix.php?id=17025r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=17025r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=17025r=globals
Bug #17026: Possible bug in php.ini-dist/Extensions: php_gd.dll - php_gd2.dll
From: [EMAIL PROTECTED] Operating system: Win2k PHP version: 4.2.0 PHP Bug Type: *Configuration Issues Bug description: Possible bug in php.ini-dist/Extensions: php_gd.dll - php_gd2.dll Hi, the php.ini-dist seems to have a bug in the extensions section. php_gd.dll should be php_gd2.dll to be found when loading. This is because you renamed the dll, but forgot to rename the name of the dll in php.ini-dist. This might cause trouble for some users. Please read my bug-report for missing files too... Thanks, Liquid -- Edit bug report at http://bugs.php.net/?id=17026edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=17026r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=17026r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=17026r=needtrace Try newer version: http://bugs.php.net/fix.php?id=17026r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=17026r=support Expected behavior: http://bugs.php.net/fix.php?id=17026r=notwrong Not enough info: http://bugs.php.net/fix.php?id=17026r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=17026r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=17026r=globals
Bug #15526 Updated: Uploading of binary file
ID: 15526
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: No Feedback
Bug Type: Unknown/Other Function
Operating System: linux
PHP Version: 4.1.1
New Comment:
No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.
Previous Comments:
[2002-04-03 02:52:50] [EMAIL PROTECTED]
Could you try 4.2.0RC1?
Please visit http://qa.php.net/ for 4.2.0RC1.
[2002-02-12 12:58:22] [EMAIL PROTECTED]
//When some binary data are send to this script it cause netscape
//unstable because PHP engine read STDIN incorrectly.
//I have try to read this data with script in perl an it was
successful.
//I append apache logs that this incorrect reading of input causes.
//x.y.x.z - - [12/Feb/2002:17:28:31 +0100] POST /IR/Edit/index.php
//HTTP/1.0 200 431 /IR/Edit/index.php Mozilla/4.77 [en] (X11; U;
//Linux 2.4.2-2 i686)
//x.y.x.z - - [12/Feb/2002:17:28:31 +0100]
9DÓYÓÓ+kµ9C9AYŦ|]z/ì;¦
//85ÜÕÃÜ$ÿ#]Ògbu\¨Òe½³87^B 200 5364 - -
//first log is ok
//but second is proof of this uncorrect STDIN reading
//it not depend if function
//move_uploaded_file($HTTP_POST_FILES['userfile'],/place/to/put/uploaded///file);
//or
//copy($HTTP_POST_FILES['userfile']['tmp_name'],/place/to/put/uploaded/file);
//are used.
//This error don't occure if I try to upload file of text/plain.
//But have been occuring ever when I try to read i.e. image/gif
TABLE bgcolor=#ff
FORM ENCTYPE=multipart/form-data METHOD=POST ACTION=?PHP
echo http://$SERVER_NAME$SCRIPT_NAME;;
// echo http://$SERVER_NAME/cgi-bin/UpLoader;;
?
TRTD/TDTD/TD/TR
TRTDSample name:/TDTDINPUT NAME=Sample TYPE=TEXT/TD/TR
TRTD valign=topNotes:/TDTDTEXTAREA NAME=SpNotes ROWS=5
COLS=50/TEXT
AREA/TD/TR
INPUT TYPE=hidden name=MAX_FILE_SIZE value=100
TRTDSend this file: /TDTDINPUT NAME=userfile
TYPE=file/TD/TR
TRTDINPUT TYPE=submit VALUE=Send File/TDTDINPUT
TYPE=reset/TD
/TR
/FORM
/TABLE
?PHP
$Sample = preg_replace(/[^a-zA-Z0-9]/,,$Sample);
if ($Sample != )
{
if (move_uploaded_file($HTTP_POST_FILES['userfile'], $IRDirectory .
$Sample
. .ir ))
{
if ($SpNotes != )
{
$fp = fopen($IRDirectory . $Sample . .txt,w+);
fwrite($fp, $SpNotes);
fclose($fp);
}
}
else
{
echo File not found !!!\n;
}
}
--
Edit this bug report at http://bugs.php.net/?id=15526edit=1
Bug #14865 Updated: php4apache.dll - phpinfo error - winXP - Apache
ID: 14865 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Apache related Operating System: Win XP Prof PHP Version: 4.1.1 New Comment: No feedback was provided for this bug for over a month, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. Previous Comments: [2002-05-03 04:33:47] [EMAIL PROTECTED] Same problem... OS: Windows XP Professional (5.1.2600 Build 2600) PHP: 4.2.0 Win32 Apache: 2.35 Win32 PHP Installed as module Testing Apache Config: Cannot load c:/Program Files/PHP/sapi/php4apache.dll into server: The specified module could not be found. [Apache will not start] Keep me informed. [2002-04-05 06:34:55] [EMAIL PROTECTED] When you updated, did you also update the php4ts.dll ?? Try PHP 4.2.0RC2 from http://www.php.net/~derick/ (and don't forget to replace php4ts.dll in your system with the one in that package) [2002-04-05 02:30:23] [EMAIL PROTECTED] Same problems as everyone else has, I didn't realize it wasn't me until I saw this post. I have: OS: Windows XP Professional (Build: 2600) PHP: 4.2.0RC1 Apache: 1.3.23 PHP Installed as module First time I noticed this was with phpinfo() flashing like 10 times and then displaying the phpinfo page, or sometimes after the flashing would display dns error page. It's not something that happens every time, and some days are also better than others and I don't expierience any problems related to this. In fact when I'm using 'localhost' this doesn't happen to me. And in fact when I surf the pages myself, phpinfo loads just fine. But as soon as someone else tries to run my scripts it starts tweaking out on them. Every time they try they say phpinfo page will load anywhere from %15 to like %90 and then it will just cut off or turn into compiled code as they put it, or simply...garbage. The point at which it starts to garble or cut off is random and unpredictable. As soon as anyone gets a fix for this it would be great if they would let everyone know! :) It's annoying not being able to share my code I've worked so hard on with other people... [2002-04-03 20:54:29] [EMAIL PROTECTED] I get a similar difficulty, but with ANY scripts no matter how small or large. 90% of the time it works perfectly, then all of a sudden PHP decides to spew a parse error or some other random phenomenon - even a single one line script will eventually suffer this fault. I experienced this when I moved to PHP 4.1.x, so reverted back to 4.0.6 which does not have the problem. Unfortunately 4.1.2 is a security fix so obviously have to upgrade, and now having to live with this problem. Not sure if its related, but 4.1.x also causes Apache's memory use to grow and grow and GROW until eventually a malloc fault occurrs. Sometimes Apache will restart, sometimes just crash. Again 4.0.6 has no such problem, just 4.1.x - had no choice but to configure Apache to self-restart every few hundred hits to overcome this memory leak. This is all with PHP as a Apache module. [2002-03-25 15:38:20] [EMAIL PROTECTED] I too am having the same problem. WinXP, Apache/1.3.22 (Win32), PHP/4.1.3-dev, mod_perl/1.26. PHP installed as a module. I haven't tried using it in CGI mode. It's not just phpinfo(). It happens regularly. Try going to: http://singularity.homedns.org/calendar/index.php Hit reload a few times, move to another month, etc. Eventually it will hose up. Spews garbage characters in the middle of the page. I understand going back to 4.0.6 seems to fix it, but I'd rather not. Any help would be..wellhelpful. IanW IanW 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/14865 -- Edit this bug report at http://bugs.php.net/?id=14865edit=1
Bug #17027: Post and Get variables can not passed to php
From: [EMAIL PROTECTED] Operating system: Red Hat Linux 7.0 PHP version: 4.2.0 PHP Bug Type: *Configuration Issues Bug description: Post and Get variables can not passed to php I install php4.2.0 on a Redhat 7.0 platform as following,when done,the Apache Server can not receive all the post and get data sent from browser,so I changed into old php-4.0.6 with the same instllation procedure,it succeded,I think there is a bug with --enable-track-vars tar xvzf apache_1.3.24.tar.gz ./configure --prefix=/www tar xvzf php-4.2.0.tar.gz ./configure --with-mysql=/usr/local/mysql --with-apache=../apache_1.3.24 --enable-track-vars make make install cp php.ini-dist /usr/local/lib/php.ini cd ../apache_1.3.24 ./configure --prefix=/www --activate-module=src/modules/php4/libphp4.a --enable-module=so -- Edit bug report at http://bugs.php.net/?id=17027edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=17027r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=17027r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=17027r=needtrace Try newer version: http://bugs.php.net/fix.php?id=17027r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=17027r=support Expected behavior: http://bugs.php.net/fix.php?id=17027r=notwrong Not enough info: http://bugs.php.net/fix.php?id=17027r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=17027r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=17027r=globals
Bug #17027 Updated: Post and Get variables can not passed to php
ID: 17027 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: *Configuration Issues Operating System: Red Hat Linux 7.0 PHP Version: 4.2.0 New Comment: Turn on register_globals in your php.ini file. (I wonder how many more of these we will get? I predict a couple of hundred...) Previous Comments: [2002-05-06 00:16:03] [EMAIL PROTECTED] I install php4.2.0 on a Redhat 7.0 platform as following,when done,the Apache Server can not receive all the post and get data sent from browser,so I changed into old php-4.0.6 with the same instllation procedure,it succeded,I think there is a bug with --enable-track-vars tar xvzf apache_1.3.24.tar.gz ./configure --prefix=/www tar xvzf php-4.2.0.tar.gz ./configure --with-mysql=/usr/local/mysql --with-apache=../apache_1.3.24 --enable-track-vars make make install cp php.ini-dist /usr/local/lib/php.ini cd ../apache_1.3.24 ./configure --prefix=/www --activate-module=src/modules/php4/libphp4.a --enable-module=so -- Edit this bug report at http://bugs.php.net/?id=17027edit=1
Bug #17028: [chm] bug on language.types.resource.html
From: [EMAIL PROTECTED] Operating system: windows PHP version: 4.1.2 PHP Bug Type: Documentation problem Bug description: [chm] bug on language.types.resource.html I have found a bug on page language.types.resource.html [chm date: 2002-04-20]... I don't know if this is exactly a bug...it seems to do with IE 5.5 and script debugging. (I do have Microsoft Script Debugger installed on my system.) Even though I have script debugging turned off (and continue flag set to true when scripting errors encountered) I still get this pop-up on most pages in the .chm format help file: Internet Explorer Script Error An error has occurred in the script on this page. Line: 3 Char: 25 Error: 'document.all.unotes' is null or not an object Code: 0 URL: ... Do you want to continue running scripts on this page? Yes|No Line number, character number and error message seem to remain constant on all pages where this occurs. Thanks, Dennis Williams -- Edit bug report at http://bugs.php.net/?id=17028edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=17028r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=17028r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=17028r=needtrace Try newer version: http://bugs.php.net/fix.php?id=17028r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=17028r=support Expected behavior: http://bugs.php.net/fix.php?id=17028r=notwrong Not enough info: http://bugs.php.net/fix.php?id=17028r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=17028r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=17028r=globals
Bug #17023 Updated: mysql_query: whitespace after ';' causes sql syntax error
ID: 17023 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: MySQL related Operating System: Linux PHP Version: 4.2.0 New Comment: Lose the ; and it will always work. The ; is not needed from mysql_query(). Not a bug - Bogus. Previous Comments: [2002-05-05 19:31:10] [EMAIL PROTECTED] Note the trailing whitespace in query: ? mysql_select_db(test); mysql_query(select * from tab; ); echo mysql_error(); ? Result: You have an error in your SQL syntax near '; ' at line 1 Again, note the trailing whitespace. Without it, it's OK. It's particullary annoying with heredoc syntax. -- Edit this bug report at http://bugs.php.net/?id=17023edit=1
Bug #16964 Updated: error in ODBC_FETCH_INTO()
ID: 16964 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Documentation problem Operating System: Winnt PHP Version: 4.2.0 New Comment: I read the english doku and I have see this example. But normaly I read the German Doku and there is no example about the version 4.2 . Thanks for help. Chris Previous Comments: [2002-05-03 08:48:28] [EMAIL PROTECTED] No, that is the valid format. Please read the odbc_fetch_into documentation very carefully, and you will find the last example for PHP 4.2.0 shows what you are saying. Albiet it can be further marked. [2002-05-03 01:12:21] [EMAIL PROTECTED] This was not a question to the support. I think The doku from PHP is false. The Version 4.1 from PHP was this correct :int odbc_fetch_into ( int result_id [, int rownumber, array result_array].And in the Version 4.2 you must do int odbc_fetch_into ( int result_id [, array result_array, int rownumber]). This is not correct. [2002-05-02 10:25:54] [EMAIL PROTECTED] It's a docu problem. [2002-05-02 10:23:33] [EMAIL PROTECTED] The bug system is not the appropriate forum for asking support questions. For a list of a range of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php Please read the manual. [2002-05-02 09:21:31] [EMAIL PROTECTED] Doku: int odbc_fetch_into ( int result_id [, int rownumber, array result_array]) don´t work this is okay : int odbc_fetch_into ( int result_id [, array result_array, int rownumber]) -- Edit this bug report at http://bugs.php.net/?id=16964edit=1
