#21499 [WFx->Opn]: include 'bogus'; refers to bogus function.main
ID: 21499 Updated by: [EMAIL PROTECTED] -Summary: include 'bogus' gives unfriendly error Reported By: [EMAIL PROTECTED] -Status: Won't fix +Status: Open Bug Type: Unknown/Other Function Operating System: all PHP Version: 4.3.0 New Comment: The fact that it provides two 404 links to a non-existent PHP function named main() is rather misleading and is not reasonable. I didn't call/use any function named main(), I used include(). Fact is, include() could not include the file because the file could not be opened. Simply "Failed opening foo for inclusion" is enough, like it used to be before php_error_docref. Linking to function.include would be fine too. IMHO this should remain open until someone fixes it. I would put php_error_docref in the summary but I really don't know the internals or if that's the problem. Previous Comments: [2003-01-07 17:36:43] [EMAIL PROTECTED] Since include is not a function but rather a language construct this is unlikely to be ever fixed. The error as is, imo is reasonably descriptive as it tells what action had failed and why. [2003-01-07 14:28:43] [EMAIL PROTECTED] This isn't a feature request Nicos, this is a bug. It refers/links to a non-existent function/page in the error. [2003-01-07 14:15:48] [EMAIL PROTECTED] Reclassifing. [2003-01-07 14:02:01] [EMAIL PROTECTED] Warning: main(foo) [function.main]: failed to create stream: No such file or directory in... Warning: main() [function.main]: Failed opening 'foo' for inclusion (include_path='.') in... Basically, this error could be a little nicer and in the very least link to function.include and not a non-existent function.main. This is the case with all the include/require constructs. -- Edit this bug report at http://bugs.php.net/?id=21499&edit=1
#17158 [Csd->Bgs]: setcookie()
ID: 17158
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Closed
+Status: Bogus
Bug Type: Feature/Change Request
Operating System: n/a
PHP Version: 4.2.0
New Comment:
You only need one click. set, click, read (tm).
Previous Comments:
[2003-01-09 00:56:27] [EMAIL PROTECTED]
Ok, but how many times do you have to press submit before the browser
actually acts. Click #1 sets the cookie, click #2 is able to read the
cookie change. 1 click too many in my opinion.
[2003-01-08 21:31:43] [EMAIL PROTECTED]
Exactly, PHP is server-side... So this is a restriction of the
server-side theory. Javascript is a client-side browser controlled
language, it is not executed on the server at all.
[2002-05-11 16:37:39] [EMAIL PROTECTED]
Javascript cookies are client-side which is an entirely different
thing. If you want to get around header() and setcookie() limitations,
take a look at http://www.php.net/manual/en/ref.outcontrol.php
[2002-05-11 16:36:26] [EMAIL PROTECTED]
this is because JS has dircet access to the browser., whereas PHP has
not. it is a limitation of HTTP in general and cookies in particular.
so the docs are right. no bug -> bogus
[2002-05-11 16:30:26] [EMAIL PROTECTED]
setcookie() states "cookies must be sent before any other headers are
sent (this is a restriction of cookies, not PHP).
http://www.php.net/manual/en/function.setcookie.php
I would like to suggest this is a restriction of PHP, not cookies.
I can send and read cookies right in the middle of my HTML
when I use Javascript:
http://www.collegeSherbrooke.qc.ca/languesmodernes/cookie.htm
setCookie("TestCookie","first time",expdate);
var DisplayData = getCookie("TestCookie");
document.write(DisplayData);
document.write("
");
setCookie("TestCookie","second time",expdate);
var DisplayData = getCookie("TestCookie");
document.write(DisplayData);
When can we expect a feature change on setcookie() ?
--
Edit this bug report at http://bugs.php.net/?id=17158&edit=1
#21499 [NEW]: include 'bogus' gives unfriendly error
From: [EMAIL PROTECTED] Operating system: all PHP version: 4.3.0 PHP Bug Type: Unknown/Other Function Bug description: include 'bogus' gives unfriendly error Warning: main(foo) [function.main]: failed to create stream: No such file or directory in... Warning: main() [function.main]: Failed opening 'foo' for inclusion (include_path='.') in... Basically, this error could be a little nicer and in the very least link to function.include and not a non-existent function.main. This is the case with all the include/require constructs. -- Edit bug report at http://bugs.php.net/?id=21499&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21499&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21499&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21499&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21499&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21499&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21499&r=support Expected behavior: http://bugs.php.net/fix.php?id=21499&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21499&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21499&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21499&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21499&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21499&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21499&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21499&r=gnused
#21499 [Opn]: include 'bogus' gives unfriendly error
ID: 21499 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open -Bug Type: Feature/Change Request +Bug Type: Unknown/Other Function Operating System: all PHP Version: 4.3.0 New Comment: This isn't a feature request Nicos, this is a bug. It refers/links to a non-existent function/page in the error. Previous Comments: [2003-01-07 14:15:48] [EMAIL PROTECTED] Reclassifing. [2003-01-07 14:02:01] [EMAIL PROTECTED] Warning: main(foo) [function.main]: failed to create stream: No such file or directory in... Warning: main() [function.main]: Failed opening 'foo' for inclusion (include_path='.') in... Basically, this error could be a little nicer and in the very least link to function.include and not a non-existent function.main. This is the case with all the include/require constructs. -- Edit this bug report at http://bugs.php.net/?id=21499&edit=1
#21102 [NoF->Opn]: stat, lstat fail if filesize larger than 2 GB
ID: 21102 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: No Feedback +Status: Open Bug Type: *Directory/Filesystem functions Operating System: solaris -PHP Version: 4.2.3 +PHP Version: 4.4.0-dev New Comment: Updating -> 4.4.0-dev / open Previous Comments: [2003-01-11 20:10:51] [EMAIL PROTECTED] [unable to edit bug report] latest CVS tarball does not fix the bug, example still fails with latest release. [2003-01-09 01:00:02] [EMAIL PROTECTED] No feedback was provided for this bug for over 2 weeks, 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-12-22 00:55:50] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-12-19 18:52:37] [EMAIL PROTECTED] ~ if the file /tmp/very_large_file is larger than 2 GB, php reports the error: Warning: stat failed for /tmp/very_large_file (errno=79 - Value too large for defined data type) php_4.2.3 is compiled as an apache_1.3.27 module -- Edit this bug report at http://bugs.php.net/?id=21102&edit=1
#20441 [Csd]: PHP_AUTH_USER isn't set
ID: 20441 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Apache related Operating System: all PHP Version: 4.3.0 New Comment: For the record, the last comment was found to be bogus in bug #21620. And on a unrelated note, it's recommended to not rely on the register_globals directive so use $_SERVER['REMOTE_USER'] not $REMOTE_USER. Previous Comments: [2003-01-13 11:33:03] [EMAIL PROTECTED] The suggestion that $REMOTE_USER still works and can be used in Safe mode is only party true. I noticed that this variable is filled with the username supplied by the external basic auth mechanism (.htaccess) unless you are in a script which has been called by a . With method="get" it works OK. I need the $REMOTE_USER to lookup users from the database and find their ID in the DB. The method="get" option is a workaround, but this does not work in upload scripts, which has to use "post". Is this a new bug? [2002-12-21 15:16:22] [EMAIL PROTECTED] It has been agreed in php-dev to keep the PHP_AUTH_* variables but to disable them when in safe mode. This change was made after 4.3.0-RC4 but will exist in PHP 4.3.0. This is from the PHP 4.3.0 NEWS: Make PHP_AUTH_* variables not available in safe mode under Apache when an external basic auth mechanism is used. (Philip) REMOTE_USER will exist regardless. In the future, a new ini directive such as expose_php_auth_vars may be available. The docs will be updated. [2002-12-18 15:21:10] [EMAIL PROTECTED] This needs to be fixed before 4.3 goes out. While it is of course important to improve the code and iron out long standing errors, we must not forget that our users rely on the old behaviour. The default behaviour of 4.3 should be the same as in old versions. [2002-12-18 13:29:19] [EMAIL PROTECTED] This problem has just caused me a big headache - a customer has been relying on the fact that both .htaccess and PHP_AUTH_USER have been available in parallel since at least PHP 4. They've asked me to fix their scripts, but it would be a massive rewrite to sort out. I only have two customers who do their own scripting, and 50% of them are bitten by this. I think that 4.3.0 may well annoy lots of people with this. I can see from the documentation of bug #19251 why the change has been made, and I understand that that the manual documents the new behaviour, but I suspect this misbehaviour is widely relied upon, and perhaps we should consider an php.ini switch. The only economic solution I can suggest for my customer in the meanwhile is for me to patch php back to its old behaviour. [2002-12-11 10:58:19] [EMAIL PROTECTED] We fixed a bug, period. Derick 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/20441 -- Edit this bug report at http://bugs.php.net/?id=20441&edit=1
#21674 [Fbk]: Warning: main(lang.php) [function.main]: failed to create stream: No such file
ID: 21674
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: *URL Functions
Operating System: Cobalt RAQ4 Apache/Linux
PHP Version: 4.3.0
New Comment:
Your error is from include not require, are you sure this is the
correct code? Require is fatal; something is fishy here.
Previous Comments:
[2003-01-15 22:33:10] [EMAIL PROTECTED]
and do the files:
/home/sites/site2/web/IV/lang.php
/home/sites/site2/web/IV/extras.php
exist?
[2003-01-15 22:29:52] [EMAIL PROTECTED]
Your include_path is empty ''; are you sure that this is correct?
[2003-01-15 22:10:32] [EMAIL PROTECTED]
Warning: main(lang.php) [function.main]: failed to create stream: No
such file or directory in /home/sites/site2/web/IV/config.php on line
97
Just upraded to 4.3.0 from 4.1.2
Issue involves the following:
Same server
Two (2) seperate virtual domains
Scripts worked find before upgrade.
I am running a local php script located at
/home/sites/site3/web/powerpage.php
powerpage.php has a line that does a require_once to a remote file
config.php located on (same server) located at
/home/sites/site2/web/IV/config.php
Sample:
require_once ("/home/sites/site2/web/IV/config.php");
langtop();
The followng errors occur when I now try to run this local script
Warning: main(lang.php) [function.main]: failed to create stream: No
such file or directory in /home/sites/site2/web/IV/config.php on line
97
Warning: main() [function.main]: Failed opening 'lang.php' for
inclusion (include_path='') in /home/sites/site2/web/IV/config.php on
line 97
Warning: main(extras.php) [function.main]: failed to create stream: No
such file or directory in /home/sites/site2/web/IV/config.php on line
98
Warning: main() [function.main]: Failed opening 'extras.php' for
inclusion (include_path='') in /home/sites/site2/web/IV/config.php on
line 98
Fatal error: Call to undefined function: langtop() in
/home/sites/site3/web/powerpage.php on line 3
Problem: The file does exist
--
Edit this bug report at http://bugs.php.net/?id=21674&edit=1
#21677 [Opn->Bgs]: GetImageSize nolonger works
ID: 21677 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: GetImageSize related Operating System: RAQ4-Latest Patches/Apache 1.3.2 PHP Version: 4.3.0 New Comment: 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. Because of this, we hope you add your comments to the existing bug instead. Thank you for your interest in PHP. #21676 Previous Comments: [2003-01-15 23:26:14] [EMAIL PROTECTED] Recently upgraded to PHP 4.3.0 with GD-2.0.1 Scripts worked fine before upgrade. After 4.3.0 upgrade, Sometimes GetImageSize works (returns probper width and height variables) and sometimes it does not (my resize functions are defaulting to 1x2 pixels) At first I thought the problem was isolated to jpgs created with prior version PHP 4.1.2 and GD-2.0.0 and imagecreatefromjpeg function. Then I noticed that there are photos were an image tag (imagecreatefromjpeg) was not used. So the problem is only occuring with certain files.) -- Edit this bug report at http://bugs.php.net/?id=21677&edit=1
#21696 [Opn->Fbk]: Checkbox is strange in POST event
ID: 21696 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Unknown/Other Function Operating System: Windows XP PHP Version: 4.3.0 New Comment: Four things: a) Only checked checkboxes pass values. b) Why do you expect $a to exist at all? I see no code that creates $a. c) Have your test (form2.php) simply be: print_r($HTTP_POST_VARS); d) I believe you mean register_globals is off, there is no such thing as global_variables. e) http://www.php.net/variables.external Previous Comments: [2003-01-16 15:43:31] [EMAIL PROTECTED] ARGH! actually, ignore that comment... I'm talking bs right now :| [2003-01-16 15:39:54] [EMAIL PROTECTED] I'm not sure if it'll make any difference, but try changing this line: echo ''; since ' is not supported as a valid HTML quote (that is, I THINK it isn't :S) [2003-01-16 15:29:28] [EMAIL PROTECTED] (continue) In fact, the error is simplier: when I run in machine 1, it's ok!! But in machine 2, it returns Notice: Undefined variable: a in test.php on line 2 Any clues??? Thanks [2003-01-16 15:26:17] [EMAIL PROTECTED] I'm using PHP 4.3.0 as ISAPI in 2 WinXP machines, running Apache 2.0.43. PHP was installed at same folders and I'm using the same PHP.INI. In machine 1, everything works great. In machine 2, everything works great too BUT when I'm using checkbox inside form posting: echo ""; echo "Are married?"; echo ""; echo ""; the form2.php is: "; $married = $HTTP_POST_VARS["married"]; echo "married = ".$married; echo ""; ?> the response is: Notice: Undefined index: married in form2.php on line 2 In machine 1, forms with checkbox are working great, but in machine 2, it doesn't. Any ideas?? PHP.INI is the same, global_variables are OFF. Thanks in advance Ivan Pisa -- Edit this bug report at http://bugs.php.net/?id=21696&edit=1
#21707 [Opn]: long html text sources truncated
ID: 21707 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Output Control Operating System: windows xp PHP Version: 4.3.0 New Comment: Truncated to how many characters and is it a consistent number? Previous Comments: [2003-01-17 00:43:36] [EMAIL PROTECTED] Apache 2.0.43 running on Windows XP. Reproduced with PHP 4.3.0 running as CGI and as module. present with output_buffering = off not present with output_buffering = on A 10kb(approximately) or larger html/text file with a .php extension is truncated if output buffering is set to off. Turn output buffering on and the entire file is sent/displayed properly -- Edit this bug report at http://bugs.php.net/?id=21707&edit=1
#15637 [Opn]: if using URI, ldap_connect() returns resource ID when server does not exist
ID: 15637
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
-Bug Type: Documentation problem
+Bug Type: LDAP related
Operating System: Linux - RedHat 7.2
-PHP Version: 4.3.0-dev
+PHP Version: 4.4.0-dev
New Comment:
I cannot get ldap_connect() to return false under ANY conditions,
including with the examples provided in this bug report. I find this
behavior impossible to document, please have another look at this.
Reclassifying -> ldap related.
Shouldn't these return false? They are not URI's:
var_dump(ldap_connect('foo'));
var_dump(ldap_connect('does.not.exist'));
I get resources with both. apache1.3.26/php4.4/openldap2.0.23
Previous Comments:
[2003-01-06 11:28:38] [EMAIL PROTECTED]
when using an ip address ldap_connect doesn't work as described.
$server = "10.1.1.100";
$port = "389";
$ds = ldap_connect($server, $port);
the result is true even if the server does not exist or the service is
not running.
[2002-12-27 16:27:34] [EMAIL PROTECTED]
I have observed something like this (in php-4.30rc3):
The whole script:
regards.
[2002-11-29 09:07:12] [EMAIL PROTECTED]
Hello,
in php-4.30rcX, the ldap_connect doesn't perform the connection, so
documentation should be updated.
But, the documention (on zend site) for ldap_connect is:
ldap_connect() establishes a connection to a LDAP server on a
specified
hostname and port. Both the arguments are optional. --> If no
arguments
are specified then the link identifier of the already opened link will
be returned.
In my script i don't have any previous opened link, so i think the
function would return FALSE.
Or the documention is wrong and need correction.
Sincerely
[2002-10-31 15:09:44] [EMAIL PROTECTED]
[EMAIL PROTECTED] suggests that "Checking the return code of ldap_bind()
would be the proper thing to do anyway." However, the act of calling
ldap_bind generates an error message on the page, e.g.:
"Warning: LDAP: Unable to bind to server: Can't contact LDAP server in
/home/shop/www/ldaps-1.php on line 8"
before any check can be made on the results of ldap_bind().
We are trying to create our first secure ldap system, and the
false-positive returns from ldap_connect() are making it difficult to
track down problems.
[2002-07-02 11:19:51] [EMAIL PROTECTED]
Reverified during bughunt. From the user-comments:
"When using an URI to describe the connection, the (open)ldap library
only parses the url and checks if it's valid, _no connection_ is
established in that case."
[EMAIL PROTECTED]
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/15637
--
Edit this bug report at http://bugs.php.net/?id=15637&edit=1
#17214 [Opn]: MING SWFBitmap Wrong Example
ID: 17214 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open -Bug Type: Documentation problem +Bug Type: Ming related Operating System: win2kServer PHP Version: 4.2.1 New Comment: Can someone with Ming knowledge confirm this with a documentable reply? So, swfbitmap does not take on an image name anymore and requires binary data? Previous Comments: [2002-05-27 03:49:22] [EMAIL PROTECTED] Documentation Problem (therefore reclassified). See the first entry in the User Contributed Notes in http://www.php.net/manual/en/function.swfbitmap.php [2002-05-26 14:46:09] [EMAIL PROTECTED] reclassify [2002-05-14 16:15:21] [EMAIL PROTECTED] The Ming extension does not work fine in this new version of PHP, the 4.2.1 It can not recognize the jpg file type. -- Edit this bug report at http://bugs.php.net/?id=17214&edit=1
#13730 [Csd]: StrPos is deficient
ID: 13730 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Feature/Change Request Operating System: Linux/Red Hat 7.1 PHP Version: 4.0.6 New Comment: Also this behavior is documented. Previous Comments: [2003-01-18 12:49:34] [EMAIL PROTECTED] Even though PHP is loosed type language there is === operator for checking the types as well the values. If the developer is lazy to write !== FALSE then he/she can get the flames after that because he/she deserves them. This will break BC and won't be implemented. Regarding the "one based" string position. PHP is like C, not Pascal. [2002-02-19 14:18:24] [EMAIL PROTECTED] Or make the string position one based instead of zero based so that a return of 0 can be used for false and any other return is true. strstr() can usually be used that way, but seems to get confused looking for "/". [2001-10-18 05:42:03] [EMAIL PROTECTED] re StrPOS, I suggest that you do the following. Make another function with a different name, e.g. StrFind, that is 1) less problematic in distinguishing between found at pos zero and not found. e.g. return -1 for not found. 2) case-insensitive, or (better) has an optional parameter ($casesensitive = false) that defaults to false You could also roll in last-occurence functionality a la strrpos with option flags After this, mark the StrPos function as obsolete/deprecated. -- Edit this bug report at http://bugs.php.net/?id=13730&edit=1
#16111 [Opn]: IIS/CGI only gives "Security Alert! PHP CGI cannot be accessed directly."
ID: 16111
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
-Bug Type: Documentation problem
+Bug Type: PWS related
Operating System: Windows
PHP Version: 4.2.1
New Comment:
This still looks like a problem to me, am marking as a PWS problem
until resolved.
Also it's important to know the correct php.ini is being edited as this
seems to be the cause of many peoples problems. So before reporting
information to this bug report, please be sure to state where phpinfo()
says it is.
If a PWS expert knows this is still a documentation problem, please
reclassify with an explanation.
Previous Comments:
[2003-01-16 20:56:50] [EMAIL PROTECTED]
win 98SE, PWS, PHP4.3.0 installbinary. ME TOO! read everything I can
find - no solution
1. PWS installed and working
2. run install shield for PHP4.3.0 normal install
(also did manual install forcing PWS etc.)
3. build simple hello.php put in root of PWS directories
4. 'Execute' is checked for that folder
5. useing browser - link/get/select hello.php
6. get same BUG. error "Security Alert... (seems PHP is trying!)
7. Changed cgi.force_redirect = 0 in PHP.ini (in c:/windows)
8. bug changed. Now the hello.php script just shows up as html text
i.e. the is not executed. (seems PHP is not being accessed
or pulled into the game)
9. because symptoms changed PHP IS reading the php.ini file - it is not
in the wrong directory. so all fixes listed so far will not work.
This is definitly a showstopper for many.
I think that setting cgi.force_redirect = 0 is somehow resulting in the
PWS not knowing where to look for the PHP.exe or something like that
but what do I know. A documentation FIX that works would be nice.
Also there seems to be different fixes for IIS and PWS and the docs are
not clear which fix for which.
[2002-12-07 06:53:50] [EMAIL PROTECTED]
Hello shelley
win2000 + iis + php
I had the same problem with header("Location) redirects.
And I don't have a solution only have one ugly code to do the same...
echo "
document.location.href=$url";
I hope change this code on the future, when somebody will have a
solution.
DJF
[2002-11-10 04:07:00] [EMAIL PROTECTED]
I too had the same problem. I read that I had to set
cgi.force_redirect=0 I did this and nothing happened. I tried
everything, only to find out that my php.ini file was not in c:\winnt
like the docs said they it would be. No the binary distro put it in
c:\documents and settings\administrator\windows I copied that file to
c:\winnt and the php part is working.
[2002-08-26 17:32:53] [EMAIL PROTECTED]
I read bug this bug and have changed my security setting on IIS and it
makes
no difference. I'm also using Zend, Smarty & ADODB. In addition I'm
running on a pentium 4. I am
having major problems in our login program and took the code out into
a
seperate test problem, and am still having the same redirect problems.
I have been checking the Forums in the PHP community for the last week
and
find this seems to be a problem. I've tested the following code and it
only will re-direct 1 time out of 5 or 6 times, of executing the
code(with
no code changes). It gives an error message the other times.
Here is my test program:
http://bugs.php.net/16111
--
Edit this bug report at http://bugs.php.net/?id=16111&edit=1
#21767 [NEW]: segfault in cli/cgi
From: [EMAIL PROTECTED]
Operating system: linux
PHP version: 5CVS-2003-01-20 (dev)
PHP Bug Type: Reproducible crash
Bug description: segfault in cli/cgi
./configure --enable-debug --enable-sockets
Autoconf 2.13
(GNU libtool) 1.4.3
(GNU Bison) 1.75
>From latest checkout of php5, configure and make run fine but simply
calling a php binary ('php -v') results is a segfault. Here's the
backtrace from simply running CLI:
#0 0x08157415 in zend_objects_store_put (object=0x401a803c,
dtor=0x8155e50 , clone=0) at
/cvs/php5/Zend/zend_objects_API.c:47
#1 0x08155efc in zend_objects_new (object=0xbfffe8a0,
class_type=0x81ac780) at /cvs/php5/Zend/zend_objects.c:58
#2 0x08149b2b in _object_and_properties_init (arg=0x81c2108,
class_type=0x81ac780, properties=0x81c2138, __zend_filename=0x816cc20
"/cvs/php5/ext/standard/browscap.c", __zend_lineno=133) at
/cvs/php5/Zend/zend_API.c:594
#3 0x0808e578 in php_browscap_parser_cb (arg1=0xbfffe980, arg2=0x0,
callback_type=2, arg=0x81a6960) at /cvs/php5/ext/standard/browscap.c:133
#4 0x081321fa in ini_parse () at /cvs/php5/Zend/zend_ini_parser.y:213
#5 0x08131c6e in zend_parse_ini_file (fh=0xb7e0, unbuffered_errors=1
'\001', ini_parser_cb=0x808e3c8 , arg=0x81a6960)
at /cvs/php5/Zend/zend_ini_parser.y:164
#6 0x0808e6d2 in zm_startup_browscap (type=1, module_number=3) at
/cvs/php5/ext/standard/browscap.c:169
#7 0x080877da in zm_startup_basic (type=1, module_number=3) at
/cvs/php5/ext/standard/basic_functions.c:1044
#8 0x0814b113 in zend_startup_module (module=0x819dd20) at
/cvs/php5/Zend/zend_API.c:1057
#9 0x08112296 in php_startup_extensions (ptr=0x81a63a4, count=8) at
/cvs/php5/main/main.c:1106
#10 0x08165b15 in php_startup_internal_extensions () at
main/internal_functions_cli.c:65
#11 0x0811270a in php_module_startup (sf=0x81a6320,
additional_modules=0x0, num_additional_modules=0) at
/cvs/php5/main/main.c:1269
#12 0x08164c0e in main (argc=2, argv=0xbaa4) at
/cvs/php5/sapi/cli/php_cli.c:480
--
Edit bug report at http://bugs.php.net/?id=21767&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=21767&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=21767&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=21767&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=21767&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=21767&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=21767&r=support
Expected behavior: http://bugs.php.net/fix.php?id=21767&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=21767&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=21767&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=21767&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21767&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=21767&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=21767&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=21767&r=gnused
#19506 [Opn]: some functions are not visble from "get_extension_funcs"
ID: 19506 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open -Bug Type: Documentation problem +Bug Type: Unknown/Other Function Operating System: Linux 2.4.19 PHP Version: 4.2.3 New Comment: This isn't a documentation problem. Either 'standard' should list said functions or they need to be listed/grouped under an additional 'extension'. As betz said, 'standard' is misleading. Reclassified -> Other Function. Previous Comments: [2002-09-20 10:55:24] [EMAIL PROTECTED] get_defined_funcs works well, but get_extension_funcs does not returm any of the zend_builtin_functions. This may not be only a documentation problem, maybe it should be fixed in the source, because get_extensions_funcs could not be "trusted". The module name standard is misleading, as long as zend_builtin_functions are standard functions (zend_builtin_functions.c), but not treated as those by get_extension_funcs. [2002-09-20 07:02:30] [EMAIL PROTECTED] This is just documentation issue. (I didn't remember get_defined_functions() at all) [2002-09-20 02:56:02] [EMAIL PROTECTED] There is nothing wrong with get_defined_functions(), except that functions like: - extension_loaded - get_extension_funcs - get_loaded_extensions are not returned by the script I submit. Problem in the function or the definition of the function... For you to decide. Gilles [2002-09-20 02:53:29] [EMAIL PROTECTED] What's wrong with get_defined_functions()? [2002-09-19 21:25:23] [EMAIL PROTECTED] Those functions are not defined in any extension but in the Zend engine..maybe there should be another function to get all defined functions? :) 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/19506 -- Edit this bug report at http://bugs.php.net/?id=19506&edit=1
#6893 [Asn]: feature request - makelinks() function
ID: 6893 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Assigned Bug Type: Feature/Change Request Operating System: N/A PHP Version: 4.0.2 Assigned To: tal New Comment: How about posting a link to this source online? Previous Comments: [2003-01-21 14:23:19] [EMAIL PROTECTED] I developed such a function in php with extensive exceptions checking, some months ago. If it would help you, you might like to eyeball it. It may give you valuable and time-saving clues to coding it as a C++ function. Please send me an email address to deliver you part of my script library as an attachment. [2002-04-28 13:35:01] [EMAIL PROTECTED] dealing with trailing periods and commas on urls is pretty easy -- just ignore them if they're followed by a whitespace character. (it's not 100% reliable, of course, but in my experience is more often correct than including the trailing period or comma in that case.) [2002-04-28 06:57:19] [EMAIL PROTECTED] In playing with this kind of thing in the past I've come up against the following problem: How do you handle URLs embedded in sentences which have contact with a full stop or commas? "Have a look at www.examples.com/hi.html, it might help you out" Baring in mind that some sites DO include a comma in the URL, for example any site powered by the Vignette content managment system - example: http://www.vignette.com/CDA/Site/0,2097,1-1-1489,00.html The same goes for sentences where the URL is followed directly by a full stop. The other thing that might be worth taking in to consideration is that many site designs will "break" if suitably long URLs are added (this is especially true for forums, which will be a major use for this function). The best solution I have seen is vBulletin's, where long URLs are shortened to look like this: http://example.com/lon...blah.html Where the full URL (to which the above text is linked) looks like this: http://example.com/long-url-here/blah/blah/blah.html Obviously different sites would need different lengths of URL, so whether or not URLs were shortened like this (and to what extent they were shortened) should probably be specified by an optional second paramater of some sort. Hope that helps, Simon [2002-04-28 02:24:17] [EMAIL PROTECTED] I'm planning to write a String_Manipulation (or something similiar, we'll probably fight about that... ;-)). Assigned to myself. -Tal [2002-01-06 10:02:06] [EMAIL PROTECTED] sounds if PEAR has another task ;). reclassified. 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/6893 -- Edit this bug report at http://bugs.php.net/?id=6893&edit=1
#21813 [Opn]: OCIFetchInto() requires array result passed by reference
ID: 21813 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open -Bug Type: Documentation problem +Bug Type: OCI8 related Operating System: Windows 2000 SP3 PHP Version: 4.2.3 New Comment: Considering this function relies on a deprecated feature, this a bug in OCIFetchInto() itself. Reclassified->Oci8 related. >From the docs for allow_call_time_pass_reference: "This method is deprecated and is likely to be unsupported in future versions of PHP/Zend." Also does @ suppress these type of warnings? Previous Comments: [2003-01-21 20:34:54] [EMAIL PROTECTED] Currently, as of 1/21/03, the documentation states that the result array used with OCIFetchInto() must be passed by reference. Since this has changed after 4.2.0(?) and is not required (generating warnings), the documentation should be updated to explain which particular version(s) will see this phenomenon, especially for those who are upgrading or testing against multiple versions. I understand that a note has been included by a user about this problem, but the note is not clear on the versions affected or when the change was made. I am using PHP Version 4.2.3 on System Windows NT 5.0 build 2195 in CGI mode only loading the php_oci8.dll module. -- Edit this bug report at http://bugs.php.net/?id=21813&edit=1
#21814 [NEW]: false array keys
From: [EMAIL PROTECTED] Operating system: linux PHP version: 4CVS-2003-01-22 (stable) PHP Bug Type: Scripting Engine problem Bug description: false array keys One can create a key as integer 0 and access it with key boolean false but one cannot create an array with boolean false as the key. In otherwords: $arr = array(false => 'bar'); // array() $arr = array((int)false => 'bar'); // array(0=>'bar') $arr = array(0 => 'bar'); print $arr[false];// bar print $arr[(int)false]; // bar This seems inconsistent. From the documentation: Using TRUE as a key will evalute to integer 1 as key. Using FALSE as a key will evalute to integer 0 as key. Please explain the reasoning behind the current behavior. -- Edit bug report at http://bugs.php.net/?id=21814&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21814&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21814&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21814&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21814&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21814&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21814&r=support Expected behavior: http://bugs.php.net/fix.php?id=21814&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21814&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21814&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21814&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21814&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21814&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21814&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21814&r=gnused
#21820 [Opn]: bc break in parser
ID: 21820
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type:Scripting Engine problem
PHP Version: 4.3.0
New Comment:
Allowing it would be nice but this topic has come up many times. Not
sure why it's not been implemented though, maybe there are reasons? I
forget them.
One feature request for this:
http://bugs.php.net/bug.php?id=15677
Previous Comments:
[2003-01-22 13:25:11] [EMAIL PROTECTED]
patch up at http://www2.omniti.com/~george/
zend.patch.2002012101
patch allows for "$arr['foo']" to be parsed correctly (this
seems better than disallowing it)
[2003-01-22 09:19:20] [EMAIL PROTECTED]
I don't think this is a bug, but someone sent it to me via
email, so I'm proxy-submitting:
Hello George-
I stumbled upon a serious bug in the string parser and it
goes something like this:
$arr = array('foo' => 'bar');
print "$arr['foo']";
This used to provide a parse error but now instead we get
this one of level E_NOTICE:
Notice: Undefined index: 'foo' in /tmp/a.php on line 4
/tmp/a.php(4) : Notice - Undefined index: 'foo'
This is a serious problem as it moved an error from
parse to E_NOTICE, fails silently as most have error
reporting turned down, shows a misleading error as foo
is defined, and breaks BC.
Tested latest 4_3 HEAD (4.3.1-dev). I would try php5
but I get segfault when trying to compile/use it :)
Have a nice day,
Philip Olson
cc: derick
--
Edit this bug report at http://bugs.php.net/?id=21820&edit=1
#21820 [Opn]: bc break in parser
ID: 21820
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type:Scripting Engine problem
PHP Version: 4.3.0
New Comment:
Point was, maybe there is a reason this was not implemented.
And btw, this is a bug as 'foo' is defined yet the error says it's
not.
Previous Comments:
[2003-01-22 13:45:54] [EMAIL PROTECTED]
this patch fixes that feature request/bug as well
[2003-01-22 13:43:05] [EMAIL PROTECTED]
Allowing it would be nice but this topic has come up many times. Not
sure why it's not been implemented though, maybe there are reasons? I
forget them.
One feature request for this:
http://bugs.php.net/bug.php?id=15677
[2003-01-22 13:25:11] [EMAIL PROTECTED]
patch up at http://www2.omniti.com/~george/
zend.patch.2002012101
patch allows for "$arr['foo']" to be parsed correctly (this
seems better than disallowing it)
[2003-01-22 09:19:20] [EMAIL PROTECTED]
I don't think this is a bug, but someone sent it to me via
email, so I'm proxy-submitting:
Hello George-
I stumbled upon a serious bug in the string parser and it
goes something like this:
$arr = array('foo' => 'bar');
print "$arr['foo']";
This used to provide a parse error but now instead we get
this one of level E_NOTICE:
Notice: Undefined index: 'foo' in /tmp/a.php on line 4
/tmp/a.php(4) : Notice - Undefined index: 'foo'
This is a serious problem as it moved an error from
parse to E_NOTICE, fails silently as most have error
reporting turned down, shows a misleading error as foo
is defined, and breaks BC.
Tested latest 4_3 HEAD (4.3.1-dev). I would try php5
but I get segfault when trying to compile/use it :)
Have a nice day,
Philip Olson
cc: derick
--
Edit this bug report at http://bugs.php.net/?id=21820&edit=1
#21674 [Opn->Fbk]: Warning: main(lang.php) [function.main]: failed to create stream: No such file
ID: 21674
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Feedback
Bug Type: *URL Functions
Operating System: Cobalt RAQ4 Apache/Linux
PHP Version: 4.3.0
New Comment:
The point of asking for var_dump(ini_get('include_path')); is so you'll
show the output of it. This is a form of debugging.
The problem has to do with the include_path directive. Now we're
trying to figure out why/where it gets set to '' before doing some of
these includes as this seems to be the case.
So, whenever you get this error:
Warning: main() [function.main]: Failed opening 'foo.php'...
Add this line above the include:
var_dump(array(ini_get('include_path'),__LINE__,__FILE));
This way we'll know some useful information. Basically put this line
above EVERY one of these failed includes, such as the inclusion
config.php, extra.php, and lang.php.
Please do this and show the output in your next reply. Btw, I modified
Wez's debug dump a little so we can be a little more specific :) Also,
be 100% sure you are not setting this directive in either httpd.conf or
.htaccess.
Previous Comments:
[2003-01-22 10:38:48] [EMAIL PROTECTED]
Hello Wez:
Not it does not look like that. I was asked to include
var_dump(ini_get('include_path'));
before the require_once statement in the primary script,
phpbug21674.php
Remember there are two scripts located in different paths representing
two different virtual domains.
/home/site3/phpbug21674.php (contains a require_once
("/home/sites/site2/web/IV/config.php");
and /home/sites/site2/web/IV/config.php" ---> contains
include_once ('lang.php');
include ('extras.php');
However, I did go back and also added the var_dump to config.php to
reflect as follows:
var_dump(ini_get('include_path'));
include_once ('lang.php');
include ('extras.php');
Results: Same results = Failed to create stream:
Again, this script worked fine on PHP 4.1.2 Now it seems to get it to
work, I have to reference the absolute path.
[2003-01-22 05:00:55] [EMAIL PROTECTED]
Just to be extra sure:
in config.php, do lines 97 and 98 look like this:
var_dump(ini_get('include_path'));
include ('extras.php');
If not, please make sure they do and report back.
If they do, then something really strange is going on.
[2003-01-21 22:52:29] [EMAIL PROTECTED]
Hello PHP.NET:
So is this bug a stream related 4.3.0 bug or not?
[2003-01-18 02:31:51] [EMAIL PROTECTED]
Did you try ? :
chown o+r / /home /home/sites \
/home/sites/site2 \
/home/sites/site2/web \
/home/sites/site2/web/IV
Up to 4.2.3 "x" permission is need on ALL directories to the include.
Since 4.3.0 "rx" permissions are required.
Don't know why.
Cordialy.
[2003-01-17 15:59:32] [EMAIL PROTECTED]
You did not ask me to place above line that include fails. You asked me
to place above require_once in the config.php file. That I can confirm.
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/21674
--
Edit this bug report at http://bugs.php.net/?id=21674&edit=1
#21850 [Opn->Bgs]: PHP_AUTH_* unavaliable
ID: 21850 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus -Bug Type: Unknown/Other Function +Bug Type: HTTP related Operating System: Linux PHP Version: 4.3.0 New Comment: It was decided to disable PHP_AUTH_* variables when safe_mode was enabled. You can use REMOTE_USER for the username regardless. Am marking this bug as bogus. http://www.php.net/features.http-auth p.s. I just tried phpmyadmin in safe mode with http auth and it works fine. Previous Comments: [2003-01-23 17:46:09] [EMAIL PROTECTED] Philib disable PHP_AUTH_* on PHP 4.3.x to PHP 5, this is a problem in many cases, howto phpmyadmin use apache auth basic... :) Have another solution? -- Edit this bug report at http://bugs.php.net/?id=21850&edit=1
#21857 [WFx]: Perl-like delimeter needed
ID: 21857 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Wont fix Bug Type: Feature/Change Request Operating System: Linux 2.4x PHP Version: 4.3.0 New Comment: Or 'single "quotes"' or <
#15637 [Fbk->Opn]: if using URI, ldap_connect() returns resource ID when server does not exist
ID: 15637
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: LDAP related
Operating System: Linux - RedHat 7.2
PHP Version: 4.4.0-dev
New Comment:
Yes, I still get ldap resources everytime except when passing in "/" or
a wrong parameter count.
Previous Comments:
[2003-01-20 16:12:25] [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
With latest CVS it returns FALSE when appropriate, cannot replicate the
problem.
[2003-01-17 22:26:57] [EMAIL PROTECTED]
I cannot get ldap_connect() to return false under ANY conditions,
including with the examples provided in this bug report. I find this
behavior impossible to document, please have another look at this.
Reclassifying -> ldap related.
Shouldn't these return false? They are not URI's:
var_dump(ldap_connect('foo'));
var_dump(ldap_connect('does.not.exist'));
I get resources with both. apache1.3.26/php4.4/openldap2.0.23
[2003-01-06 11:28:38] [EMAIL PROTECTED]
when using an ip address ldap_connect doesn't work as described.
$server = "10.1.1.100";
$port = "389";
$ds = ldap_connect($server, $port);
the result is true even if the server does not exist or the service is
not running.
[2002-12-27 16:27:34] [EMAIL PROTECTED]
I have observed something like this (in php-4.30rc3):
The whole script:
regards.
[2002-11-29 09:07:12] [EMAIL PROTECTED]
Hello,
in php-4.30rcX, the ldap_connect doesn't perform the connection, so
documentation should be updated.
But, the documention (on zend site) for ldap_connect is:
ldap_connect() establishes a connection to a LDAP server on a
specified
hostname and port. Both the arguments are optional. --> If no
arguments
are specified then the link identifier of the already opened link will
be returned.
In my script i don't have any previous opened link, so i think the
function would return FALSE.
Or the documention is wrong and need correction.
Sincerely
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/15637
--
Edit this bug report at http://bugs.php.net/?id=15637&edit=1
#21506 [Csd->Opn]: Latest CVS missing php4apache2.dll?
ID: 21506 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Closed +Status: Open Bug Type: Compile Failure Operating System: Windows XP PHP Version: 4CVS-2003-01-07 (dev) New Comment: This should remain open until the problem is solved. Reopening. Previous Comments: [2003-01-27 16:51:02] [EMAIL PROTECTED] They say that they are aware, but nothing has been done since it first happened (the time i mentioned). I really would like to test 5.0.x, but cant! :-( [2003-01-27 16:45:13] [EMAIL PROTECTED] Have you any news concerning this problem? The Apache 2 module is still missing in the latest CVS snapshots... [2003-01-08 03:34:08] [EMAIL PROTECTED] Its actually a compile problem with the latest CVS. You can have a look at http://snaps.php.net/win32/compile.log to see the reason. This will be fixed soon. Closing the report since we're aware of the issue and are working on it. [2003-01-07 23:19:33] [EMAIL PROTECTED] I *HIGHLY* doubt this is a doc problem as most likely that dll just forgot to make its way into the distro. Nobody is perfect :) [2003-01-07 22:48:28] [EMAIL PROTECTED] sorry about the above! my dog was 'nosing' my mouse! :\ 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/21506 -- Edit this bug report at http://bugs.php.net/?id=21506&edit=1
#21902 [Asn]: PHPxxxxxx in /tmp
ID: 21902 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Assigned Bug Type: *Directory/Filesystem functions Operating System: Redhat7.3 PHP Version: 4.3.0 Assigned To: wez New Comment: This bug is assigned to Wez, please stop responding to this bug report as the bug is known and will be fixed one day. Previous Comments: [2003-01-28 07:29:02] [EMAIL PROTECTED] And do you find the problem ??? Nico [2003-01-28 02:38:21] [EMAIL PROTECTED] Yes, i suppose it's the same.. It's sure a php bug... Nico [2003-01-27 18:36:13] [EMAIL PROTECTED] This is most likely related to this bug: http://bugs.php.net/bug.php?id=21713 [2003-01-27 12:50:30] [EMAIL PROTECTED] I send you the url by mail Nico [2003-01-27 12:43:05] [EMAIL PROTECTED] in the php4 source directory. It is created when you run configure. 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/21902 -- Edit this bug report at http://bugs.php.net/?id=21902&edit=1
#21922 [Bgs]: suggestion for a new function
ID: 21922
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: Feature/Change Request
Operating System: all
PHP Version: 4.2.3
New Comment:
Yet another example on how lame/overused/misleading the quickfix option
_can_ be.
no@email, the text was autogenerated via a 'quickfix' option except the
last paragraph. I don't know why the quickfix was used here as it
inserted irrelevant and bogus text.
Previous Comments:
[2003-01-28 13:20:29] [EMAIL PROTECTED]
hi, it's already sorted,
my \t abs were at the start of the doc so trim() did the trick for me
thanks,
thanks for the 'bogus' classification [EMAIL PROTECTED]:
I'm not asking for help,
I'm trying to help,
I'm saying maybe there's a need for that function,
(same as with strip_tags etc)
you can do anything with regexp but that's not the issue,
it's weather there's an enough warrant/need/use for a new function
politta I don't care if you guys take it to heart or not,
but you shouldn't be someone with rights to classify suggestions if you
can't read posts properly,
ok bye
[2003-01-28 13:03:41] [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.
No new function is needed for this as it can already been done with a
single preg_replace call as shown by [EMAIL PROTECTED] above.
[2003-01-28 12:59:22] [EMAIL PROTECTED]
Have a look at the preg_replace function, which can do all kinds of
this, e.g. try:
echo preg_replace("/[[:alpha:]]/","","123hi456ho");
echo preg_replace("/[^[:alpha:]]/","","123hi456ho");
[2003-01-28 09:14:01] [EMAIL PROTECTED]
Hi,
I was just in the #php irc channel and I asked 'how to strip all
non-text characters from a string'
and two minutes later another guy comes in and asks the same q',
there is 'trim()' but it only does starts and ends,
there is a function in unix that is called 'strings' that does approx
this,
can you look into it do you think,
and if you do, maybe make it so it can be used the other way around too
(strip all text),
maybe call it 'strip_notext' or so
thanks,
Re
--
Edit this bug report at http://bugs.php.net/?id=21922&edit=1
#19874 [WFx->Opn]: Compile error related to readlin
ID: 19874 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Wont fix +Status: Open Bug Type: Feature/Change Request Operating System: FreeBSD 4.6.2-RELEASE -PHP Version: 4.2.2 +PHP Version: 4.3.0 New Comment: worthy argument, may as well leave this feature request open :) btw, submit a patch and someone will most likely evaluate/comment on it. new features do not go into minor point releases so if this was implemented it'd go in PHP 5.0.0 Previous Comments: [2003-01-28 15:27:17] [EMAIL PROTECTED] Yeah, this is the obvious way around it, but it's pretty crude. I use strpos() for speed, especially on large string, and if you need to first copy the entire string and convert it lowercase, I might as well use stristr(). Implementing stripos() would be so trivial, I can't see a reason not to do it. I'd do it myself, however, to keep the quality of PHP high, it'd be better for someone with Zend/PHP C experience to write it. Could stripos() be available in the next minor point release even? Many thanks, Hans [2003-01-28 15:10:51] [EMAIL PROTECTED] Consider using: $position = strpos(strtolower($haystack),strtolower($needle)); [2002-10-11 20:29:09] [EMAIL PROTECTED] Maybe I'm missing something, but a case-insensitive strpos() would be handy. Yeah, there's obvious ways around it, but a native function would be great. Regards, Hans -- Edit this bug report at http://bugs.php.net/?id=19874&edit=1
#19874 [Opn]: Case-insensitive strpos()
ID: 19874 Updated by: [EMAIL PROTECTED] -Summary: Compile error related to readlin Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Feature/Change Request Operating System: FreeBSD 4.6.2-RELEASE PHP Version: 4.3.0 New Comment: hrm, the summary got changed, not sure how. Previous Comments: [2003-01-28 15:53:04] [EMAIL PROTECTED] worthy argument, may as well leave this feature request open :) btw, submit a patch and someone will most likely evaluate/comment on it. new features do not go into minor point releases so if this was implemented it'd go in PHP 5.0.0 [2003-01-28 15:27:17] [EMAIL PROTECTED] Yeah, this is the obvious way around it, but it's pretty crude. I use strpos() for speed, especially on large string, and if you need to first copy the entire string and convert it lowercase, I might as well use stristr(). Implementing stripos() would be so trivial, I can't see a reason not to do it. I'd do it myself, however, to keep the quality of PHP high, it'd be better for someone with Zend/PHP C experience to write it. Could stripos() be available in the next minor point release even? Many thanks, Hans [2003-01-28 15:10:51] [EMAIL PROTECTED] Consider using: $position = strpos(strtolower($haystack),strtolower($needle)); [2002-10-11 20:29:09] [EMAIL PROTECTED] Maybe I'm missing something, but a case-insensitive strpos() would be handy. Yeah, there's obvious ways around it, but a native function would be great. Regards, Hans -- Edit this bug report at http://bugs.php.net/?id=19874&edit=1
#21991 [Fbk]: CLI only gets compiled with --with-apxs
ID: 21991
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: *Configuration Issues
Operating System: Debian GNU/Linux Sid/Unstable
PHP Version: 4.3.0
New Comment:
Please read these docs:
http://www.php.net/features.commandline
And clarify if you meant cli isn't being built at all (as
sapi/cli/php) or if you mean 'make install' isn't putting cli in
{prefix}/bin/php because after reading those docs you will realize that
you need 'make install-cli' under certain conditions to put it there.
Those docs will explain this confusing issue.
Previous Comments:
[2003-01-31 17:27:48] [EMAIL PROTECTED]
If you want cli only you should probably just add --disable-cgi as it
is cgi that is installed by default when both cgi and cli are
selected.
[2003-01-31 17:19:24] [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.
Seems you must have done something more. I tried it myself
and it is working. However i did it with current CVS version. Could you
please try that yourself?
If the CVS version behaves the same way i suggest you post your
configure line here and it may be necessary to inquire the generated
makefile.
However there is another solution for that effect: Did you use
--disable-all or --disable-cli for any reason? You can verify that by
locking into config.nice.
[2003-01-31 16:47:39] [EMAIL PROTECTED]
There seems to be a configure bug with php 4.3.0.
When you compile, you dont get the CLI unless you include --with-apxs
in the ./configure line.
I confirmed this by having my mates try out different configure lines,
they too only got it when configuring with the --with-apxs option
enabled.
If this is a global bug I do not know, but it would seem so - One of
them is running Mandrake 9.0, the other Red Hat 8.0, and myself Debian
Sid/Unstable.
--
Edit this bug report at http://bugs.php.net/?id=21991&edit=1
#22001 [WFx]: /php.ini is read instead of configured /usr/local/etc/php.ini !!!
ID: 22001 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Wont fix Bug Type: *Configuration Issues Operating System: Solaris 8 PHP Version: 4.3.0 New Comment: Added a link to this bug report in the related existing bug of #21783 so this information will be added to the manual sometime. http://bugs.php.net/bug.php?id=21783 Previous Comments: [2003-02-02 05:50:38] [EMAIL PROTECTED] yes... i understand how this is done... now. but: i did not find anything 'bout this behaviour in the manual... maybe i overread it, but it should be placed to be seen at 1st (bold, underline ;-)) maybe in: http://www.php.net/manual/en/configuration.php#configuration.file thx, md. [2003-02-01 19:42:39] [EMAIL PROTECTED] This is a known issue. PHP searches for php.ini in current working directory first (exception to this is CLI SAPI) and apache does cd / at startup so /php.ini gets read. There are nó current plans to change this. [2003-02-01 17:09:10] [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 Could you also stop and start apache instead of restart? I can't reproduce this with current HEAD. [2003-02-01 15:50:50] [EMAIL PROTECTED] hi, i saved a version of php.ini as "/php.ini", which should only be a copy before i changed my real one... then i tried to change my real php.ini (/usr/local/etc/php.ini) but the changes did NOT take effect (yes, i restarted my apache!) reading phpinfo() output, it told me that it read /php.ini instead of /usr/local/etc/php.ini, which is given in the compile options as default as you can see below: i compiled php-4.3.0 with the following options: ./configure \ --prefix=/usr/local \ --with-apxs=/data/apache/bin/apxs \ --enable-cli \ --disable-cgi \ --disable-debug \ --with-config-file-path=/usr/local/etc\ --with-exec-dir \ --enable-sigchild \ --disable-magic-quotes\ --disable-rpath \ --disable-ipv6\ --with-openssl\ --disable-all \ --with-zlib=/usr/local\ --disable-ctype \ --with-curl=/usr/local\ --with-gd \ --with-jpeg-dir=/usr/local\ --with-png-dir=/usr/local \ --with-zlib-dir=/usr/local\ --with-freetype-dir=/usr/local\ --with-t1lib=/usr/local \ --enable-gd-native-ttf\ --with-gettext=/usr/local \ --with-imap=/usr/local\ --with-imap-ssl=/usr/local\ --with-ldap=/usr/local\ --with-mcrypt=/usr/local \ --with-mysql=/usr/local \ --with-oci8=/data/oracle \ --with-pcre-regex \ --disable-posix \ --enable-session \ --enable-sockets \ --enable-sysvmsg \ --enable-sysvsem \ --enable-sysvshm \ --enable-xml \ --with-expat-dir=/usr/local \ --enable-shared \ --enable-static \ --disable-inline-optimization \ snip
#21885 [Opn]: move_uploaded_file error with open_basedir
ID: 21885 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open -Bug Type: Documentation problem +Bug Type: PHP options/info functions Operating System: Windows XP - IIS PHP Version: 4.3.0 New Comment: No clue what to document here and it still looks like a bug. If it's not a bug, it would be nice if a php-dev member explained this new behavior vs the old behavior as otherwise this will remain an open doc bug all through eternity. Previous Comments: [2003-01-28 06:42:05] [EMAIL PROTECTED] And, by the way, to [EMAIL PROTECTED]: your change to open_basedir can't have "taken", as the error message is still indicating it's just "." -- you did restart your Web server, didn't you? Cheers! [2003-01-28 06:39:29] [EMAIL PROTECTED] Sorry, Sniper, but I fail to see what #16128 has to do with this. That report complained that open_basedir was not being applied to the *destination* of a move_uploaded_file(); this one complains that it *is* being applied to the *source* of a move_uploaded_file() -- that is, the temporary copy of the uploaded file. There is no obvious (to me) good reason why the open_basedir restriction should be applied to the uploaded temp-file -- if there is, it should be documented so we know what it is. Cheers! [2003-01-28 03:03:53] [EMAIL PROTECTED] thank you... but adding a path to open basedir doesn't do the job it continue to say File(c:\temp\php-uploads\phpD.tmp) is not within the allowed path(s): (.) [2003-01-28 02:21:49] [EMAIL PROTECTED] Is upload_tmp_dir affected by these? In otherwords, does the upload_tmp_dir need to be listed in open_basedir? Where does safe_mode come into play? Please provide some documentable information as neither of these bug reports do. #16128 says it's fixed but what does that mean? [2003-01-27 23:27:16] [EMAIL PROTECTED] This was changed because of this bug: http://bugs.php.net/bug.php?id=16128&edit=1 And it will stay. Reclassified as documentation prob. 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/21885 -- Edit this bug report at http://bugs.php.net/?id=21885&edit=1
#22005 [Bgs->Opn]: mysql_stat() - Incorrect Format
ID: 22005
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Bogus
+Status: Open
Bug Type: MySQL related
Operating System: Windows 2000 Server
PHP Version: 4.3.0
New Comment:
a) split/preg_split uses regex, not explode
b) it would not work well as it'd split up everything
c) this is not related to html but rather a php string
d) the example in the manual uses explode on two spaces
If this is indeed true (one space before Queries) than this is a bug
... somewhere.
Previous Comments:
[2003-02-02 03:23:43] [EMAIL PROTECTED]
In fact there are more space but the HTML output will read only one.
Use explode('[[:space:]]',$var) to divide it.
(You can verify that by looking at the HTML source.
[2003-02-01 21:26:48] [EMAIL PROTECTED]
When I call mysql_stat(), it returns a string like this:
Uptime: 1182208 Threads: 13 Questions: 745284 Slow queries: 1
Opens: 2210 Flush tables: 1 Open tables: 12 Queries per second avg:
0.630
All the fields are supposed to have two spaces (" ") between each of
them so that an explode() will work on it.
However, you will notice that there is only 1 space (" ") between the
value of "Open Tables" and the caption "Queries per second avg:"
Is this how it is supposed to be? Or is this a minor bug?
--
Edit this bug report at http://bugs.php.net/?id=22005&edit=1
#22013 [Opn]: setcookie does not work on Mozilla
ID: 22013
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: HTTP related
Operating System: Windows
PHP Version: 4.3.0
New Comment:
Please confirm that HTTP_HOST exists (i.e. what $domain is)
Previous Comments:
[2003-02-02 13:16:18] [EMAIL PROTECTED]
By the way, my original test script was kind of stupid. Here is the
corrected test script.
[2003-02-02 13:15:13] [EMAIL PROTECTED]
I added:
error_reporting(E_ALL);
to the script and saw no errors reported.
This was not surprising since I have this set in php.ini:
error_reporting = E_ALL; display all errors, warnings and notices
display_errors = On
[2003-02-02 12:57:55] [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.
your script contains errors: $this is not an object.
Add:
error_reporting(E_ALL);
in line 1 to see if there's anything else reported.
[2003-02-02 12:35:33] [EMAIL PROTECTED]
Today I upgraded from PHP 4.2.2 to PHP 4.3. I am using Apache 2.0.43
on Windows with PHP CGI.
After doing this upgrade, setcookie() stopped working for me using
Mozilla 1.3a though it continued to work using IE. setcookie() was
working for me with both browsers before the upgrade.
Here is a script that illustrates the bug.
id, $expirationTime, '/', $domain, 0)) {
$success = false;
}
if (!setCookie(USERNAME, $this->username, $expirationTime, '/',
$domain, 0)) {
$success = false;
}
if ($success) {
print "setCookie's succeeded";
} else {
print "setCookie's failed";
}
?>
--
Edit this bug report at http://bugs.php.net/?id=22013&edit=1
#22013 [Opn]: setcookie does not work on Mozilla with localhost as domain
ID: 22013 Updated by: [EMAIL PROTECTED] -Summary: setcookie does not work on Mozilla Reported By: [EMAIL PROTECTED] Status: Open Bug Type: HTTP related Operating System: Windows PHP Version: 4.3.0 New Comment: According to the spec: http://wp.netscape.com/newsref/std/cookie_spec.html The domain must have at least two periods. I'm not sure how this applies to localhost but I guess for localhost just don't set it or set as an empty string. Previous Comments: [2003-02-02 13:48:21] [EMAIL PROTECTED] $domain is 'localhost' because I am testing on my local machine. I updated the script to not pass the $domain and $expirationTime to the setCookie function and the script now works. I am not sure why 'localhost' would be a problem since I see when I take out $domain and $expirationTime, Mozilla sets the host for the cookie to 'localhost'. Maybe this is a Mozilla bug. [2003-02-02 13:38:17] [EMAIL PROTECTED] Please confirm that HTTP_HOST exists (i.e. what $domain is) [2003-02-02 13:16:18] [EMAIL PROTECTED] By the way, my original test script was kind of stupid. Here is the corrected test script. [2003-02-02 13:15:13] [EMAIL PROTECTED] I added: error_reporting(E_ALL); to the script and saw no errors reported. This was not surprising since I have this set in php.ini: error_reporting = E_ALL; display all errors, warnings and notices display_errors = On [2003-02-02 12:57:55] [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. your script contains errors: $this is not an object. Add: error_reporting(E_ALL); in line 1 to see if there's anything else reported. 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/22013 -- Edit this bug report at http://bugs.php.net/?id=22013&edit=1
#22039 [Opn->Fbk]: HTTP client problem
ID: 22039 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Unknown/Other Function Operating System: Linux PHP Version: 4.3.0 New Comment: a) What is your register_globals directive b) What is your variables_order directive c) Why do you feel $my_var is newer than $HTTP_POST_VARS['my_var'] d) Give a few examples of when $my_var is untruthful (the desired value versus the actual value) Previous Comments: [2003-02-03 18:32:10] [EMAIL PROTECTED] I made a new site that runs perfectlyunder netscape, opera, konqueror, and 99% of Micro$oft clients, but 1% of Micosoft client does not work. I tried to figure out if it was a problem of DB, I ran tests, but the test all gone to the conclusion that "some" IE browsers refuse to apply the new version of PHP. As far as I can see the old version of HTTP addressing $HTTP_POST_VARS['my_var'] works 100% but the new one $my_var does only give 100% truth on any browser but IE for which 1% says no ! I hope to have any clue on this subject because we shall quickly explain it PHP developpers. Herve PS the test site is www.virtualtransat.com/vt -- Edit this bug report at http://bugs.php.net/?id=22039&edit=1
#21728 [Opn]: sort() sorts are unpredictable
ID: 21728
Updated by: [EMAIL PROTECTED]
-Summary: Additional (kindly weird example) for sort()
Reported By: [EMAIL PROTECTED]
Status: Open
-Bug Type: Documentation problem
+Bug Type: Unknown/Other Function
Operating System: All
PHP Version: 4.4.0-dev
New Comment:
Reclassified as a sort() problem as this is too weird and
unpredictable. Maybe php-dev can confirm this behavior as how it
should and will continue to be. Mike, nice response but I still don't
like this ;)
Previous Comments:
[2003-01-20 12:00:26] [EMAIL PROTECTED]
There was (and is) a suspicion in me about because the sort is made by
qsort algo. As you said all comparisons are valid ones but the order is
unpredicatble.
Thanks for the comment.
I think we should rethink the sort() function and maybe change the
default way of sorting (from SORT_REGULAR to SORT_STRING).
[2003-01-20 11:54:48] [EMAIL PROTECTED]
Well, one of the problems here is that some of the array elements will
take different values in an element-to-element comparison depending on
the type of the other element. For example, "true" will be just that
compared to another string, but 0 when compared against an integer;
strings and integers are both converted to Boolean when compared to
true/false (with resulting loss of significant information).
Another problem is that if you're using a non-sequential sorting
algorithm (such as shellsort or quicksort), simply changing the length
of the array will probably change which element is compared to which,
and hence, because of the strangeness of "dual values" caused by
type-juggling, the final order of the array. (This may be even worse
for an algorithm that is not guaranteed to maintain the order of equal
items.)
If you take a look at the sorted versions of each array cited, you will
find that all of the element-to-neighbour-element comparisons are
actually valid, thus:
array("a","b","c","d","4",5,4,"true","TRUE",true) --
true : 4 ==> (bool)true == true
4 : "4" ==> (int) 4 == 4
"4": "TRUE" ==> (string) "4"< "TRUE"
"TRUE" : "a" ==> (string) "TRUE" < "a"
"a": "b" ==> (string) "a"< "b"
"b": "c" ==> (string) "b"< "c"
"c": "d" ==> (string) "c"< "d"
"d": "true" ==> (string) "d"< "true"
"true" : 5 ==> (int) 0 < 5
array("a","b","4",5,4,"true","TRUE",true, false, "c") --
false : "TRUE" ==> (bool) false < true
"TRUE" : "a" ==> (string) "TRUE" < "a"
"a": "true" ==> (string) "a"< "true"
"true" : true==> (bool) true == true
true : "b" ==> (bool) true == true
"b": "c" ==> (string) "b"< "c"
"c": 4 ==> (int)0 == 4
4 : "4" ==> (int)4 == 4
"4": 5 ==> (int)4 < 5
array("a","b","4",5,4,"true","TRUE",true, false, "c", "d") --
false : "4" ==> (bool)false < true
"4": "TRUE" ==> (string) "4"< "TRUE"
"TRUE" : "a" ==> (string) "TRUE" < "a"
"a": "b" ==> (string) "a"< "b"
"b": "c" ==> (string) "b"< "c"
"c": "d" ==> (string) "c"< "d"
"d": "true" ==> (string) "d"< "true"
"true" : true==> (bool)true == true
true : 4 ==> (bool)true == true
4 : 5 ==> (int) 4 < 5
So, in each case, we have a valid sort -- just a *different* valid
sort. The prime determiners here seem to be the non-sequential order
in which the individual comparisons are performed, and, as has been
indicated, the automatic casting that takes place for each one.
(Incidentally, whilst putting the above together I was unable to find a
definitive listing of *exactly* what automatic type-conversions take
place in which contexts. This is a definite oversight, as in contexts
like the above it's important to know, for example, that comparing an
int to a bool will cast the int to bool, and not the bool to int.
Perhaps this needs to become a doc problem for the inclusion of such a
list or table?)
Hope this enlightens at least some souls reading this far!
Cheers!
Mike
[2003-01-18 12:23:24] [EMAIL PROTECTED]
Maybe it should not happen but the as I said the comparisons done are
correct (extensive type juggling). Maybe SORT_REGULAR is not the way to
sort (by default) but SORT_STRING.
Comments from other people are welcome :)
[2003-01-18 12:17:00] [EMAIL PROTECTED]
I swear I get different results by just adding a "d" to the end. This
should not happen.
---
#22110 [Opn]: ini_get ("memory_limit"); not working
ID: 22110
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: PHP options/info functions
Operating System: freeBSD 4.7
PHP Version: 4.3.0
New Comment:
Here's how I see it. You must have used --enable-memory-limit to use
this directive at all so it essentially isn't being used so it returns
an empty string. I believe this is intentional but ideally a php-dev
person will answer:
Why doesn't it return the default value? Whether that be 8M or -1 (not
sure which it is :) ... when not compiled in. An empty string seems
misleading.
Previous Comments:
[2003-02-07 10:29:28] [EMAIL PROTECTED]
ini_get ("memory_limit"); does not return anything.
--
Edit this bug report at http://bugs.php.net/?id=22110&edit=1
#15208 [Csd->Opn]: .phps file additional feature
ID: 15208 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Closed +Status: Open Bug Type: Feature/Change Request Operating System: Linux PHP Version: 4.1.1 New Comment: This was never implemented/committed. Here's a thread: http://marc.theaimsgroup.com/?l=php-dev&m=103239898231495 And here's a patch: http://www.dapond.net/code/zend_highlight.patch Previous Comments: [2003-02-06 21:09:12] [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. There is no ini settings, however as of PHP 4.3.0 you can passd a string via GET that will enable the display of line numbers. [2002-01-24 12:32:54] [EMAIL PROTECTED] It would be very helpful if you had a php.ini directive like: php_source_view_linenum = 0/1 If it is set to '1', a .phps file would print the line number in front of the colorized syntax. It's not a huge feature, but would be very nice to help debug some code, or help others see the logic of code. -- Edit this bug report at http://bugs.php.net/?id=15208&edit=1
#15208 [Opn]: .phps file additional feature
ID: 15208 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Feature/Change Request -Operating System: Linux +Operating System: all -PHP Version: 4.1.1 +PHP Version: 5.0.0 -Assigned To: +Assigned To: zeev New Comment: To add. That looong thread ends with this comment by Zeev as certain conditions with that patch cause a segfault: "I'll try to find some time to look at it. I need to re-familiarize myself with the output buffering code at some point anyway..." So, I suppose this should be assigned to Zeev. And it is, now. Previous Comments: [2003-02-07 11:59:42] [EMAIL PROTECTED] This was never implemented/committed. Here's a thread: http://marc.theaimsgroup.com/?l=php-dev&m=103239898231495 And here's a patch: http://www.dapond.net/code/zend_highlight.patch [2003-02-06 21:09:12] [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. There is no ini settings, however as of PHP 4.3.0 you can passd a string via GET that will enable the display of line numbers. [2002-01-24 12:32:54] [EMAIL PROTECTED] It would be very helpful if you had a php.ini directive like: php_source_view_linenum = 0/1 If it is set to '1', a .phps file would print the line number in front of the colorized syntax. It's not a huge feature, but would be very nice to help debug some code, or help others see the logic of code. -- Edit this bug report at http://bugs.php.net/?id=15208&edit=1
#22169 [Fbk]: Undefined variable
ID: 22169
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: IIS related
Operating System: Win 2k pro
PHP Version: 4.3.0
New Comment:
There are times when submit buttons don't pass values. I always forget
the exact circumstances so rarely rely on them but anyway, assuming
this is a post form, do:
var_dump(array('p' => $_POST, 'r' => ini_get('register_globals')));
Of course, use $_GET for GET.
Previous Comments:
[2003-02-11 10:37:59] [EMAIL PROTECTED]
YES, register_globals is On!
[2003-02-11 10:20:26] [EMAIL PROTECTED]
run phpinfo() to make sure your register_globals (I assume that is the
option you are referring to) is enabled.
[2003-02-11 10:10:55] [EMAIL PROTECTED]
I read all your posts about the "Undefined variable" and I changed the
php.ini global variable to On, but I still have that message when I
want to referance a $submit variable!!!
Message is :
Notice: Undefined variable: submit in "..." on line 4
I tested it with php3 and php4 --->same thing
--
Edit this bug report at http://bugs.php.net/?id=22169&edit=1
#22193 [Csd]: PHP no longer supports Cybercash?!?
ID: 22193 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: *E-commerce functions Operating System: FreeBSD 4.7 PHP Version: 4.3.0 New Comment: The documentation at php.net/cybercash has been updated to reflect this change. The docs have linked to the above quoted faq for quite some time. The new documentation will show up online within the coming week(s). Previous Comments: [2003-02-13 10:30:22] [EMAIL PROTECTED] Thanks! That solves the problem handily. [2003-02-12 22:55:10] [EMAIL PROTECTED] Moved cybercash into PECL. You SHOULD be able to just do a pear install cybercash, but seeing as I dont have the cybercash libraries that need to be linked against, your mileage may vary. [2003-02-12 22:14:34] [EMAIL PROTECTED] >From http://www.verisign.com/support/cyberCash/integration.html (selected excerpts): -- 1. Will my service be interrupted? * No, we will continue to operate the CyberCash gateway at its high level of reliability and uptime. 3. Do I need to convert over to VeriSign's gateway? * No, we will continue to operate the CyberCash gateway for the foreseeable future. 8. I looked at VeriSign before going with CyberCash and didn't care for their product offering. Should I be looking at other providers now? * We are maintaining the service for existing CyberCash customers, so there is no reason for you to think about looking at other payment gateways. -- I also submit as evidence the fact that the server's I'm dealing with have cleared several thousand transactions via PHP and Cybercash already this month. :) [2003-02-12 21:41:05] [EMAIL PROTECTED] Interesting, can you point any URI saying that their services are still up and maintained? We are open-minded ! :-) [2003-02-12 21:37:42] [EMAIL PROTECTED] Thanks for the information. I still believe that it was deprecated unfairly (it still interfaces with an operating, maintained service), but that's your call. 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/22193 -- Edit this bug report at http://bugs.php.net/?id=22193&edit=1
#21820 [Ver->Ctl]: bc break in parser
ID: 21820
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Verified
+Status: Critical
Bug Type:Scripting Engine problem
PHP Version: 4.3.0
New Comment:
Marking as critical. This is a serious bug as it's subtle and confuses
newbies, especially when they/we try to use autoglobals in strings.
This bug fix really needs to make it into 4.3.1
Previous Comments:
[2003-01-22 20:28:56] [EMAIL PROTECTED]
This bug appeared in 4.3.0 as a result of the lexer changes
added to ZE1 and ZE2 in november to speed up
variableinterpolation in strings.
Previous to 4.3 this was valid:
echo "$a[b]";
but
echo "$a['b']"; generated a parse error.
The bug manifests itself by turning this parse error into a
non-sensical E_NOTICE error.
The patch 'fixes' the bug by making
echo "$a['b']";
work, which has been a pending feature request and seems
nice (to me), or at least harmless.
[2003-01-22 19:53:20] [EMAIL PROTECTED]
Anyone remember in what version of PHP this did work? :)
Correct (?) way to do this is:
'bar');
print "{$arr['foo']}";
?>
Or at least I've started to use that just because of this bug.
[2003-01-22 13:56:01] [EMAIL PROTECTED]
Point was, maybe there is a reason this was not implemented.
And btw, this is a bug as 'foo' is defined yet the error says it's
not.
[2003-01-22 13:45:54] [EMAIL PROTECTED]
this patch fixes that feature request/bug as well
[2003-01-22 13:43:05] [EMAIL PROTECTED]
Allowing it would be nice but this topic has come up many times. Not
sure why it's not been implemented though, maybe there are reasons? I
forget them.
One feature request for this:
http://bugs.php.net/bug.php?id=15677
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/21820
--
Edit this bug report at http://bugs.php.net/?id=21820&edit=1
#20371 [Opn]: Wrong NEWS entry. This change should read 4.2.3 not 4.3.0.
ID: 20371
Updated by: [EMAIL PROTECTED]
-Summary: 4.2.3 Change Log/NEWS file missing mail() 5th Param
Value
Reported By: [EMAIL PROTECTED]
Status: Open
-Bug Type: Documentation problem
+Bug Type: Unknown/Other Function
Operating System: FreeBSD
PHP Version: 4.2.3
New Comment:
Okay, someone put this in the wrong NEWS.
http://www.php.net/php4news
This is not a doc problem, reclassified so this will make it to php-dev
not phpdoc. Someone needs to edit NEWS.
Previous Comments:
[2002-11-12 22:16:56] [EMAIL PROTECTED]
Updated Summary to make it more relevant.
[2002-11-12 22:03:49] [EMAIL PROTECTED]
In the source of 4.2.3 that I downloaded, the code has been changed to
include this check in safe mode.
It is not in the 4.2.3 NEWS file in the source I downloaded, or on the
4.2.3 Change Log: http://www.php.net/ChangeLog-4.php
As I say, it has been comitted to the 4.2.3 source as far as I can see,
the code is right here in mail.c:
if (PG(safe_mode) && (ZEND_NUM_ARGS() == 5)) {
php_error(E_WARNING, "%s(): SAFE MODE Restriction in effect. The
fifth parameter is disabled in SAFE MODE.",
get_active_function_name(TSRMLS_C));
RETURN_FALSE;
}
Am I to understand this has been documented as a 4.3.0 change?
[2002-11-12 19:18:34] [EMAIL PROTECTED]
It's not listed in that changelog because that changelog updates
depending on current stable PHP version. It does not show 4.3.0
entries as the current stable version is 4.2.3
The question is when did this _really_ get committed? It's in the
4.3.0 NEWS yet is currently documented as a 4.2.3 change. I am
assuming this is a documentation bug for now.
[2002-11-11 17:06:35] [EMAIL PROTECTED]
It is however not mentioned on:
http://www.php.net/ChangeLog-4.php
It is not mentioned on this change log that it is
summarised/incomplete. While it may be mentioned elsewhere, this is
more a complaint about the front page change log than anything else.
[2002-11-11 17:01:49] [EMAIL PROTECTED]
It's right there in the NEWS file:
- Disabled the fifth parameter in mail() when safe-mode is turned on.
(Derick)
And for that matter, it is also in the ChangeLog:
2002-07-02 Derick Rethans <[EMAIL PROTECTED]>
* ext/standard/mail.c:
- Be nice to users and allow them to check if the mail was send
* ext/standard/mail.c: - Disable 5th parameter to mail in safemode
- Disabled the fifth parameter to the mail function in safemode.
And yes, we will continue to fix security problems in minor releases.
This was a nasty security hole and needed to be fixed.
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/20371
--
Edit this bug report at http://bugs.php.net/?id=20371&edit=1
#20431 [Bgs]: function generated include blocks access to $HTTP_GET_VARS[]
ID: 20431
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Windows XP Pro
PHP Version: 4.2.3
New Comment:
Your example is including files inside a function so the included files
follow standard variable scope rules. This is why this is marked as a
bogus bug and a support question.
function foo() {
$var = 'blah';
}
foo(); var_dump($var); // NULL
$_GET will still be available as it's an autoglobal while
$HTTP_GET_VARS will not.
Previous Comments:
[2002-11-14 13:47:03] [EMAIL PROTECTED]
I know you bogusified my report, but it doesn't make sense. I'm just
telling PHP to write itself what I would normally write. How can this
block the isset function and the _GET array?
[2002-11-14 13:36:46] [EMAIL PROTECTED]
Then how come the isset function doesn't work with these includes?
[2002-11-14 13:30:16] [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.
[2002-11-14 13:29:22] [EMAIL PROTECTED]
My script uses multiple includes and the file names all have the same
syntax. So instead of writing each individual include, I created an
array which contains all the filenames
function LoadSections($sections)
{
foreach ($sections as $key => $value)
{
include "mod.section." . $value . ".php";
}
}
All the files load well except that I cannot access HTTP_GET_VARS and
the isset() function always return false.
NB My includes work fine when loaded individually
--
Edit this bug report at http://bugs.php.net/?id=20431&edit=1
#19848 [Csd->Opn]: Wrong $_REQUEST values ($_FILES appearance is wacky)
ID: 19848
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Closed
+Status: Open
Bug Type: HTTP related
Operating System: *any
PHP Version: 4.2.3,4,3.0-dev
Assigned To: sterling
New Comment:
Until import_request_variables() behavior is discussed in php-dev this
should remain open. IMHO $_REQUEST and import_request_variables()
should behave the same way as to remain consistent. As of PHP 4.3.0
$_FILES was only removed from $_REQUEST.
Previous Comments:
[2002-11-15 07:44:41] [EMAIL PROTECTED]
not sure if this is important, but import_request_variables imports the
wrong thing.
html:
code:
import_request_variables("GP", "__");
result:
$__d = array (
'name' => array ( 'file' => '' ),
'type' => array ( 'file' => '' ),
'tmp_name' => array ( 'file' => '' ),
'error' => array ( 'file' => 4 ),
'size' => array ( 'file' => 0 )
)
[2002-10-27 20:47:21] [EMAIL PROTECTED]
Fixed in CVS... $_FILES is no longer present in $_REQUEST...
[2002-10-24 18:42:14] [EMAIL PROTECTED]
This test form strips 3 characters from the posted variable:
2 dimensional array - this test form strips 8 characters from the
posted variable:
For every dimension added to the array, another 4 characters are
scripted from the beginning of the posted variable. Works on PHP
version less than 4.2.2 and earlier.
[2002-10-20 22:17:12] [EMAIL PROTECTED]
The 'voting' on php-dev was in favour for removing the $_FILES from
$_REQUEST..as it doesn't make much sense
to have them there. Just FYI. :)
--Jani
[2002-10-20 22:14:01] [EMAIL PROTECTED]
Sterling Hughes is working on this issue, according to posts to
php-dev.
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/19848
--
Edit this bug report at http://bugs.php.net/?id=19848&edit=1
#20461 [Bgs->Fbk]: Unable to access $PHP_AUTH_USER or $PHP_AUTH_PW
ID: 20461 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Feedback Bug Type: Apache related Operating System: Linux 2.4.8 PHP Version: 4CVS-2002-11-17 New Comment: Is the php directive register_globals on or off? The default changed in PHP 4.2.0 from on to off, phpinfo() will tell you your true setting. Previous Comments: [2002-11-17 05:32:32] [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. [2002-11-17 01:11:02] [EMAIL PROTECTED] I recently decided to upgrade to GD 2.0 but was having problems getting it to compile with 4.2.3 or any of the older versions of PHP, which is odd because I've had it work before. Anyways, as a last resort, I decided to download one of the stable CVS snapshots and, lo and behold, it worked fine. The only problem I'm having now is that I can't seem to access $PHP_AUTH_USER or $PHP_AUTH_PW, and I have a few applications on my site that depend on being able to access these variables. The variables appear to be empty when I reference them. I am using the exact same configure line when I compiled the CVS version of PHP as I used when I tried the other versions... ./configure --with-apxs --with-mysql --enable-ftp --with-session --with-zlib-dir=/usr/local --with-gd=/usr/local --with-jpeg-dir=/usr/local --with-png-dir=/u sr/local --with-freetype-dir=/usr/local --with-mcal=/usr/local --with-mhash=/usr/local I have GD 2.0 installed under /usr/local, as indicated by the configure line above. If you need any additional information, please contact me. Thanks in advance for your help. -- Edit this bug report at http://bugs.php.net/?id=20461&edit=1
#16744 [Opn]: automatik installation failed
ID: 16744 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open -Bug Type: Documentation problem +Bug Type: Apache2 related Operating System: Windows 2000 PHP Version: 4.2.0 New Comment: Am marking this as apache2 related as the doc team does not have access to install.txt and it's apache2 related. Please see: http://www.php.net/manual/en/install.apache2.php Previous Comments: [2002-04-23 05:54:39] [EMAIL PROTECTED] Apache 2 support is still experimental, as you could read from www.php.net/release_4_2_0.php and I changed the category to "Documentation Problem". Derick [2002-04-23 05:43:21] [EMAIL PROTECTED] The automatic installatoin for Apache 2.0 failed. The install.txt has no working methods to run php with apache 2.x -- Edit this bug report at http://bugs.php.net/?id=16744&edit=1
#16744 [Opn->Csd]: win32/index.txt lacks apache 2 related documentation
ID: 16744 Updated by: [EMAIL PROTECTED] -Summary: automatik installation failed Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Apache2 related -Operating System: Windows 2000 +Operating System: Windows -PHP Version: 4.2.0 +PHP Version: 4.3.0-dev New Comment: index.txt is now updated, the related diff can be seen here: http://cvs.php.net/diff.php/php4/win32/install.txt?r1=1.16&r2=1.17 This will make it into PHP 4.3.0, thanks for the report! Previous Comments: [2002-11-18 18:05:59] [EMAIL PROTECTED] Am marking this as apache2 related as the doc team does not have access to install.txt and it's apache2 related. Please see: http://www.php.net/manual/en/install.apache2.php [2002-04-23 05:54:39] [EMAIL PROTECTED] Apache 2 support is still experimental, as you could read from www.php.net/release_4_2_0.php and I changed the category to "Documentation Problem". Derick [2002-04-23 05:43:21] [EMAIL PROTECTED] The automatic installatoin for Apache 2.0 failed. The install.txt has no working methods to run php with apache 2.x -- Edit this bug report at http://bugs.php.net/?id=16744&edit=1
#20509 [Opn->Bgs]: $_SERVER['HTTP_RAW_POST_DATA'] not equivalent to $HTTP_RAW_POST_DATA
ID: 20509 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Variables related Operating System: FreeBSD 4.6.2 PHP Version: 4.2.2 New Comment: This variable does not live in $_SERVER or any superglobal for that matter. It's its own variable. The documentation is being worked out as there is still a question on when this variable should exist. Previous Comments: [2002-11-19 18:06:46] [EMAIL PROTECTED] Environment: Apache 1.3.26 on FreeBSD 4.6.2 with mod_php 4.2.2 register_globals is off and always_populate_raw_post_data is defaulted to off (phpinfo() says "0"). I'm trying to use nuSOAP (http://sourceforge.net/projects/nusoap/). The final line of a server is typically something like: $server->service($_SERVER['HTTP_RAW_POST_DATA']); Only thing is, it doesn't work. It *does* work if one states it this way: $server->service($HTTP_RAW_POST_DATA); Shouldn't the super-global be exactly the same as the environment variable? -- Edit this bug report at http://bugs.php.net/?id=20509&edit=1
#20510 [Csd->Fbk]: All spaces on a right padded string getting chopped
ID: 20510 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Closed +Status: Feedback Bug Type: MySQL related Operating System: Linux PHP Version: 4.3.0RC1 New Comment: The posted details make it sound like a bug to me so unless you truly know the answer nicos I don't think this should be closed. jrust, maybe it'd be helpful if you provide a small db schema that'll go along with a query so others can easily test it. Previous Comments: [2002-11-19 19:38:43] [EMAIL PROTECTED] I really don't think that can be PHP related... Post a MySQL bug instead? Did you tried that with MySQL 4 (C API)? Anyway if someone feels that I'm wrong, open it again. Thank you for the report. [2002-11-19 19:22:04] [EMAIL PROTECTED] The following mysql query should return the data padded with spaces on the right: However, the all spaces to the right of the string are chopped off, as if PHP (or maybe the MySQL api?) is doing an rtrim on the data. Some details: * The exact same query run from the MySQL console returns the correctly padded data. * If the ORDER BY is commented out the data comes back padded correctly. * If the query does not contain a JOIN the data comes back padded correctly (even if there is an ORDER BY) * It doesn't matter what the data is for table1 and table2 so long as the two tables can be joined and have some data in the fields * I am using MySQL version 3.23.52 -- Edit this bug report at http://bugs.php.net/?id=20510&edit=1
#20540 [Opn->Fbk]: PHP do not read PHP.INI
ID: 20540 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: Do this: a) load phpinfo(); b) It will tell you where your php.ini is or where it's looking for it. It will include the path and filename so: c:\foo\php.ini c) Not that (b) will not just be a path, it will include the filename too. Please confirm this. If just a path shows, put your php.ini in this directory. d) Edit this php.ini. If you are running php as a module, restart web server. e) For kicks, try changing some more common directives, such as register_globals Also, name it php.ini not PHP.ini although on windows this shouldn't matter but... Previous Comments: [2002-11-21 04:45:25] [EMAIL PROTECTED] Hello, I've put PHP.ini in C:\WINXP as requested, but when I modify it (for exemple changing the SMTP server info), phpinfo() do NOT get the changes... I verified again and again, php.ini is correct with the changes, but the SMTP value is still the default value "localhost"... I've check, I have no other php.ini on my machine... I even suppress php.ini, but phpinfo() do not really care it seems... taking always default values. Thanks in advance for your help -- Edit this bug report at http://bugs.php.net/?id=20540&edit=1
#8353 [Csd->Opn]: foreach modify array pointer
ID: 8353
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Closed
+Status: Open
Bug Type:Arrays related
-PHP Version: 4.0.4
+PHP Version: 4.3.0-dev
New Comment:
foreach essentially REMOVES the array pointer alltogether on the
original array.
$arr = array('a','b'); foreach ($arr as $v); var_dump( current($arr)
);
$arr = array('a','b'); foreach ($arr as $v); reset($arr); var_dump(
current($arr) );
Results:
bool(false)
string(1) "a"
Using key() instead of current() results in NULL instead of false.
Where did the pointer go?
Conclusion:
Either foreach() has a feature that removes the array pointer from the
original array or it's a bug. If it's seen as a feature please explain
why so it can be documented.
Previous Comments:
[2001-03-09 21:32:57] [EMAIL PROTECTED]
no feedback.
[2001-01-05 22:52:10] [EMAIL PROTECTED]
I get 121 for both cases. Please try the latest snapshot from
http://snaps.php.net/
--Jani
[2000-12-21 09:44:03] [EMAIL PROTECTED]
try 1.:
$var[] = "1";
$var[] = "2";
foreach($var as $test)
{
echo $test;
}
reset($var);
echo current($var);
output -> 12
then try:
$var[] = "1";
$var[] = "2";
//reset($var);
foreach($var as $test)
{
echo $test;
current($var);
}
echo current($var);
output -> 121
this should be the output of the first script too?
Greetings lunepi
--
Edit this bug report at http://bugs.php.net/?id=8353&edit=1
#19640 [Bgs->Opn]: [phpweb] Make mirrors not crawlable
ID: 19640 Updated by: [EMAIL PROTECTED] -Summary: Too many docs mirrors - Yes, I think it's a bug. Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Open -Bug Type: Documentation problem +Bug Type: Feature/Change Request Operating System: ALL -PHP Version: 4.2.3 +PHP Version: 4.4.0-dev New Comment: How about adding such things as -manual in your search query. In otherwords, - can be useful too. Regarding this bug report this is a valid point to consider. I'm reclassifying this as a phpweb feature request titled "Make mirrors not crawlable" So, a robots.txt similar to: User-agent: * Disallow: /manual/ But, keep in mind the benefit of having mirrors indexable as it means less traffic on the already overburdened www.php.net server. Also keep in mind that there are a ton of 'uncontrollable' unofficial mirrors that simply download the manual and put it on their site. In this case maybe a meta tag might be more appropriate, such as: Anyway, this is something to think about and is a feature request for the phpweb team. Regarding giving up on PHP, that's too bad. I hope it's not because there are too many php manuals indexed in google. Previous Comments: [2002-11-26 20:22:05] [EMAIL PROTECTED] My point was totally lost. I will try again: I cannot find good tutorials that may include a particular function because everyone and his mother is mirroring the documentation for that particular function. It would not be overly difficult to remind mirror maintainers that googlebot needs not crawl thier mirror. Its not like it really matters now, I've all but given up on php anyways. [2002-09-28 06:41:32] [EMAIL PROTECTED] It would be a good idea to visit one of the many php-tutorial sites/script download sites (e.g. HotScripts.com). [2002-09-28 04:54:41] [EMAIL PROTECTED] First of all, we cannot correct this. Second think about PHP codes. If you would like to find HTML pages using the lenght JS property, would you search for ":.length" in google. No. Because JS content is not indexed. The same stands for PHP codes. As far as I see approximately 95% of PHP code available on the net is distributed in compressed files, or only available after authentication (phpclasses for example). So searching for a function name, counting on google to return PHP source code results is quite bad direction. [2002-09-27 15:33:44] [EMAIL PROTECTED] If I try to find others' examples of a particular function by searching google for that function, I get HUNDREDS of pages that are nothing more than mirrors of the documentation, which I have ALREADY READ (its the first place I go when I need help with a function). This just plain sucks. I appreciate having faster places to read the documentation, but for christs sake, sometimes I just want to look at others' code because thats how I learn. I know soneone is going to get angry and say this is not a bug, but to me, its an annoyance of such proportion that it should be considered a bug. PLEASE PLEASE PLEASE ask doc-mirrors to not allow googlebot to crawl thier mirror as it's extremely frustrating. -- Edit this bug report at http://bugs.php.net/?id=19640&edit=1
#20644 [Opn]: Incrementing/Decrementing booleans != boolean+1
ID: 20644 Updated by: [EMAIL PROTECTED] -Summary: in some cases ++ operation DOESN'T work Reported By: [EMAIL PROTECTED] Status: Open -Bug Type: Documentation problem +Bug Type: Scripting Engine problem -Operating System: Win32, FreeBSD +Operating System: all -PHP Version: 4.2.1 +PHP Version: 4.3.0-dev New Comment: Please explain how this is to be documented (why this isn't a bug) as I fail to understand the seemingly inconsistent behavior of this example: $t = true; $a = $t + 1; (same as $t += 1; // 2) $b = ++$t; print "a: $a b: $b"; // a: 2 b: 1 In otherwords, incrementing/decrementing a boolean keeps it as boolean while adding an integer, such as 1, changes it to an integer. Reclassifying as a scripting engine problem so php-dev gets this report. Please provide a documentable reason for this behavior. Previous Comments: [2002-11-27 01:49:34] [EMAIL PROTECTED] Reclassified. [2002-11-27 01:24:49] [EMAIL PROTECTED] it was really an user error, sorry. i found than "++" operator doesn't make type conversion from boolean to int, and if variable is boolean and equals TRUE than after ++ it remains as TRUE, so $a = TRUE; echo ($a++).$a; produces output "11" this behavior of increment operator was unexpected to me and i suppose that it can be the same to others, so i wrote an user note at "type juggling" part at online documentation [2002-11-26 20:37:54] [EMAIL PROTECTED] Not known and most likely user error. Please provide a reproducing script. [2002-11-26 07:32:11] [EMAIL PROTECTED] After installing PHP 4.2.1 in some time I noticed a strange bug: at some situation increment operation (++) didn't work! I failed to write a simple code to reproduce that bug (it occurs regular at the same situation in nested functions of a rather big project), but in short - when trying to increment by ++ operation a function parameter, which was setted to 1 as a default parameter value of upper function (which called that function), incrementation does NOT happen. and such code as echo $newteamid; $newteamid++; echo $newteamid; $a = $newteamid; echo $a; $a++; echo $a; produces an output: "" but if I use " += 1" instead of "++" all works ok (and I was to make so at my project) as I mentioned I tried to reproduce that bug at simple code, but it works ok in a short program with the same variables values. and the same occurs at PHP 4.2.3. if that bug is not known I can try to write an example for this (dont wanna waste a time if it's well-known) but please confirm that -- Edit this bug report at http://bugs.php.net/?id=20644&edit=1
#8353 [Fbk->Opn]: foreach modify array pointer
ID: 8353
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type:Arrays related
-PHP Version: 4.3.0-dev
+PHP Version: 4.4.0-dev
New Comment:
As I've been taught, foreach doesn't affect the pointer as it merely
works on a copy. Also, the following note exists in the foreach()
entry of the manual and has for over two years:
Note: Also note that foreach operates on a copy of the specified
array, not the array itself, therefore the array pointer is not
modified as with the each() construct and changes to the array element
returned are not reflected in the original array.
That was added by Sterling here:
http://cvs.php.net/diff.php/phpdoc/en/language/control-structures.xml?login=2&r1=1.9&r2=1.10&ty=h
Everyone assumes foreach works on a copy and only a copy. IMHO each()
isn't a fair comparison because it doesn't work on a copy.
Previous Comments:
[2002-11-24 23:10:40] [EMAIL PROTECTED]
IMO this is not a bug. Foreach works virtually like while + each
combination, with a few exceptions such as not requiring a reset()
prior to execution since it does not care about the current position in
the array.
As far as current(), next() and simular are concerned,
while (each($arr)); == foreach ($arr as $v);, once the loops are
complete current() will return FALSE. This IMO is a consistent
behaviour and is definately not a bug. I believe this is merely a
documentation issue.
[2002-11-21 15:21:34] [EMAIL PROTECTED]
foreach essentially REMOVES the array pointer alltogether on the
original array.
$arr = array('a','b'); foreach ($arr as $v); var_dump( current($arr)
);
$arr = array('a','b'); foreach ($arr as $v); reset($arr); var_dump(
current($arr) );
Results:
bool(false)
string(1) "a"
Using key() instead of current() results in NULL instead of false.
Where did the pointer go?
Conclusion:
Either foreach() has a feature that removes the array pointer from the
original array or it's a bug. If it's seen as a feature please explain
why so it can be documented.
[2001-03-09 21:32:57] [EMAIL PROTECTED]
no feedback.
[2001-01-05 22:52:10] [EMAIL PROTECTED]
I get 121 for both cases. Please try the latest snapshot from
http://snaps.php.net/
--Jani
[2000-12-21 09:44:03] [EMAIL PROTECTED]
try 1.:
$var[] = "1";
$var[] = "2";
foreach($var as $test)
{
echo $test;
}
reset($var);
echo current($var);
output -> 12
then try:
$var[] = "1";
$var[] = "2";
//reset($var);
foreach($var as $test)
{
echo $test;
current($var);
}
echo current($var);
output -> 121
this should be the output of the first script too?
Greetings lunepi
--
Edit this bug report at http://bugs.php.net/?id=8353&edit=1
#20737 [Bgs]: PHP has Apache 2 support?
ID: 20737 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: *Configuration Issues Operating System: Red Hat Linux 7.3 PHP Version: 4.3.0RC2 New Comment: Maybe INSTALL should have a small note regarding apache 2. Previous Comments: [2002-11-30 18:36:07] [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. [2002-11-30 12:52:43] [EMAIL PROTECTED] > And, regardless, assuming that PHP has Apache 2 support, > the wording in the installation should be changed from > > ... Apache 1.x module ... That should actually give you a hint. Did you use --with-apxs= or --with-apxs2= ? [2002-11-30 12:41:42] [EMAIL PROTECTED] Since I am commenting anyway, where can one get the PHP-Bug reporting system software. It is rather good. [2002-11-30 12:39:59] [EMAIL PROTECTED] And, regardless, assuming that PHP has Apache 2 support, the wording in the installation should be changed from ... Apache 1.x module ... No? It is somewhat misleading to someone hitting another bug and wondering whether Apache 2 is supported. [2002-11-30 12:36:49] [EMAIL PROTECTED] /usr/bin/perl -v gives appropriate response. Thus appears to be valid perl interpreter. 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/20737 -- Edit this bug report at http://bugs.php.net/?id=20737&edit=1
#20488 [Bgs->Opn]: is_dir(), Warning: Unable ...
ID: 20488
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Bogus
+Status: Open
Bug Type: Directory function related
Operating System: winME
PHP Version: 4.2.3
New Comment:
I don't get it. Someone reports a bug, it's tested in latest PHP
version as asked, problem still exists ... and now it's marked as
bogus?
Why doesn't this simply return boolean false? Where is this behavior
documented? Reopening...
Previous Comments:
[2002-12-01 16:35:43] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
[2002-11-18 16:52:58] [EMAIL PROTECTED]
Nope not in safe mode at least, now i simply get a ref to the php doc
page with the warning (4.3RC1):
is_dir("non existing directory...");
Warning: is_dir() [http://www.php.net/function.is-dir]: Unable to
access "non existing directory..." in "whatever.php" on line "xx"
Again, this only happens if safe mode is turned ON
[2002-11-18 16:03:08] [EMAIL PROTECTED]
Okay, it looks like this is fixed in CVS. Can you try the windows
snapshot @ http://snaps.php.net/~edink/php-4.3.0RC1-Win32.zip ?
Derick
[2002-11-18 15:56:09] [EMAIL PROTECTED]
is_dir("nonexisten directory.");
result:
Warning: Unable to access "nonexisten directory." in "whatever.php"
on line "xx"
[2002-11-18 15:53:08] [EMAIL PROTECTED]
What is the full error message?
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/20488
--
Edit this bug report at http://bugs.php.net/?id=20488&edit=1
#20754 [Csd->Bgs]: PROBLEM WITH SPLIT FUNCTION
ID: 20754
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Closed
+Status: Bogus
Bug Type: Strings related
Operating System: Win 2k
PHP Version: 4.2.3
Previous Comments:
[2002-12-01 21:06:22] [EMAIL PROTECTED]
sorry, didnt know i have to put 2 escape characters for a for both
escape character \ and search character '\'.
thanks :)
[2002-12-01 20:56:37] [EMAIL PROTECTED]
Your regex is broken, it should be:
$arr = split ("", $mytest);
[2002-12-01 20:36:35] [EMAIL PROTECTED]
I was trying to split the string with the splitter "\", but it gives me
this error message:
"Warning: REG_EESCAPE:wtrailing backslash (\) in
E:\Inetpub\wwwroot\test\split.php on line 8"
MY SCRIPT:
$mytest = "STAFF\Tester";
$arr = split ("\\", $mytest); //--> ERROR!
Please help!
--
Edit this bug report at http://bugs.php.net/?id=20754&edit=1
#14877 [Opn]: HTTP_FDF_DATA not available (php_fdf.dll crashes)
ID: 14877 Updated by: [EMAIL PROTECTED] -Summary: HTTP_FDF_DATA not available Reported By: [EMAIL PROTECTED] Status: Open Bug Type: FDF related Operating System: XP Pro PHP Version: 4.4 dev Assigned To: hholzgra New Comment: I've been testing windows today (I have very little experience installing on win32 so bare with me) and so I decided to include all the dlls. This particular one (php_fdf.dll) is causing problems and when the dll is loaded it gives an error at startup yet no error in the error log. Apache still runs but PHP will not. In short: I just experienced what Christoph did, *crash*. Although I only tested php4.3.0rc2... Apache module. Previous Comments: [2002-11-29 14:01:23] [EMAIL PROTECTED] sorry for the delay - dev snapshot from today still crashing at startup when fdf is enabled. [2002-11-19 01:00:04] [EMAIL PROTECTED] No feedback was provided for this bug for over 2 weeks, 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-11-03 11:15:37] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-10-30 15:48:18] [EMAIL PROTECTED] The last one that I tried and that worked was 4.07dev from July,3 2001. Then a dev version from beginning of January 2002 was not working with other symptoms (see original bug report). I then only tried again recently when Hartmut asked me to do so. Meanwhile other people were mailing and asked me if I found a solution as they've had the same problems. [2002-10-29 17:06:01] [EMAIL PROTECTED] What was the version of PHP with which it didn't crash? 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/14877 -- Edit this bug report at http://bugs.php.net/?id=14877&edit=1
#20753 [Bgs]: php.ini not read
ID: 20753
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: PHP options/info functions
Operating System: WinXP
PHP Version: 4.2.3
New Comment:
Also it's worth noting that phpinfo() will say:
// Is working
c:\foo\php.ini
As opposed to:
// Is not working
c:\foo\
In otherwords, the name of php.ini will be seen too, not just the
path.
Also, please look in your windows options to see if known extensions
are being hidden. When looking at the list of files there should be an
option in:
Tools -> Folder Options -> View ->
"Hide file extensions with known types" [ ]
I believe this defaults to on. Not sure about WinXP but this has
existed in other versions. Anyway, php.ini.ini would show as php.ini
in this case. Also, this may have been the reason why you added the
second .ini. Please confirm and for the love that is sane turn that
silly feature off :)
Previous Comments:
[2002-12-02 09:51:17] [EMAIL PROTECTED]
This *is* bug (for MS), but also a "support issue" (for PHP). Turns
out that WinXP refuses to display the final ".ini" extension, even in
the "properties" display, the file-rename box, or the details list; my
file had actually been named "php.ini.ini", and all I could ever see at
all in any GUI was "php.ini" (except when I finally used the command
line prompt). Sorry for taking your time, but this is an extremely
subtle problem: perhaps the documentation could mention that the
renaming and name-checking must happen in the command prompt ("DOS"),
because otherwise there will be no error that the file wasn't found.
Take care!
[2002-12-01 23:12:43] [EMAIL PROTECTED]
OK, finally got it working: here's the top of phpinfo():
PHP Version 4.4.0-dev
System Windows NT localhost 5.1 build 2600
Build Date Dec 2 2002 04:12:18
Server API Apache
Virtual Directory Support enabled
Configuration File (php.ini) Path C:\WINDOWS
PHP API 20020918
Right below, it shows:
Directive Local Value Master Value
allow_call_time_pass_reference On On
allow_url_fopen On On
The file c:\windows\php.ini still has these entries:
allow_call_time_pass_reference = Off
allow_url_fopen = Off
So it looks like even the CVS snapshot is ignoring the php.ini file it
expects to see. Glad it doesn't want c:\winnt any more; that's an
improvement. But the "bug" (or "support issue") remains...
[2002-12-01 22:07:30] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-latest.zip
[2002-12-01 21:55:37] [EMAIL PROTECTED]
I assume you mean what phpinfo() prints out in the table at the top
(I've clipped it here):
System Windows NT 5.1 build 2600
Build Date Sep 6 2002 10:38:51
Server API Apache
Virtual Directory Support enabled
Configuration File (php.ini) Path c:\winnt
Debug Build no
Thread Safety enabled
I'd be happy to try changing c:\winnt to some other directory, but I
have no idea how to, or where that is configured.
[2002-12-01 19:49:43] [EMAIL PROTECTED]
This is most likely another support question, but let's try help you
anyway: What is said by phpinfo() for where it's trying to read php.ini
from?
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/20753
--
Edit this bug report at http://bugs.php.net/?id=20753&edit=1
#20765 [Opn->Bgs]: problem with array_search function
ID: 20765 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Scripting Engine problem Operating System: Windows XP PHP Version: 4.2.3 New Comment: There is a warning in the docs, I'll quote it here: This function may return Boolean FALSE, but may also return a non-Boolean value which evaluates to FALSE, such as 0 or "". Please read the section on Booleans for more information. Use the === operator for testing the return value of this function. This comes from the &return.falseproblem; entity in the docs. Previous Comments: [2002-12-02 11:10:15] [EMAIL PROTECTED] array_search will return "THE POSITION of the NEEDLE" when a needle is found in an array and return "FALSE" when not found. The problem will occur when the NEEDLE is found to be at the first position of an array which will return a "0", a value that is equipvalent to "FALSE" though the NEEDLE has been successfully found. -- Edit this bug report at http://bugs.php.net/?id=20765&edit=1
#20779 [Opn]: Several dll entry points not found in php4ts.dll
ID: 20779 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Dynamic loading Operating System: Win2k Pro PHP Version: 4.3.0RC2 New Comment: >From the docs: http://www.php.net/manual/en/printwn/install.apache2.php Note: Apache 2.0 SAPI-support started with PHP 4.2.0. PHP 4.2.3 its known to work in conjunction with Apache 2.0.39. Don't try to use this version of PHP with any other version of Apache. We do not recommend to use PHP 4.2.3 along with Apache 2.0.39. And btw, are you trying 4.2.3 or 4.3.0RC2, you list both in this bug report. This looks like an Apache2 related bug so the category may want to reflect that but I personally have no idea so won't touch it :) Previous Comments: [2002-12-02 21:28:38] [EMAIL PROTECTED] Please excuse the spelling mistake : dynamic link librart should be dynamic link library. [2002-12-02 21:26:21] [EMAIL PROTECTED] I have installed Apache 2.0.43 as a service on Win 2k with PHP 4.2.3. These are upgrades from Apache 2.0.39 and PHP 4.2.2. Now I had previuosly enabled the following php extensions and they worked fine in the older setup. Now, after the upgrade, they don't. They are bz2, ctypye, curl, ming, pdf, zlib. The errors are: php_bz2.dll Apache.exe - Entry Point Not Found The procedure entry point php_file_le_fpoen could not be loacted in the dynamice link librart php4ts.dll Unkown(): Unable to load dynamic library './php_bz.dll' - The procedure could not be found' php_ctype functions: Warning Function registration failed - duplicate name - ctype_alnum Warning Function registration failed - duplicate name - ctype_alpha Warning Function registration failed - duplicate name - ctype_cntrl Warning Function registration failed - duplicate name - ctype_digit Warning FunctioWarning Function registration failed - duplicate name - ctype_print Warning Function registration failed - duplicate name - ctype_space Warning Function registration failed - duplicate name - ctype_upper Warning Function registration failed - duplicate name - ctype_xdigit Warning ctype: unable to register function, unable to load php_curl.dll: Apache.exe - Entry Point Not Found The procedure entry point php_file_le_fpoen could not be loacted in the dynamice link librart php4ts.dll Unkown(): Unable to load dynamic library './php_bz.dll' - The procedure could not be found' php_ming.dll Apache.exe - Entry Point Not Found The procedure entry point php_fsock_fread could not be loacted in the dynamice link librart php4ts.dll Unkown(): Unable to load dynamic library './php_ming.dll' - The procedure could not be found' php_pdf.dll Apache.exe - Entry Point Not Found The procedure entry point zif_warn_not_available could not be loacted in the dynamice link librart php4ts.dll Unkown(): Unable to load dynamic library './php_pdf.dll' - The procedure could not be found' php_zlib.dll Apache.exe - Entry Point Not Found The procedure entry point php_fopen_wrapper could not be loacted in the dynamice link librart php4ts.dll Unkown(): Unable to load dynamic library './php_zlib.dll' - The procedure could not be found' End of errors details. --- The workaround works by disabling these extension in the php.ini file but this is not pratical for me long term. The extension folder is located under :c:/php/extensions. This problems occured after the upgrade to the latest versions of php and apache. Please assist, as it would be much appreciated. Charlie -- Edit this bug report at http://bugs.php.net/?id=20779&edit=1
#20779 [Dup]: Apache 2 + PHP not working.
ID: 20779 Updated by: [EMAIL PROTECTED] -Summary: Several dll entry points not found in php4ts.dll Reported By: [EMAIL PROTECTED] Status: Duplicate -Bug Type: *Configuration Issues +Bug Type: Apache2 related Operating System: Win2k Pro PHP Version: 4.2.3 New Comment: PHP with Apache 2 support is experimental. If you want something that will for sure work use Apache 1.3.xx instead. But if you're bored, try downloading the latest PHP, which is 4.3.0RC2, and see if it works with that. A link can be found here: http://qa.php.net/ Those docs are a little odd but it basically says what is known to work (PHP 4.2.3 + Apache 2.0.39) and that any other combo will most likely NOT work. User beware. Apache 2 + PHP is not recommended right now. This is a known issue and being worked on. Previous Comments: [2002-12-03 00:04:03] [EMAIL PROTECTED] Error with Version in header of posting ... Version of PHP is 4.2.3. [2002-12-03 00:02:51] [EMAIL PROTECTED] Error with Version in header of posting ... Version of PHP is 4.2.3. [2002-12-02 23:56:10] [EMAIL PROTECTED] Hi there Additional Category: Apache Just to clarify some points, i am using Apache 2.0.43 not Apache 2.0.39. So does the warning (below), of which I was aware of apply to newer versions of Apache (ie 2.0.40 and later). If its a known issue, then what measure have been taken to fix it. I believe its a PHP error. Apache runs everything else okay. The apache server environment is only for local development (i.e desktop). Secondly, I am using 4.2.3, which I downloaded on Saturday, Australian DST. Charlie PS The documentated warning about PHP and apache on windows for sapi seem to contradictory comapre these two sentences: "PHP 4.2.3 its known to work in conjunction with Apache 2.0.39." --- so PHP 4.2.3 works. "We do not recommend to use PHP 4.2.3 along with Apache 2.0.39." --- so as it works, it is not recommened. Eh? "Don't try to use this version of PHP with any other version of Apache." --- Is that earlier (older) or later (newer) versions of apache i.e before/after v.2.0.39. A fuller explaination would be preferable. I know that a the PHP 4.2.2 sapi worked with Apache 2.0.39, via console set up (not as a service) - although it was fiddley and a manual start up - but no errors. [2002-12-02 23:55:34] [EMAIL PROTECTED] Hi there Additional Category: Apache Just to clarify some points, i am using Apache 2.0.43 not Apache 2.0.39. So does the warning (below), of which I was aware of apply to newer versions of Apache (ie 2.0.40 and later). If its a known issue, then what measure have been taken to fix it. I believe its a PHP error. Apache runs everything else okay. The apache server environment is only for local development (i.e desktop). Secondly, I am using 4.2.3, which I downloaded on Saturday, Australian DST. Charlie PS The documentated warning about PHP and apache on windows for sapi seem to contradictory comapre these two sentences: "PHP 4.2.3 its known to work in conjunction with Apache 2.0.39." --- so PHP 4.2.3 works. "We do not recommend to use PHP 4.2.3 along with Apache 2.0.39." --- so as it works, it is not recommened. Eh? "Don't try to use this version of PHP with any other version of Apache." --- Is that earlier (older) or later (newer) versions of apache i.e before/after v.2.0.39. A fuller explaination would be preferable. I know that a the PHP 4.2.2 sapi worked with Apache 2.0.39, via console set up (not as a service) - although it was fiddley and a manual start up - but no errors. [2002-12-02 21:41:43] [EMAIL PROTECTED] >From the docs: http://www.php.net/manual/en/printwn/install.apache2.php Note: Apache 2.0 SAPI-support started with PHP 4.2.0. PHP 4.2.3 its known to work in conjunction with Apache 2.0.39. Don't try to use this version of PHP with any other version of Apache. We do not recommend to use PHP 4.2.3 along with Apache 2.0.39. And btw, are you trying 4.2.3 or 4.3.0RC2, you list both in this bug report. This looks like an Apache2 related bug so the category may want to reflect that but I personally have no idea so won't touch 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/20779 -- Edit this bug report at http://bugs.php.net/?id=20779&edit=1
#20796 [Bgs->Ver]: Overridden Get, Post and Cookie data with register_globals turned on
ID: 20796
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Bogus
+Status: Verified
Bug Type: Variables related
Operating System: Red Hat 8.0
-PHP Version: 4.2.2
+PHP Version: 4.3.0-rc2
New Comment:
Just verified this bug, so:
a) Only arrays are affected.
b) Only affected if register_globals = on
c) This is a bug, $_GET for example should never have a
COOKIE value it in.
Here's another piece of test code, and the results with
register_globals = on. When register_globals = off, everything works
as expected.
And:
Provides us with:
GET
Array
(
[a] => Array
(
[foo] => I_AM_A_COOKIE
)
[b] => another_get
[c] => bar
)
POST
Array
(
[a] => Array
(
[foo] => I_AM_A_COOKIE
)
[b] => another_post
[c] => bar
[submit] => submit
)
COOKIE
Array
(
[a] => Array
(
[foo] => I_AM_A_COOKIE
)
[b] => I_AM_ALSO_A_COOKIE
[c] => bar
)
REQUEST
Array
(
[a] => Array
(
[foo] => I_AM_A_COOKIE
)
[b] => I_AM_ALSO_A_COOKIE
[c] => bar
[submit] => submit
)
$_REQUEST of course works as expected according to the variables_order
directive.
Previous Comments:
[2002-12-03 13:28:47] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
This is why register_globals is dangerous, if there are variables with
the same name they get over-written. This is why you should keep it
off.
You can control the order of the way variables passed via
GET/POST/COOKIE/FILES are registered via the gpc_order ini setting.
[2002-12-03 12:25:22] [EMAIL PROTECTED]
With register_globals turned on, if 3 variables WITH THE
SAME NAME are defined in your script (one as a Get
variable, one as a Post variable and one as a Cookie
variable) and if this name is an ARRAY ELEMENT (let's
say foo[ab]), then $_GET["foo"]["ab"] and
$_POST["foo"]["ab"] will both be set to $_COOKIE["foo"]["ab"].
Let's try it.
First, write the script "print_gpc.php" :
";
print_r($_GET);
echo "";
echo '$_POST';
echo "";
print_r($_POST);
echo "";
echo '$_COOKIE';
echo "";
print_r($_COOKIE);
echo "";
?>
Then call the form below ("test.php") in your browser :
and clic on the OK button.
If you have register_globals turned off, you will see
what you expect :
$_GET
Array
(
[foo] => Array
(
[ab] => I_am_a_get_value
)
)
$_POST
Array
(
[foo] => Array
(
[ab] => OK
)
)
$_COOKIE
Array
(
[foo] => Array
(
[ab] => I_am_a_cookie
)
)
but if you have register_globals turned on,
you will have $_GET["foo"]["ab"] == "I_am_a_cookie"
and $_POST["foo"]["ab"] == "I_am_a_cookie".
Strangly, this problem does not occur if the cookie name
is NOT an array element EVEN if register_globals is
turned On. (Try to replace "foo[ab]" by "foo" in the
"test.php" form.)
--
Edit this bug report at http://bugs.php.net/?id=20796&edit=1
#20796 [Ver->Ctl]: Overridden Get, Post and Cookie data with register_globals turned on
ID: 20796
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Verified
+Status: Critical
Bug Type: Variables related
Operating System: Red Hat 8.0
PHP Version: 4.3.0-rc2
New Comment:
Marking as critical as this bug causes autoglobals
to be unreliable.
Previous Comments:
[2002-12-03 14:31:19] [EMAIL PROTECTED]
Just verified this bug, so:
a) Only arrays are affected.
b) Only affected if register_globals = on
c) This is a bug, $_GET for example should never have a
COOKIE value it in.
Here's another piece of test code, and the results with
register_globals = on. When register_globals = off, everything works
as expected.
And:
Provides us with:
GET
Array
(
[a] => Array
(
[foo] => I_AM_A_COOKIE
)
[b] => another_get
[c] => bar
)
POST
Array
(
[a] => Array
(
[foo] => I_AM_A_COOKIE
)
[b] => another_post
[c] => bar
[submit] => submit
)
COOKIE
Array
(
[a] => Array
(
[foo] => I_AM_A_COOKIE
)
[b] => I_AM_ALSO_A_COOKIE
[c] => bar
)
REQUEST
Array
(
[a] => Array
(
[foo] => I_AM_A_COOKIE
)
[b] => I_AM_ALSO_A_COOKIE
[c] => bar
[submit] => submit
)
$_REQUEST of course works as expected according to the variables_order
directive.
[2002-12-03 13:28:47] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
This is why register_globals is dangerous, if there are variables with
the same name they get over-written. This is why you should keep it
off.
You can control the order of the way variables passed via
GET/POST/COOKIE/FILES are registered via the gpc_order ini setting.
[2002-12-03 12:25:22] [EMAIL PROTECTED]
With register_globals turned on, if 3 variables WITH THE
SAME NAME are defined in your script (one as a Get
variable, one as a Post variable and one as a Cookie
variable) and if this name is an ARRAY ELEMENT (let's
say foo[ab]), then $_GET["foo"]["ab"] and
$_POST["foo"]["ab"] will both be set to $_COOKIE["foo"]["ab"].
Let's try it.
First, write the script "print_gpc.php" :
";
print_r($_GET);
echo "";
echo '$_POST';
echo "";
print_r($_POST);
echo "";
echo '$_COOKIE';
echo "";
print_r($_COOKIE);
echo "";
?>
Then call the form below ("test.php") in your browser :
and clic on the OK button.
If you have register_globals turned off, you will see
what you expect :
$_GET
Array
(
[foo] => Array
(
[ab] => I_am_a_get_value
)
)
$_POST
Array
(
[foo] => Array
(
[ab] => OK
)
)
$_COOKIE
Array
(
[foo] => Array
(
[ab] => I_am_a_cookie
)
)
but if you have register_globals turned on,
you will have $_GET["foo"]["ab"] == "I_am_a_cookie"
and $_POST["foo"]["ab"] == "I_am_a_cookie".
Strangly, this problem does not occur if the cookie name
is NOT an array element EVEN if register_globals is
turned On. (Try to replace "foo[ab]" by "foo" in the
"test.php" form.)
--
Edit this bug report at http://bugs.php.net/?id=20796&edit=1
#20777 [Bgs]: will not find apache2 apxs
ID: 20777 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Apache2 related Operating System: Solaris 8 PHP Version: 4.3.0RC2 New Comment: Tell us what this says: /www2/bin/apxs -q INCLUDEDIR Previous Comments: [2002-12-04 01:57:32] [EMAIL PROTECTED] This works just fine here. Must be something wrong in your apache2 install. (update it, it's most likely too old or you're really trying to configure with apache1) [2002-12-03 14:48:19] [EMAIL PROTECTED] Sorry I typed the message wrong it is /www2/bin/apxs [2002-12-02 18:52:24] [EMAIL PROTECTED] You're using /www/bin/apxs but showing the output of /www2/bin/apxs, so which one is the right one? [2002-12-02 18:49:52] [EMAIL PROTECTED] ./configure --with-apxs2=/www/bin/apxs just testing Configuring SAPI modules checking for AOLserver support... no checking for Apache 1.x module support via DSO through APXS... no checking for Apache 1.x module support... no checking for mod_charset compatibility option... no checking for Apache 2.0 module support via DSO through APXS... Sorry, I cannot run apxs. Possible reasons follow: 1. Perl is not installed 2. apxs was not found. Try to pass the path using --with-apxs2=/path/to/apxs 3. Apache was not built using --enable-so (the apxs usage page is displayed) The output of /www2/bin/apxs follows: Usage: apxs -g [-S =] -n apxs -q [-S =] ... apxs -c [-S =] [-o ] [-D [=]] [-I ] [-L ] [-l ] [-Wc,] [-Wl,] ... apxs -i [-S =] [-a] [-A] [-n ] ... apxs -e [-S =] [-a] [-A] [-n ] ... configure: error: Aborting bash-2.05# perl asdf ^C bash-2.05# perl -v This is perl, v5.6.1 built for sun4-solaris Copyright 1987-2001, Larry Wall Perl may be copied only under the terms of either the Artistic License or the GNU General Public License, which may be found in the Perl 5 source kit. Complete documentation for Perl, including FAQ lists, should be found on this system using `man perl' or `perldoc perl'. If you have access to the Internet, point your browser at http://www.perl.com/, the Perl Home Page. bash-2.05# -- Edit this bug report at http://bugs.php.net/?id=20777&edit=1
#7220 [Opn]: Error Report on Function Arguments
ID: 7220
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Feature/Change Request
-Operating System: HP-UX / Linux / FreeBSD
+Operating System: all
-PHP Version: 4.0.3
+PHP Version: 4.3.0
New Comment:
This sounds like a decent request, how about having the error report
both locations?
Previous Comments:
[2001-02-24 12:38:22] [EMAIL PROTECTED]
Not really a bug.. its the expected behaviour. Changing to feature
request.
James
[2000-10-15 11:38:02] [EMAIL PROTECTED]
function bob($arg1, $arg2) {
;
}
bob(4);
bob(5,2);
i.e., PHP will falselpy report the error with bob(4) in funcion Bob
(i.e., line 1)
instead of bob(4) i.e., line 5.
This is quite annoying when tracking down function calls that have an
incorrect number of arguments
--
Edit this bug report at http://bugs.php.net/?id=7220&edit=1
#7535 [Ana]: Entities missing in get_html_translation_table ( HTML_ENTITIES );
ID: 7535 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Analyzed Bug Type: Feature/Change Request Operating System: FreeBSD PHP Version: 4.0.3pl1 New Comment: Can someone explain this a bit in laymens terms so it can be documented? Previous Comments: [2002-04-27 18:58:16] [EMAIL PROTECTED] ÿ and € are implemented. (€ when using the iso-8859-15 charset.) the other entities are not included because htmlentities() does not handle entities outside of the 8-bit character range. [2000-10-30 13:26:39] [EMAIL PROTECTED] These are the entities not listed in this function. Character entity references in HTML 4 (http://www.w3.org/TR/html4/sgml/entities.html) "ÿ" => "ÿ" "ƒ" => "ƒ" "Α" => "Α" "Β" => "Β" "Γ" => "Γ" "Δ" => "Δ" "Ε" => "Ε" "Ζ" => "Ζ" "Η" => "Η" "Θ" => "Θ" "Ι" => "Ι" "Κ" => "Κ" "Λ" => "Λ" "Μ" => "Μ" "Ν" => "Ν" "Ξ" => "Ξ" "Ο" => "Ο" "Π" => "Π" "Ρ" => "Ρ" "Σ" => "Σ" "Τ" => "Τ" "Υ" => "Υ" "Φ" => "Φ" "Χ" => "Χ" "Ψ" => "Ψ" "Ω" => "Ω" "α" => "α" "β" => "β" "γ" => "γ" "δ" => "δ" "ε" => "ε" "ζ" => "ζ" "η" => "η" "θ" => "θ" "ι" => "ι" "κ" => "κ" "λ" => "λ" "μ" => "μ" "ν" => "ν" "ξ" => "ξ" "ο" => "ο" "π" => "π" "ρ" => "ρ" "ς" => "ς" "σ" => "σ" "τ" => "τ" "υ" => "υ" "φ" => "φ" "χ" => "χ" "ψ" => "ψ" "ω" => "ω" "ϑ" => "ϑ" "ϒ" => "ϒ" "ϖ" => "ϖ" "•" => "•" "…" => "…" "′" => "′" "″" => "″" "‾" => "‾" "⁄" => "⁄" "℘" => "℘" "ℑ" => "ℑ" "ℜ" => "ℜ" "™" => "™" "ℵ" => "ℵ" "←" => "←" "↑" => "↑" "→" => "→" "↓" => "↓" "↔" => "↔" "↵" => "↵" "⇐" => "⇐" "⇑" => "⇑" "⇒" => "⇒" "⇓" => "⇓" "⇔" => "⇔" "∀" => "∀" "∂" => "∂" "∃" => "∃" "∅" => "∅" "∇" => "∇" "∈" => "∈" "∉" => "∉" "∋" => "∋" "∏" => "∏" "∑" => "∑" "−" => "−" "∗" => "∗" "√" => "√" "∝" => "∝" "∞" => "∞" "∠" => "∠" "∧" => "∧" "∨" => "∨" "∩" => "∩" "∪" => "∪" "∫" => "∫" "∴" => "∴" "∼" => "∼" "≅" => "≅" "≈" => "≈" "≠" => "≠" "≡" => "≡" "≤" => "≤" "≥" => "≥" "⊂" => "⊂" "⊃" => "⊃" "⊄" => "⊄" "⊆" => "⊆" "⊇" => "⊇" "⊕" => "⊕" "⊗" => "⊗" "⊥" => "⊥" "⋅" => "⋅" "⌈" => "⌈" "⌉" => "⌉" "⌊" => "⌊" "⌋" => "⌋" "⟨" => "〈" "⟩" => "〉" "◊" => "◊" "♠" => "♠" "♣" => "♣" "♥" => "♥" "♦" => "♦" "Œ" => "Œ" "œ" => "œ" "Š" => "Š" "š" => "š" "Ÿ" => "Ÿ" "ˆ" => "ˆ" "˜" => "˜" " " => " " " " => " " " " => " " "" => "" "" => "" "" => "" "" => "" "–" => "–" "—" => "—" "‘" => "‘" "’" => "’" "‚" => "‚" "“" => "“" "”" => "”" "„" => "„" "†" => "†" "‡" => "‡" "‰" => "‰" "‹" => "‹" "›" => "›" "€" => "€" -- Edit this bug report at http://bugs.php.net/?id=7535&edit=1
#8827 [Opn]: PHP_AUTH_PW stores password when using External Authentication
ID: 8827 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Feature/Change Request Operating System: Redhat Linux 6.2 PHP Version: 4.0.4pl1 New Comment: I believe this was fixed in 4.3.0, can someone confirm (Jani)? Previous Comments: [2001-06-10 15:22:07] [EMAIL PROTECTED] I understand about the raw headers. Which is why I am suggesting if it would be possible to have an administrator configurable flag to enable/disable PHP storing the password in PHP_AUTH_PW . Assumung that the web server only runs PHP with no CGI and such, it would be pretty difficult(?) for unauthorised users to extract the password from the raw headers. But PHP happily stores it in a variable and allows any programmer to access it. Thanks! [2001-06-09 23:52:43] [EMAIL PROTECTED] This is the correct behaviour the information is avalible via the raw headers anyway. - James [2001-04-28 23:09:00] [EMAIL PROTECTED] Isn't this going to be a big security problem for portal sites using PHP which have a common user base and separate groups of developers developing and selling online service? As a malicious group of developers would be able to capture the password and assume the identity of the user and go around "patronising" other services. How about having a general configuration parameter that disables the storage of the password in PHP_AUTH_PW and HTTP_RAW_HEADERS without having the need for PHP to autodetect for external authentications? Something like a STORE_PASSWORD = false flag in php.ini which the administrator needs to manually set to on or off. Thanks! [2001-04-28 16:12:30] [EMAIL PROTECTED] This is the expected behaviour now. HTTP_RAW_HEADERS holds the same information anyway. - James [2001-04-17 04:53:29] [EMAIL PROTECTED] I am currently running with safe_modes enabled but the password is still retrievable via the PHP_AUTH_PW variable when using external authentications. Thanks! 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/8827 -- Edit this bug report at http://bugs.php.net/?id=8827&edit=1
#20814 [Opn]: reproducable, freaky parse error in 'here document' structure
ID: 20814 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Scripting Engine problem -Operating System: several +Operating System: all -PHP Version: 4.2.3 +PHP Version: 4.4.0-dev New Comment: To clarify a few points: a) This is known and is both documented and is a current feature request: http://bugs.php.net/bug.php?id=8685 http://www.php.net/language.types.string#language.types.string.syntax.heredoc b) The error that's reported is odd, and looks something like this: Parse error: parse error, unexpected $ in test.php on line 42 Where 42 is, for example, on the last line of test.php even when the error is elsewhere. This error sorta makes sense in most cases (like a missing quote or closing brace) but IMHO not here. Maybe someone can briefly explain what PHP is thinking. c) Many have attempted to fix this and many more have reported it (a) but it appears to be almost impossible to fix and remains a feature request. Again, it is documented with a big fat warning. Am leaving as open as this mentions the strange error too (b), not just the known feature request. Previous Comments: [2002-12-04 11:23:05] [EMAIL PROTECTED] [quick on the trigger]... scratch that last sentence ... I was going to point out that the closing tag has to be flush left but I think that is not a bug. [2002-12-04 11:04:39] [EMAIL PROTECTED] I've tested this on PHP 4.2.3 for OSX, Open BSD, Linux... If you leave any whitespace after the closing tag of a here document structure (not sure if that's what it is called, like in Perl) a parse error will occur but never for the correct line. This seems like a bug to me because a semi- colon should terminate the code allowing the programmer to put comments or whatever after the semi-colon. Here is an example: $variable = "variable"; $someVariable = << text text $variable testing here document hereDocument; // closing comment or just whitespace echo $someVariable; After the closing "hereDocument;" if you leave any whitespace (other than a carriage return) or text, a parse error is generated but the line number never leads you to the right place. This can be very confusing if you are working on a large class (like I was) and you left a tab or space after a closing tag. I'm not sure how consciously supported the here document structure is but this is worth addressing since here documents can be very useful for storing large variables containing HTML code with double and single quotes, for example. While I'm submitting this bug, I might as well point -- Edit this bug report at http://bugs.php.net/?id=20814&edit=1
#14736 [Opn->]: about error_reporting for $_GET
ID: 14736 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Won\'t fix Bug Type: Feature/Change Request Operating System: all PHP Version: 4.1.1 New Comment: This is already possible with @. print @$_GET['id']; Regardless, autoglobals should still report undefined indices, I don't see any advantage in not reporting them but only the introduction of inconsistencies. This will never change, marking as "Won\'t fix". See also: array_key_exists(). Previous Comments: [2001-12-28 10:58:15] [EMAIL PROTECTED] suggest that it should be possible to turn off warnning of undefined index of $_GET ans $_POST and so on.. example: such as: url: http://www.domain.com/index.php code: would cause warnning 'Undefined index' unless the user must type in http://www.domain.com/index.php?id=123 or the code should be changed into: or maybe: of cause, we can turn off warnning for a running website. buthow can the web developers bear it when developing ? it's a 'terrible' warnning message that we don't want, we should have our attentions to those warnning about variables like $foo['bar'] not $_GET['id'] nor $_POST['username'] -- Edit this bug report at http://bugs.php.net/?id=14736&edit=1
#15018 [Opn]: opendir() not affected by safe_mode
ID: 15018 Updated by: [EMAIL PROTECTED] -Summary: readdir() not affected by safe_mode Reported By: [EMAIL PROTECTED] Status: Open -Bug Type: Feature/Change Request +Bug Type: Filesystem function related Operating System: Debian Linux -PHP Version: 4.1.0 +PHP Version: 4.3.0-RC2 New Comment: With: safe_mode = On safe_mode_gid = On The code below can browse any directory/file on the system. This mentions openbase_dir but one (at least I) would think Safe Mode would have more power. Safe mode is strict in some regards but super loose in others it seems. In the very least please explain this a bit so it can be documented. And btw, the following is in the _php_do_opendir code but what does it do? dirp = php_stream_opendir(Z_STRVAL_PP(arg), ENFORCE_SAFE_MODE|REPORT_ERRORS, NULL); Also AFICT this was suppose to be fixed: http://marc.theaimsgroup.com/?l=php-dev&m=101518887024304 Previous Comments: [2002-01-14 10:27:42] [EMAIL PROTECTED] Danielsan is right... i have had a short look into the sourcecode (ext/standard/dir.c) and compared chdir-function with opendir-function. In PHP_FUNCTION(chdir) i found this three-liner which seems to be a safe_mode-Check: - if (PG(safe_mode) && !php_checkuid((*arg)->value.str.val, NULL, CHECKUI$ RETURN_FALSE; } - PHP_FUNCTION(opendir) (or _php_do_opendir() to which this function refers) does not have such a check, just a short open_basedir-Check. Oh, btw, it seems for me that chdir doesn't do a open_basedir-Check but i may be wrong. cu, Roland PS: All what i said is just 'imho' and 'afaik' because i do not have many expiences with C! [2002-01-14 08:55:06] [EMAIL PROTECTED] i did not test it, but 'looking at the source code' (TM) seems you need to use open_basedir to limit opendir() directory range. [2002-01-14 08:25:55] [EMAIL PROTECTED] On the same system (=same configuration) chdir() IS limited by safe_mode, opendir() are readdir() are NOT. This is either a bug, or if it isn't, I'll make it a feature request. Either way, it should be fixed, I think. Kind Regards, Daniel Lorch [2002-01-13 15:31:47] [EMAIL PROTECTED] Sorry for the bogus. Would you care to elaborate? I seem to be misunderstanding something. I just don't understand why - with the same configuration - chdir() cares about the UID, and opendir/readdir don't. chdir raises a "SAFE MODE Restriction in effect" whereas readdir() and opendir() let me browse through all directories where I have apache allowed to. Thanks for your help. Kind Regards, Daniel Lorch [2002-01-13 14:50:47] [EMAIL PROTECTED] Like I mentioned on the mailing list, opendir() is the function that would be relevant here. It is analogous to saying that mysql_query() should block you from accessing data in a database as opposed to this access restriction being placed on the mysql_connect() call. If the perms on the dir are such that opendir() can read the directory under safe-mode, then readdir() is going to give you a list of the files in that dir. Whether you can actually open and read those individual files themselves is of course another issue and any such access would be subject to a safe-mode check. But an individual readdir() call does not have any safe-mode implications. 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/15018 -- Edit this bug report at http://bugs.php.net/?id=15018&edit=1
#20725 [Fbk]: $_REQUEST not populated when there is no tmp dir or upload_tmp_dir not writable
ID: 20725
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: Scripting Engine problem
Operating System: BSD/OS 4.2
PHP Version: 4.3.0RC2
New Comment:
I can't replicate either, and I set upload_tmp_dir to something that
doesn't exist. But anyway can you separate the dump of $_POST and
$_REQUEST so we know which one at least exists? And can you explain
what display_startup_errors affect is on this exactly? And does it
matter if upload_tmp_dir is set? Don't see why it would. Anyway,
please do more tests and try to see if you can get it to work :)
Previous Comments:
[2002-12-05 01:08:51] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-latest.zip
I've been unable to replicate this problem using latest CVS of
4.3.0-dev/4.4.0-dev. Please try a later version and report back, there
is nothing in the code to cause the behaviour you've described.
[2002-11-29 08:12:54] [EMAIL PROTECTED]
Stumbled upon this, in a chrooted environment.
No php.ini (so default settings). No /tmp and /var/tmp or make
upload_tmp_dir not writeable for the webserver.
display_errors On
error_reporting 'no value' (E_ALL ^ E_NOTICE)
$_REQUEST/_POST are not populated.
Only when setting display_startup_errors to 'On', one gets a clue, what
is going on.
Example:
output:
array(0){
}
--
Edit this bug report at http://bugs.php.net/?id=20725&edit=1
#20725 [Fbk]: $_REQUEST not populated when there is no tmp dir or upload_tmp_dir not writable
ID: 20725
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: Scripting Engine problem
Operating System: BSD/OS 4.2
PHP Version: 4.3.0RC2
New Comment:
You have:
output:
array(0){
}
This suggests one exists, it's just empty. Which one I wonder...
Previous Comments:
[2002-12-05 03:09:04] [EMAIL PROTECTED]
philip: $_REQUEST and $_POST both don't exist. display_startup_errors
gives you a warning "File upload error - unable to create a temporary
file" so you actually have to upload something for this bug to
trigger.
If upload_tmp_dir isn't set, it tries to use /var/tmp, /tmp or anything
similar.
Using latest 4.3 branch I can't reproduce it either, but this is
another server. The server where I discovered this bug, is in
production, so I won't be able to test it until some odd hours during
the weekend.
[2002-12-05 01:38:24] [EMAIL PROTECTED]
I can't replicate either, and I set upload_tmp_dir to something that
doesn't exist. But anyway can you separate the dump of $_POST and
$_REQUEST so we know which one at least exists? And can you explain
what display_startup_errors affect is on this exactly? And does it
matter if upload_tmp_dir is set? Don't see why it would. Anyway,
please do more tests and try to see if you can get it to work :)
[2002-12-05 01:08:51] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-latest.zip
I've been unable to replicate this problem using latest CVS of
4.3.0-dev/4.4.0-dev. Please try a later version and report back, there
is nothing in the code to cause the behaviour you've described.
[2002-11-29 08:12:54] [EMAIL PROTECTED]
Stumbled upon this, in a chrooted environment.
No php.ini (so default settings). No /tmp and /var/tmp or make
upload_tmp_dir not writeable for the webserver.
display_errors On
error_reporting 'no value' (E_ALL ^ E_NOTICE)
$_REQUEST/_POST are not populated.
Only when setting display_startup_errors to 'On', one gets a clue, what
is going on.
Example:
output:
array(0){
}
--
Edit this bug report at http://bugs.php.net/?id=20725&edit=1
#20723 [Bgs]: include self file
ID: 20723 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: *General Issues Operating System: Red Hat 7.2 PHP Version: 4.2.2 New Comment: I'm not sure what expected behavior should be here but consider using include_once(). On a related note: include 'idonotexist.php'; gives a confusing error these days: Warning: main(idonotexist.php) [function.main]: failed to create stream: No such file or directory in /var/www/include.php on line 3 Warning: main() [function.main]: Failed opening 'idonotexist.php' for inclusion (include_path='.:/usr/local/lib/php') in /var/www/include.php on line 3 A lot of people are going to find themselves here: http://www.php.net/function.main ;) Previous Comments: [2002-12-10 01:25:04] [EMAIL PROTECTED] it is a bug [2002-11-29 06:51:10] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php [2002-11-29 06:50:29] [EMAIL PROTECTED] script.php if you try this you will get: hello hello hello ... and the script will failure -- Edit this bug report at http://bugs.php.net/?id=20723&edit=1
#20895 [Bgs->Ver]: dirname() behaviour changed
ID: 20895
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Bogus
+Status: Verified
Bug Type: Filesystem function related
Operating System: Win 2000Pro SP3
PHP Version: 4.3.0RC2
New Comment:
A couple people just tested this and get the same results as the bug
report with 4.3.0RC2, please explain why this behavior changed.
Previous Comments:
[2002-12-08 23:56:53] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
[2002-12-08 23:35:37] [EMAIL PROTECTED]
Hello.
Up to 4.2.3:
dirname("c:/");
// or
dirname("c:");
// both returned '.'
in 4.3.0 RC2, we got now:
dirname("c:/");
// gives you c:\
dirname("c:");
// gives you c:
(i) I'm not sure that such path shall be used with dirname(). But after
all, why not? And in fact I used it.
(ii) What's the reason for that behaviour change?
(iii) As some of my classes are now broken, will this new behaviour
become the rule for the future?
Apache independent.
Standarts php.ini (recommended) and httpd.conf
Mozilla 1.2
Thanks.
--
Edit this bug report at http://bugs.php.net/?id=20895&edit=1
#20441 [Bgs->Opn]: PHP_AUTH_USER isn't set
ID: 20441 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Open Bug Type: Apache related -Operating System: Redhat Linux 7.1 kernel 2.4.2-2 +Operating System: all PHP Version: 4.3.0-pre2 New Comment: Can someone explain this? Apparently some external auth systems did not populate PHP_AUTH_USER while others did... Was this BC break discussed? It has been documented forever but this behavior changed so please explain it. Previous Comments: [2002-12-11 10:39:14] [EMAIL PROTECTED] I agree with the previous poster that this is a serious bug. When we upgraded to 4.3.0RC2 our development application broke. [2002-11-22 02:40:55] [EMAIL PROTECTED] This is not bogus!! This is a genuine bug. PHP_AUTH_USER was set in 4.2.3 why has the functionality been changed without warning? This will break so many peoples scripts it is not true. This *HAS TO BE FIXED* os that it works as it did before. Please stop trying to pretend that this is not a bug. It is, and a serious one at that. [2002-11-15 09:10:09] [EMAIL PROTECTED] It was fixed to be like it should be since PHP 3. [2002-11-15 03:52:04] [EMAIL PROTECTED] So I should use $_SERVER["REMOTE_USER"] if I use .htaccess and $_SERVER["PHP_AUTH_USER"] when I header the authentication? Why is this behaviour changed without notice? [2002-11-15 03:10:35] [EMAIL PROTECTED] You need to decide if you are using an external auth mechanism or http auth from php. You can't do both. 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/20441 -- Edit this bug report at http://bugs.php.net/?id=20441&edit=1
#20540 [Bgs]: PHP do not read PHP.INI
ID: 20540 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: PHP options/info functions Operating System: Windows XP Pro PHP Version: 4.2.0 New Comment: This really is bogus, please read the findings found at: http://bugs.php.net/bug.php?id=20753 It has to do with your windows settings, not PHP. If another person can confirm the findings in #20753 then this windows feature/bug will be documented as a . Previous Comments: [2002-12-13 02:33:17] [EMAIL PROTECTED] Hi Guys, I'm happy to see I'm not alone, and too much stupid :-) I found 2 workarounds that can work for you (I hope) 1) With Apache : I put php.ini in Apache Directory, I've deleted the one in ../system32/ I don't know why but... it worked... 2) Other solution : I have installed the Php version 4.3 RC0 These 2 solutions worked fine for me, hope this will help you as well Sincerely, Jean-Frederic [2002-12-12 20:01:01] [EMAIL PROTECTED] i am having the exact problem with my php.ini settings under winxp pro w/iis ... the ini_set function does work to fix it but i really dont feel like editing all the configs for things like phpbb, phorm, my own scripts and such itts just oo much of a hassle... any other suggestions would be greatly appreciated. I am confident you guys will find the solution to this bug eventually. thanks Andrew. [2002-12-01 18:56:41] [EMAIL PROTECTED] I've got an identical problem on php 4.2.3 (submitted as a new bug #20753) to make sure it returns to "open" status. [2002-12-01 16:48:20] [EMAIL PROTECTED] Thank you for taking the time to report a problem with PHP. Unfortunately you are not using a current version of PHP -- the problem might already be fixed. Please download a new PHP version from http://www.php.net/downloads.php If you are able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to "Open". Again, thank you for your continued support of PHP. [2002-11-21 16:41:21] [EMAIL PROTECTED] You are using a relatively dated PHP, upgrading to 4.2.3 or better yet stable snapshot (avaliable from http://snaps.php.net) may solve your 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/20540 -- Edit this bug report at http://bugs.php.net/?id=20540&edit=1
#21006 [Bgs]: $_Server variables are not global
ID: 21006 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: IIS related Operating System: win 200 server PHP Version: 4.3.0RC3 New Comment: Some thoughts: a) That error has nothing to do with undefined or "non global" variables. It's a parse error. b) Variables are case sensitive, never write $_Server it's ALWAYS $_SERVER c) A weird character? I really don't think this was ever an error in PHP and has to do with your code only, PHP won't put weird characters in your code. I blame your text editor. Try this test: What text editor do you use to write code? Previous Comments: [2002-12-14 01:49:43] [EMAIL PROTECTED] RC3 seems to have fixed it weird character ahowing up in front of $ [2002-12-14 01:26:40] [EMAIL PROTECTED] On my IIS Server, now running 4.3.0RC3 ( i just installed and tested it, started writing issue with RC2), $_Server variables are not global, they don't work inside functions specifically $agent = $_SERVER["HTTP_USER_AGENT"]; I hear that *nix machines do not have this issue. The following does not work, there is no variable set for the user agent and i get an error. Parse error: parse error, unexpected T_VARIABLE in c:\ inetpub\wwwroot\admin\index.php on line 26 PHP Parse error: parse error, unexpected T_VARIABLE in c:\ inetpub\wwwroot\admin\index.php on line 26 Basically the variable is not set. This does work outside the function however (i coded this to explain issue more simply, originally got help at http://www.webmasterworld.com/forum13/1766.htm which has more specific details, example code and the like) $_SERVER["HTTP_USER_AGENT"]; is global in scope but is not accessable in my installation inside a function. I now use define to pass variable down to my function and avoid any more issues personally. I have a feeling it has to do with my using release candidate 2 but do not wish to test with previous versions of php at this time. This seems like an IIS quirk as the forum moderator seemed not to have this issue and agreed $_SERVER variables are global in scope, as is my understanding from was what i read in the manual. info from my phpinfo() PHP Version 4.3.0RC2 System Windows NT localhost 5.0 build 2195 Build Date Nov 27 2002 21:11:38 Server API CGI/FastCGI register globals is also on for the time being, (seems like this is always asked) -- Edit this bug report at http://bugs.php.net/?id=21006&edit=1
#21116 [Opn]: where do I find optional dlls?
ID: 21116 Updated by: [EMAIL PROTECTED] -Summary: INI file needs updating Reported By: [EMAIL PROTECTED] Status: Open -Bug Type: Documentation problem +Bug Type: PHP options/info functions Operating System: Windows PHP Version: 4.3.0RC3 New Comment: I'm not sure the policy of php.ini and extensions that aren't included in the windows distro (dlls) but regardless this is a php-dev question so am marking it as such. I don't think the php.ini entry should be removed though, I'm sure there are others and they are commented out. Also, this may have to do with PECL extensions being included or not. Btw, you can find this (and many other dlls) here: http://kromann.info/php4.php Changing summary to: "Where do I find optional dlls?" :) Previous Comments: [2002-12-20 11:38:17] [EMAIL PROTECTED] In the ini file there is a php_printer.dll option under extensions. No such dll file exists in the extensions directory. This option just needs to be deleted out of the ini file. -- Edit this bug report at http://bugs.php.net/?id=21116&edit=1
#20441 [Ctl->Csd]: PHP_AUTH_USER isn't set
ID: 20441 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Critical +Status: Closed Bug Type: Apache related Operating System: all -PHP Version: 4.3.0-pre2 +PHP Version: 4.3.0 New Comment: It has been agreed in php-dev to keep the PHP_AUTH_* variables but to disable them when in safe mode. This change was made after 4.3.0-RC4 but will exist in PHP 4.3.0. This is from the PHP 4.3.0 NEWS: Make PHP_AUTH_* variables not available in safe mode under Apache when an external basic auth mechanism is used. (Philip) REMOTE_USER will exist regardless. In the future, a new ini directive such as expose_php_auth_vars may be available. The docs will be updated. Previous Comments: [2002-12-18 15:21:10] [EMAIL PROTECTED] This needs to be fixed before 4.3 goes out. While it is of course important to improve the code and iron out long standing errors, we must not forget that our users rely on the old behaviour. The default behaviour of 4.3 should be the same as in old versions. [2002-12-18 13:29:19] [EMAIL PROTECTED] This problem has just caused me a big headache - a customer has been relying on the fact that both .htaccess and PHP_AUTH_USER have been available in parallel since at least PHP 4. They've asked me to fix their scripts, but it would be a massive rewrite to sort out. I only have two customers who do their own scripting, and 50% of them are bitten by this. I think that 4.3.0 may well annoy lots of people with this. I can see from the documentation of bug #19251 why the change has been made, and I understand that that the manual documents the new behaviour, but I suspect this misbehaviour is widely relied upon, and perhaps we should consider an php.ini switch. The only economic solution I can suggest for my customer in the meanwhile is for me to patch php back to its old behaviour. [2002-12-11 10:58:19] [EMAIL PROTECTED] We fixed a bug, period. Derick [2002-12-11 10:53:53] [EMAIL PROTECTED] Can someone explain this? Apparently some external auth systems did not populate PHP_AUTH_USER while others did... Was this BC break discussed? It has been documented forever but this behavior changed so please explain it. [2002-12-11 10:39:14] [EMAIL PROTECTED] I agree with the previous poster that this is a serious bug. When we upgraded to 4.3.0RC2 our development application broke. 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/20441 -- Edit this bug report at http://bugs.php.net/?id=20441&edit=1
#21138 [NEW]: AUTH_TYPE exists, PHP_AUTH_TYPE does not
From: [EMAIL PROTECTED] Operating system: linux PHP version: 4.3.0RC4 PHP Bug Type: HTTP related Bug description: AUTH_TYPE exists, PHP_AUTH_TYPE does not PHP_AUTH_TYPE has been documented forever yet it doesn't exist. It's also mentioned in various places in the php4 source code but to no avail. However, the variable AUTH_TYPE does exist. -- Edit bug report at http://bugs.php.net/?id=21138&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21138&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21138&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21138&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21138&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21138&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21138&r=support Expected behavior: http://bugs.php.net/fix.php?id=21138&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21138&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21138&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21138&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21138&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21138&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21138&r=isapi
#21145 [Bgs->Opn]: CLI version of PHP always prints HTTP headers.
ID: 21145 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Open Bug Type: Unknown/Other Function Operating System: Linux - Debian Woody PHP Version: 4CVS-2002-12-22 (stable) New Comment: Please explain to the doc team how to document this new behavior in PHP, regarding the CLI/CGI build process. And the various problems (such as this ncurses one) that may/will arise. Previous Comments: [2002-12-22 12:55:46] [EMAIL PROTECTED] I just reconfigured with --enable-cli and recompiled with the same results. It always says cgi in php -v, no matter if I configure it as a CLI or not. [2002-12-22 12:49:55] [EMAIL PROTECTED] Just in case I wasn't clear enough on what HTTP headers where printed, they follow: Content-type: text/html X-Powered-By: PHP/4.3.0-dev [2002-12-22 12:48:08] [EMAIL PROTECTED] try running "php -v" I bet you're using the CGI. Not a bug -> bogus. Derick [2002-12-22 12:46:22] [EMAIL PROTECTED] The CLI version of PHP always prints the headers. This may be related to my configure settings, which follow. './configure' '--enable-bcmath' '--enable-pcntl' '--enable-sysvsem' '--enable-sysvshm' '--enable-sysvmsg' '--enable-tokenizer' '--with-pear' '--with-curl' '--with-mysql' '--with-gettext' '--with-mcrypt' '--with-mhash' '--with-ming' '--with-ncurses=/root/ncurses-5.3' '--with-shmop' '--enable-sockets' -- Edit this bug report at http://bugs.php.net/?id=21145&edit=1
#21159 [NEW]: zend_ini_parser.y:215.4-6: unrecognized escape: `\\0'
From: [EMAIL PROTECTED]
Operating system: linux
PHP version: 4CVS-2002-12-22 (dev)
PHP Bug Type: Scripting Engine problem
Bug description: zend_ini_parser.y:215.4-6: unrecognized escape: `\\0'
During make the following exists. First, the setup:
autoconf : 2.13
bison : (GNU Bison) 1.75
>From the output:
bison -y -p ini_ -v -d /cvs/php4/Zend/zend_ini_parser.y -o
Zend/zend_ini_parser.c
/cvs/php4/Zend/zend_ini_parser.y:215.4-6: unrecognized escape: `\\0'
PHP compiles but maybe this is something to consider. It's the only such
warning I get. One thread did talk a little about this specific error but
nothing came of it afaict. Is this a bison bug?
http://marc.theaimsgroup.com/?l=php-dev&m=103680308111343
Line 215 looks like (aside from a little whitespace change):
| '\0' { $$.value.str.val = strdup(""); $$.value.str.len=0; $$.type =
IS_STRING; }
--
Edit bug report at http://bugs.php.net/?id=21159&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=21159&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=21159&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=21159&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=21159&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=21159&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=21159&r=support
Expected behavior: http://bugs.php.net/fix.php?id=21159&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=21159&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=21159&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=21159&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21159&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=21159&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=21159&r=isapi
#21154 [Bgs->Opn]: $_SERVER[PHP_SELF] empty in cgi
ID: 21154 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Open Bug Type: Other web server Operating System: mac osx PHP Version: 4.3.0RC4 New Comment: Why does CLI have all of these? Why is PHP_SELF empty as opposed to not existing at all? Previous Comments: [2002-12-23 05:25:55] [EMAIL PROTECTED] CGI needs specific environmental variables to be set in order to determine PHP_SELF. Running from the command line does not (usually) have the environment set up as described in the CGI spec, and that is the reason it's missing. If you think about it, it makes sense; how can it determine the relative path to the root of the web server when it is not actually running under a web server? http://www.php.net/manual/en/reserved.variables.php#reserved.variables.globals States: " 'PHP_SELF' The filename of the currently executing script, relative to the document root. For instance, $_SERVER['PHP_SELF'] in a script at the address http://example.com/test.php/foo.bar would be /test.php/foo.bar. If PHP is running as a command-line processor, this variable is not available. " So I'm marking this report as bogus (nothing personal!). [2002-12-22 21:36:14] [EMAIL PROTECTED] I should note that the cgi and cli are both being run by hand from a shell (not exec'd from a webserver). [2002-12-22 21:31:12] [EMAIL PROTECTED] returns: 22:28:26(george@ool-18bced28)[~/Advanced PHP/examples]> php a.php Content-type: text/html X-Powered-By: PHP/4.3.0-dev Array ( [HOME] => /Users/george [SHELL] => /bin/tcsh [USER] => george [LANG] => en [PATH] => /sw/bin:/sw/sbin:/bin:/usr/bin:/Users/george/ bin:/usr/sbin:/opt/GN Upgcc/bin:/opt/GNUxemacs/bin:/usr/local/bin:/usr/local/ sbin:/usr/openwin/bin:/us r/dt/bin:/usr/ccs/bin:/usr/proc/bin:/usr/ucb:/usr/X11R6/ bin:/sw/bin:/sw/sbin:.:/ usr/X11R6/bin [__CF_USER_TEXT_ENCODING] => 0x1F5:0:0 [TERM] => vt100 [PWD] => /Users/george/Advanced PHP/examples [HOSTTYPE] => macintosh [VENDOR] => apple [OSTYPE] => darwin [MACHTYPE] => powerpc [SHLVL] => 1 [LOGNAME] => george [GROUP] => staff [HOST] => ool-18bced28.dyn.optonline.net [HOSTTAG] => maya [Omniti/mobile] [MANPATH] => /usr/share/man:/usr/openwin/share/man:/ usr/man:/usr/local/man:/ opt/SUNWwabi/man:/usr/local/lib/perl5/man:/opt/GNUpgcc/ man:/opt/GNUxemacs/man [INFOPATH] => /sw/share/info:/sw/info:/usr/local/share/ info:/usr/local/lib/i nfo:/usr/local/info:/usr/share/info [PERL5LIB] => /sw/lib/perl5 [EDITOR] => vi [VISUAL] => vi [DISPLAY] => :0.0 [CVS_RSH] => ssh [OPENWINHOME] => /usr/openwin [XFILESEARCHPATH] => /usr/dt/lib/%T/%N%S [XGLHOME] => /opt/SUNWits/Graphics-sw/xgl [LD_LIBRARY_PATH] => /usr/lib:/usr/dt/lib:/usr/openwin/ lib:/usr/ucblib:/usr/ local/lib:. [XILHOME
#21177 [NEW]: cgi shows header output with -q
From: [EMAIL PROTECTED] Operating system: linux PHP version: 4CVS-2002-12-25 (stable) PHP Bug Type: Unknown/Other Function Bug description: cgi shows header output with -q I've been looking for PEBKAC but it doesn't seem to be the case. Here's the commandline output (with some whitespace changes), this is latest checkout of the PHP_4_3 branch and also exists in HEAD: rock:/cvs/a/php4# cat a.php rock:/cvs/a/php4# sapi/cgi/php -v PHP 4.3.0-dev (cgi), Copyright (c) 1997-2002 The PHP Group Zend Engine v1.3.0, Copyright (c) 1998-2002 Zend Technologies rock:/cvs/a/php4# sapi/cgi/php -q a.php Content-type: text/html X-Powered-By: PHP/4.3.0-dev Hello World rock:/cvs/a/php4# sapi/cli/php a.php Hello World rock:/cvs/a/php4# sapi/cgi/php -h Usage: php [-q] [-h] [-s [-v] [-i] [-f ] php [args...] -a Run interactively -C Do not chdir to the script's directory -c | Look for php.ini file in this directory -n No php.ini file will be used -d foo[=bar] Define INI entry foo with value 'bar' -e Generate extended information for debugger/profiler -f Parse . Implies `-q' -h This help -i PHP information -l Syntax check only (lint) -m Show compiled in modules -q Quiet-mode. Suppress HTTP Header output. -s Display colour syntax highlighted source. -v Version number -w Display source with stripped comments and whitespace. -z Load Zend extension . rock:/cvs/a/php4# And now from a PHP 4.2.3 CGI binary: rock:/cvs/a/php4# php4 -v 4.2.3 rock:/cvs/a/php4# php4 a.php X-Powered-By: PHP/4.2.3 Content-type: text/html Hello World rock:/cvs/a/php4# php4 -q a.php Hello World rock:/cvs/a/php4# -- Edit bug report at http://bugs.php.net/?id=21177&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21177&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21177&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21177&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21177&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21177&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21177&r=support Expected behavior: http://bugs.php.net/fix.php?id=21177&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21177&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21177&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21177&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21177&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21177&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21177&r=isapi
#16411 [NoF->Opn]: CGI application misbehaved by not returning a complete set of
ID: 16411 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: No Feedback +Status: Open Bug Type: MSSQL related Operating System: Windows 2000 PHP Version: 4.1.2 New Comment: Looks like feedback exists -> open Previous Comments: [2002-12-24 01:00:03] [EMAIL PROTECTED] No feedback was provided for this bug for over 2 weeks, 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-12-18 06:43:19] [EMAIL PROTECTED] I have the same problem. Platform: PHP different versions, SQL Server 2000 and Windows 2000. I see it a lot when the server is busy, or when two requests are made really fast after another. Really need a solution for this. [2002-12-13 11:25:11] [EMAIL PROTECTED] i'm also experiencing this error with win xp, mssql 2000, and php 4.3.0 rc3. is it a problem with php, or with the mssql libraries? [2002-12-08 10:31:33] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-12-02 19:59:17] [EMAIL PROTECTED] Database connections are all transient. In the original code, I did not close the connections because php would do that at the end of script. But as I was in doubt, I later made a close right before calling the function header() but the same problem happened. I also made another test: in the script I just opened and immediately right after colsed it. The same bug happened. When I removed that tiny chunk of code, every thing worked just fine. 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/16411 -- Edit this bug report at http://bugs.php.net/?id=16411&edit=1
#21182 [Opn->Ctl]: range() change value of string argument
ID: 21182
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Critical
Bug Type: Arrays related
Operating System: FreeBSD
-PHP Version: 4.2.1
+PHP Version: 4.3.0-dev
New Comment:
Confirmed in 4.3.0. If they are strings, $a turns into 40! If $a is
integer, it stays 20 as expected. Btw if we have '$a = "$a = "24"; $b
= "140";' then $a turns into 04. There seems to be sort of a pattern
but it's kinda weird :) The second argument ($b) does not get modified
and the following behavoir exists:
range(20, "30"); // okay in 4.3.0-dev
range("20", "30"); // not okay in 4.3.0-dev
And as a holiday bonus, in HEAD either use results in a segfault with
the following backtrace for CLI:
rock:/tmp# php range.php
a1: 20
FATAL: erealloc(): Unable to allocate 1515870815 bytes
Segmentation fault (core dumped)
#0 0x400b9c51 in kill () from /lib/libc.so.6
#1 0x0815f28c in _erealloc (ptr=0x8360cdc, size=1515870815,
allow_failure=0, __zend_filename=0x81b8100
"/cvs/php4/Zend/zend_operators.c", __zend_lineno=1013,
__zend_orig_filename=0x0, __zend_orig_lineno=0)
at /cvs/php4/Zend/zend_alloc.c:298
#2 0x0816fb47 in add_string_to_string (result=0xbfffd5f4,
op1=0xbfffd5f4, op2=0xbfffd748) at
/cvs/php4/Zend/zend_operators.c:1013
#3 0x0818766b in execute (op_array=0x83677c4) at
/cvs/php4/Zend/zend_execute.c:1463
#4 0x08174924 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /cvs/php4/Zend/zend.c:931
#5 0x08139553 in php_execute_script (primary_file=0xba2c) at
/cvs/php4/main/main.c:1693
#6 0x0818e817 in main (argc=2, argv=0xbaa4) at
/cvs/php4/sapi/cli/php_cli.c:744
range.php looks like this:
Previous Comments:
[2002-12-25 10:43:54] [EMAIL PROTECTED]
I searched range's source (php4/ext/standard/array.c)
It seems that problem is in string
for (; *low <= *high; (*low) += (unsigned int)lstep) {
add_next_index_stringl(return_value, low, 1, 1);
}
+= increments not pointer, but value, to which low points.
Therefore for(;;) iterates values between first characters of high and
low strings.
[2002-12-25 10:02:09] [EMAIL PROTECTED]
I have the following code:
For some reason it display "40".
I know that I have to write
$result = range((int)$a, (int)$b);
But why range() change value of argument?
--
Edit this bug report at http://bugs.php.net/?id=21182&edit=1
#21198 [Opn->Fbk]: mysql_num_rows() not valid
ID: 21198
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Feedback
Bug Type: MySQL related
Operating System: Linux
PHP Version: 4.2.3
New Comment:
Rewrite this:
$result = mysql_query($query);
Like this:
if (!$result = mysql_query($query)) {
print "Could not run query ($query) : " . mysql_error();
exit;
}
If that doesn't output something, try and rewrite your query like so:
$query = "SELECT count(*)
FROM books
WHERE $searchtype
LIKE '%$searchterm%'";
And get the count by:
if ($result = mysql_query($query)) {
print mysql_result($result,0);
exit;
}
Anyway this looks like a support question but just in case try the
above. I'm guessing the query is invalid, like, $searchtype is not
defined correctly or something. In which case you'd be giving
mysql_num_rows() a invalid mysql result resource because mysql_query()
retured false on the bogus query. And BTW, you want && not ||.
Error handling is your friend. Like for example, make sure $searchtype
is a column you want to use. Anyway, when in doubt, print stuff.
Previous Comments:
[2002-12-26 09:45:49] [EMAIL PROTECTED]
I have a very simple PHP script, that searches a small mysql database
for a result. And the result that I keep receiving pertaining to the
mysql_num_rows() function is listed below.
Warning: mysql_num_rows(): supplied argument is not a valid MySQL
result resource in /bookorama/results.php on line 29
Number of books found:
Here is some of the PHP script.
Number of books found: ".$num_results."";
for($i=0; $i < $num_results; $i++) {
$row = mysql_fetch_array($result);
echo "".($i + 1).". Title: ";
echo htmlspecialchars(stripslashes($row["title"]));
echo "Author: ";
echo htmlspecialchars(stripslashes($row["author"]));
echo "ISBN: ";
echo htmlspecialchars(stripslashes($row["isbn"]));
echo "Price: ";
echo htmlspecialchars(stripslashes($row["price"]));
echo "";
}
?>
--
Edit this bug report at http://bugs.php.net/?id=21198&edit=1
#21198 [Fbk->Bgs]: mysql_num_rows() not valid
ID: 21198
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Bogus
Bug Type: MySQL related
Operating System: Linux
PHP Version: 4.2.3
New Comment:
You can't have spaces in column names, your query is bogus. And btw I
just noticed your typo:
$searchtype = addslashes($searchtype);
$searchtype = addslashes($searchterm); // notice the problem?
Anyway, this is bogus.
Previous Comments:
[2002-12-26 10:55:15] [EMAIL PROTECTED]
Okay, I did the first rewrite and I got the below output.
Could not run query (select * from books where Java 2 like '%Java 2%')
: You have an error in your SQL syntax near '2 like '%Java 2%'' at line
1
Then I tried the second rewrite and I got the one below.
Warning: mysql_result(): supplied argument is not a valid MySQL result
resource in /bookorama/results.php on line 32
[2002-12-26 10:39:28] [EMAIL PROTECTED]
Rewrite this:
$result = mysql_query($query);
Like this:
if (!$result = mysql_query($query)) {
print "Could not run query ($query) : " . mysql_error();
exit;
}
If that doesn't output something, try and rewrite your query like so:
$query = "SELECT count(*)
FROM books
WHERE $searchtype
LIKE '%$searchterm%'";
And get the count by:
if ($result = mysql_query($query)) {
print mysql_result($result,0);
exit;
}
Anyway this looks like a support question but just in case try the
above. I'm guessing the query is invalid, like, $searchtype is not
defined correctly or something. In which case you'd be giving
mysql_num_rows() a invalid mysql result resource because mysql_query()
retured false on the bogus query. And BTW, you want && not ||.
Error handling is your friend. Like for example, make sure $searchtype
is a column you want to use. Anyway, when in doubt, print stuff.
[2002-12-26 09:45:49] [EMAIL PROTECTED]
I have a very simple PHP script, that searches a small mysql database
for a result. And the result that I keep receiving pertaining to the
mysql_num_rows() function is listed below.
Warning: mysql_num_rows(): supplied argument is not a valid MySQL
result resource in /bookorama/results.php on line 29
Number of books found:
Here is some of the PHP script.
Number of books found: ".$num_results."";
for($i=0; $i < $num_results; $i++) {
$row = mysql_fetch_array($result);
echo "".($i + 1).". Title: ";
echo htmlspecialchars(stripslashes($row["title"]));
echo "Author: ";
echo htmlspecialchars(stripslashes($row["author"]));
echo "ISBN: ";
echo htmlspecialchars(stripslashes($row["isbn"]));
echo "Price: ";
echo htmlspecialchars(stripslashes($row["price"]));
echo "";
}
?>
--
Edit this bug report at http://bugs.php.net/?id=21198&edit=1
#21201 [Opn->Dup]: FDF Extension makes PHP crash
ID: 21201 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Duplicate Bug Type: FDF related Operating System: Windows 98 SE PHP Version: 4.3.0RC4 New Comment: Duplicate of #14877 http://bugs.php.net/14877 Previous Comments: [2002-12-26 11:19:36] [EMAIL PROTECTED] PHP crash if there is fdf extension loaded. Commenting the extension in php.ini, it works. List of extensions: extension=php_cpdf.dll extension=php_curl.dll extension=php_dbg.dll extension=php_dbx.dll extension=php_domxml.dll extension=php_exif.dll ;extension=php_fdf.dll extension=php_gd.dll extension=php_java.dll extension=php_mhash.dll extension=php_mime_magic.dll extension=php_openssl.dll extension=php_pdf.dll extension=php_sockets.dll extension=php_w32api.dll extension=php_xmlrpc.dll extension=php_xslt.dll extension=php_zlib.dll Dr. Watson dump: PHP ha provocato un errore di pagina non valida nel modulo PHP_FDF.DLL in 0177:01791220. Registri: EAX=0091 CS=0177 EIP=01791220 EFLGS=00010246 EBX=007627f0 SS=017f ESP=0063fbd4 EBP=100ad170 ECX=007d4660 DS=017f ESI=007d1a60 FS=62df EDX= ES=017f EDI=1012b460 GS= Byte all'indirizzo CS:EIP: c7 00 00 00 00 00 33 c0 c3 90 90 90 90 90 90 90 Immagine dello stack: 100ad18d 0001 0015 007627f0 007d1ab0 100aa422 007d1a60 007627f0 0063fc74 007627f0 0076384c 0063fc6c 100b6534 1012b460 100ad170 007627f0 -- Edit this bug report at http://bugs.php.net/?id=21201&edit=1
#21198 [Bgs]: mysql_num_rows() not valid
ID: 21198
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: MySQL related
Operating System: Linux
PHP Version: 4.2.3
New Comment:
Please ignore everything I said and go here:
http://www.php.net/support
This is not a bug in PHP.
Previous Comments:
[2002-12-26 12:07:08] [EMAIL PROTECTED]
This is what my code looks like now:
Number of books found: ".$num_results."";
for($i=0; $i < $num_results; $i++) {
$row = mysql_fetch_array($result);
echo "".($i + 1).". Title: ";
echo htmlspecialchars(stripslashes($row["title"]));
echo "Author: ";
echo htmlspecialchars(stripslashes($row["author"]));
echo "ISBN: ";
echo htmlspecialchars(stripslashes($row["isbn"]));
echo "Price: ";
echo htmlspecialchars(stripslashes($row["price"]));
echo "";
}
?>
and this is the response I get:
Warning: mysql_result(): supplied argument is not a valid MySQL result
resource in /bookorama/results.php on line 29
[2002-12-26 11:49:50] [EMAIL PROTECTED]
You can't have spaces in column names, your query is bogus. And btw I
just noticed your typo:
$searchtype = addslashes($searchtype);
$searchtype = addslashes($searchterm); // notice the problem?
Anyway, this is bogus.
[2002-12-26 10:55:15] [EMAIL PROTECTED]
Okay, I did the first rewrite and I got the below output.
Could not run query (select * from books where Java 2 like '%Java 2%')
: You have an error in your SQL syntax near '2 like '%Java 2%'' at line
1
Then I tried the second rewrite and I got the one below.
Warning: mysql_result(): supplied argument is not a valid MySQL result
resource in /bookorama/results.php on line 32
[2002-12-26 10:39:28] [EMAIL PROTECTED]
Rewrite this:
$result = mysql_query($query);
Like this:
if (!$result = mysql_query($query)) {
print "Could not run query ($query) : " . mysql_error();
exit;
}
If that doesn't output something, try and rewrite your query like so:
$query = "SELECT count(*)
FROM books
WHERE $searchtype
LIKE '%$searchterm%'";
And get the count by:
if ($result = mysql_query($query)) {
print mysql_result($result,0);
exit;
}
Anyway this looks like a support question but just in case try the
above. I'm guessing the query is invalid, like, $searchtype is not
defined correctly or something. In which case you'd be giving
mysql_num_rows() a invalid mysql result resource because mysql_query()
retured false on the bogus query. And BTW, you want && not ||.
Error handling is your friend. Like for example, make sure $searchtype
is a column you want to use. Anyway, when in doubt, print stuff.
[2002-12-26 09:45:49] [EMAIL PROTECTED]
I have a very simple PHP script, that searches a small mysql database
for a result. And the result that I keep receiving pertaining to the
mysql_num_rows() function is listed below.
Warning: mysql_num_rows(): supplied argument is not a valid MySQL
result resource in /bookorama/results.php on line 29
Number of books found:
Here is some of the PHP script.
Number of books found: ".$num_results."";
for($i=0; $i < $num_results; $i++) {
$row = mysql_fetch_array($result);
echo "".($i + 1).". Title: ";
echo htmlspecialchars(stripslashes($row["title"]));
echo "Author: ";
echo htmlspecialchars(stripslashes($row["author"]));
echo "ISBN: ";
echo htmlspecialchars(stripslashes($row["isbn"]));
echo "Price: ";
echo htmlspecialchars(stripslashes($row["price"]));
echo "";
}
?>
--
Edit this bug report at http://bugs.php.net/?id=21198&edit=1
#21214 [Bgs]: ldap_connect returns LDAP link identifier on error.
ID: 21214
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: LDAP related
Operating System: RedHat 8
PHP Version: 4.3.0
New Comment:
See: http://bugs.php.net/bug.php?id=15637
Previous Comments:
[2002-12-27 11:04:51] [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. Because of this, we hope you add your comments
to the existing bug instead.
Thank you for your interest in PHP.
[2002-12-27 10:58:38] [EMAIL PROTECTED]
ldap_connect returns LDAP link identifier on error
The source:
// LDAP variables
$ldaphost = "nonexistendserver"; // your ldap servers
$ldapport = 389; // your ldap server's port number
// Connecting to LDAP
$ldapconn = ldap_connect( $ldaphost, $ldapport )
or die( "Could not connect to {$ldaphost}" );
echo $ldapconn;
returns sth like this:
Resource id #11
Any ideas???
--
Edit this bug report at http://bugs.php.net/?id=21214&edit=1
#21219 [Bgs]: LS_COLOR destruct phpinfo() Output
ID: 21219 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: *General Issues Operating System: Linux Suse 8.0 PHP Version: 4.3.0 New Comment: Btw, this is related to the open feature request here: http://bugs.php.net/bug.php?id=5301 Previous Comments: [2002-12-27 14:14:26] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php word wrapping enviroment variables may corrupt them, therefor they are displayed as is. [2002-12-27 14:13:02] [EMAIL PROTECTED] If I open my file phpinfo.php for my phpinfos (phpinfo()) in Enviroment->LS_COLORS and PHP Variables->LS_COLORS it doesn't wordwrap the line, so it creates a very large cell with this value: no=00:fi=00:di=01;34:ln=01:pi=40;33:so=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:ex=01;31:*.cmd=01;32:*.exe=01;32:*.com=01;32:*.bat=01;32:*.btm=01;32:*.dll=01;32:*.tar=00;31:*.tbz=00;31:*.tgz=00;31:*.rpm=00;31:*.arj=00;31:*.taz=00;31:*.lzh=00;31:*.zip=00;31:*.z=00;31:*.Z=00;31:*.gz=00;31:*.bz2=00;31:*.tbz2=00;31:*.png=01;35:*.bmp=01;35:*.gif=01;35:*.jpg=01;35:*.jpeg=01;35:*.pcx=01;35:*.ppm=01;35:*.tif=01;35:*.xbm=01;35:*.xpm=01;35:*.wav=00;32:*.mp3=00;32:*.au=00;32:*.aiff=00;32:*.mid=00;32:*.voc=00;32: Maybe this is only depend on the Browser (I'm using Opera 6.03) -- Edit this bug report at http://bugs.php.net/?id=21219&edit=1
#21218 [Opn]: should be able to set a list of hidden environment vars
ID: 21218 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Feature/Change Request Operating System: Red Hat Linux 7.3 PHP Version: 4.3.0 New Comment: On a related note fwiw, even if E is removed from the variables_order directive (so that $_ENV will not exist), one can still use getenv() to access the variables. Previous Comments: [2002-12-27 13:55:14] [EMAIL PROTECTED] Currently, safe_mode_protected_env_vars can be set to disallow setting of specific environment variables. I propose an option to set a list of environment variables (possibly with wildcards, such as SUDO_*) that are completely hidden from PHP pages, and do not show up in phpinfo() (Since you can disable environment variables, but to hide _ENV globals, you would have to disable variable listing completely, which is not always good enough). Showing certain environment settings are a huge security risk, such as SUDO_UID and SUDO_USER if apache was started using sudo, as well as PWD, PATH, SSH_CONNECTION, etc. Disabling phpinfo() is not always a possibility, since it gives a lot of useful information to users. -- Edit this bug report at http://bugs.php.net/?id=21218&edit=1
#21222 [Bgs]: problem with dirname
ID: 21222
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: Directory function related
Operating System: Win2k
PHP Version: 4.3.0
New Comment:
See also:
http://bugs.php.net/bug.php?id=20895
Maybe someone with a clue (unlike me) can document this.
Previous Comments:
[2002-12-27 15:49:00] [EMAIL PROTECTED]
No, the trailing / the docs talk about are cases where you actually
have a trailing / in the source path. eg. /some/path/
It does not mean that the trailing path of the returned string will be
stripped.
[2002-12-27 15:46:26] [EMAIL PROTECTED]
That reasoning doesn't quite go along with what the documentation says,
IMHO:
(quoted from http://www.php.net/dirname)
"[...]Essentially, this means that if there are no slashes in path , a
dot ('.') is returned, indicating the current directory. Otherwise, the
returned string is path with any trailing /component removed.[...]"
So for the input '/test.php', the first case (no slashes in path)
obviously doesn't apply, since there is a slash contained in the path
in question.
Now, the second case states that the returned string is the path
('/test.php') with any trailing /component (in this case '/test.php')
removed, i.e. simply ''.
So there seems to be some kind of contradiction between the manual and
what you said, could your elaborate on that, please? Apologies if I'm
missing the point,
Michael
PS: Even if the behaviour was changed to return '/' instead of an empty
string, the transformation of '/' to the default directory separator
should still be officially documented (and not in the user comments).
[2002-12-27 15:27:42] [EMAIL PROTECTED]
Your expectation is simply wrong. dirname() is documented to return
the directory component of a pathname you feed it. You fed it
/test.php and it gave you back / (or the Windows equivalent thereof) as
expected.`
[2002-12-27 15:24:46] [EMAIL PROTECTED]
Hi there,
';
echo '"' . dirname($_SERVER['REQUEST_URI']) . '"';
?>
produces following output...
/test.php
"\"
Instead of the output above, i expected
/test.php
""
Can someone confirm this?
Daniel
--
Edit this bug report at http://bugs.php.net/?id=21222&edit=1
#18288 [NoF->Fbk]: browscap.ini and get_browser()
ID: 18288 Updated by: [EMAIL PROTECTED] -Summary: Browscap.ini Reported By: [EMAIL PROTECTED] -Status: No Feedback +Status: Feedback Bug Type: Scripting Engine problem Operating System: * -PHP Version: 4.3.0-dev +PHP Version: 4.3.0 New Comment: Can you try this again please? It should work better now and please get an up-to-date browscap.ini at: http://www.garykeith.com/browsers/downloads.asp The one at cyscape is outdated by about two years. Previous Comments: [2002-09-11 11:35:37] [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. [2002-07-26 06:22:52] [EMAIL PROTECTED] Are you sure it's not the browscap.ini file? Anyway, this thing has not worked very well for a long time.. [2002-07-26 02:49:08] [EMAIL PROTECTED] The problem is that when I use the browsecap function, i am supposed to get a bunch of information back. I get stuff that tells me I am using netscape 4.0 and I am running IE 6. If this is working correctly, what good is the browse cap function? [2002-07-25 23:43:04] [EMAIL PROTECTED] Thats the environment variables that your browser sends. Saying that its Mozilla not a PHP bug. Bogusing. [2002-07-15 13:19:34] [EMAIL PROTECTED] Broswecap.ini is not working correctly for me. When I use it I get this for a response: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; Q312461) browser_name_pattern: Mozilla/4\.0.* parent: Netscape 4.0 browser: Netscape version: 4.0 majorver: #4 minorver: #0 frames: 1 tables: 1 cookies: 1 backgroundsounds: vbscript: javascript: 1 javaapplets: 1 activexcontrols: beta: You can see that I am using IE 6 and it is telling me I am using netscape. Do you know what the problem is? 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/18288 -- Edit this bug report at http://bugs.php.net/?id=18288&edit=1
#21007 [Opn]: html_errors off text-only output in phpinfo
ID: 21007 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open -Bug Type: Documentation problem +Bug Type: PHP options/info functions Operating System: all -PHP Version: 4.3.0RC3 +PHP Version: 4.3.0 New Comment: Please explain why this is intended behavior, it does not make sense to me. html_errors is for html_errors, it's documented as such in php.ini: ; Disable the inclusion of HTML tags in error messages. ;html_errors = Off This says nothing about phpinfo() and IMHO it shouldn't affect it at all. The patch that resulted in this change is here: * add phpinfo() support for CLI. http://cvs.php.net/diff.php/php4/ext/standard/info.c?r1=1.193&r2=1.194 Why is html_errors being used in this way? When html_errors = off, errors remain readable when viewing in a browser but this textual version of phpinfo() == complete fubar in the browser (yes, one can use ). One might turn html_errors off, for example, to use error_prepend_string/error_append_string in some way. Or they just don't want html in the errors... I don't see how this has anything to do with phpinfo() output. Why doesn't that patch instead check if sapi = cli? A person shouldn't be forced to have this textual phpinfo() if they decide to not include html in php generated errors. Please explain. phpinfo() is not an error! :) Previous Comments: [2002-12-14 15:17:42] [EMAIL PROTECTED] Where? Put the information in this bug report. [2002-12-14 13:39:31] [EMAIL PROTECTED] I've submitted a note to document this behavior in the PHP Manual. [2002-12-14 06:31:19] [EMAIL PROTECTED] If this is intended behaviour, this seems to be a doc problem, since I can't find anything about in the docs. Regards Friedhelm Betz [2002-12-14 06:19:32] [EMAIL PROTECTED] It's indeed intended like this (and I already forgave your typo :). Derick [2002-12-14 06:16:29] [EMAIL PROTECTED] Sorry a misleading typo, but the script should be: or php.ini html_errors=off Is it intended behaviour with this settings that phpinfo() produces text-only output no html-formated output? Sorry if my first post wasn't clear enough. BTW, I wasn'able to find anything in the docs, that setting html_errors off causes phpinfo() to display text-only output. Regards Friedhelm Betz 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/21007 -- Edit this bug report at http://bugs.php.net/?id=21007&edit=1
