#24505 [Opn->Asn]: fopen works incorrect with URL
ID: 24505
Updated by: [EMAIL PROTECTED]
Reported By: firewolf at pochtampt dot ru
-Status: Open
+Status: Assigned
Bug Type: Feature/Change Request
Operating System: FreeBSD-4.8
PHP Version: 4.3.3RC1
-Assigned To:
+Assigned To: wez
New Comment:
We won't be overloading fopen() to handle partial fetches.
However, we are looking at adding some kind of http_request() function
that can include this kind of feature.
Previous Comments:
[2003-07-05 00:23:11] firewolf at pochtampt dot ru
Description:
function fopen(),
when I open http://somesite/somefile
I can't use reget, because server response:
HTTP/1.0 206 Partial content... and php log error.
Its possible when I make content:
$opts = array('http'=>array('user_agent'
=> "USER_AGET NAME\r\nRange: bytes=2000-\r\n"));
$context = stream_context_create($opts);
$fl = fopen("$url","r",false,$context);
Reproduce code:
---
php-4.3.3RC1/ext/standard/http_fopen_wrapper.c.orig:
...
line 300:
switch(response_code) {
case 200:
case 302:
case 301:
reqok = 1;
break;
case 403:
Expected result:
php-4.3.3RC1/ext/standard/http_fopen_wrapper.c.orig:
...
line 300:
switch(response_code) {
case 200:
case 206:
case 302:
case 301:
reqok = 1;
break;
case 403:
--
Edit this bug report at http://bugs.php.net/?id=24505&edit=1
#24503 [Opn->Fbk]: writing newlines and multiline comments produces strange results
ID: 24503
Updated by: [EMAIL PROTECTED]
Reported By: troublegum at woltlab dot de
-Status: Open
+Status: Feedback
Bug Type: Filesystem function related
Operating System: Windows 2000 Professional
PHP Version: 5CVS-2003-07-04 (dev)
New Comment:
try fopen("file.php", "wb") instead.
Previous Comments:
[2003-07-04 17:52:02] troublegum at woltlab dot de
Description:
OS: Windows 2000 Professional
Server: Apache 1.3.27
PHP: Version 5.0.0b2-dev (cvs snapshot 07-04-2003) as apache module
I wanted to create .php files dynamically.
I tested the following test-script:
Reproduce code:
---
$val) {
fwrite($fp, "\$var_".$key." = \"".addcslashes($val,"$\"\\")."\";\n");
}
fwrite($fp, "\n?>");
// close file and show results
fclose($fp);
echo "file written\n";
show_source("./file.php");
?>
Expected result:
The expected content of the file "./file.php" should be the following:
Actual result:
--
Instead, the content which is written to "./file.php" is the
following:
So it is not surprising that show_source for this file results in
Warning: Unterminated comment starting line 2 in
c:\dev\htdocs\php5\fw.php on line 21
--
Edit this bug report at http://bugs.php.net/?id=24503&edit=1
#22563 [Com]: The specified CGI application misbehaved by not returning a complete set of HTT
ID: 22563
Comment by: johan at onsvala_dot_mine dot nu
Reported By: frankielam at ucr dot com dot hk
Status: No Feedback
Bug Type: CGI related
Operating System: Windows 2000
PHP Version: 4.3.1
New Comment:
I get
"CGI Error
The specified CGI application misbehaved by not returning a complete
set of HTTP headers."
I run PHP as CGI on Windows 2003 Server Web Edition. Same error occurs
on W2K, but not as often. I have a frameset consisting of about 10
different frames, of which about 6-7 loads PHP-pages. When refreshing
the page I get the above mentioned error in one (any) of the
PHP-containing frames at least 1 time out of 50, sometimes more. MS
says this error occurs when the PHP-process ends prematurely, so the
question is - why?
[EMAIL PROTECTED]
Previous Comments:
[2003-03-10 20:39:38] [EMAIL PROTECTED]
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.
[2003-03-05 22:41:43] [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
[2003-03-05 21:50:55] frankielam at ucr dot com dot hk
I find the CGI error occurs intermittently with the php script below(a
simple script that
do nothing but keeps refreshing itself with a different value of
parameter passed into it as GET, REMEMBER to open serveral instances
to
run it.)
Teh message it returns is:
"CGI Error
The specified CGI application misbehaved by not returning a complete
set of HTTP headers. The headers it did return are:"
doit.php
8<---
testing";
if (isset($_GET["times"]))
$times = ($_GET["times"]) + 1;
else
$times = 0;
//SEE??? even i comment the statement out, infamous cgi error occurs,
STILL!
//$conn = mssql_connect('127.0.0.1', 'sa', '') or die("couldn't
connect");
echo "";
echo "Trying CGI";
echo "$times";
//header("doit.php");
?>
8<---
My config.:
Windows 2000 Advanced Server with SP3
PHP 4.3.1 / 4.2.3 (both tested to have CGI problem)
P3-1G with 128MB RAM
--
Edit this bug report at http://bugs.php.net/?id=22563&edit=1
#24503 [Fbk->Opn]: writing newlines and multiline comments produces strange results
ID: 24503
User updated by: troublegum at woltlab dot de
Reported By: troublegum at woltlab dot de
-Status: Feedback
+Status: Open
Bug Type: Filesystem function related
Operating System: Windows 2000 Professional
PHP Version: 5CVS-2003-07-04 (dev)
New Comment:
Well, this works for me now. Thank you.
I found this in the fopen manual entry. It was recently added, wasn't
it?
> It is strongly recommended that you always use the 'b'
> flag when opening files with fopen().
Previous Comments:
[2003-07-05 03:27:41] [EMAIL PROTECTED]
try fopen("file.php", "wb") instead.
[2003-07-04 17:52:02] troublegum at woltlab dot de
Description:
OS: Windows 2000 Professional
Server: Apache 1.3.27
PHP: Version 5.0.0b2-dev (cvs snapshot 07-04-2003) as apache module
I wanted to create .php files dynamically.
I tested the following test-script:
Reproduce code:
---
$val) {
fwrite($fp, "\$var_".$key." = \"".addcslashes($val,"$\"\\")."\";\n");
}
fwrite($fp, "\n?>");
// close file and show results
fclose($fp);
echo "file written\n";
show_source("./file.php");
?>
Expected result:
The expected content of the file "./file.php" should be the following:
Actual result:
--
Instead, the content which is written to "./file.php" is the
following:
So it is not surprising that show_source for this file results in
Warning: Unterminated comment starting line 2 in
c:\dev\htdocs\php5\fw.php on line 21
--
Edit this bug report at http://bugs.php.net/?id=24503&edit=1
#17079 [Com]: setlocale changes the internal representation of floats
ID: 17079
Comment by: dMNz at one dot lt
Reported By: jonathan at tricolon dot com
Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Red Hat Linux 7.1
PHP Version: 4.3.0 RC2
Assigned To: hholzgra
New Comment:
am pabandymuj..
Previous Comments:
[2003-03-24 10:18:13] [EMAIL PROTECTED]
Related discussion:
http://news.php.net/article.php?group=php.dev&article=95211
[2003-01-02 13:58:52] php at zeguigui dot com
I switched to PHP 4.3 (in dev only) and I saw this change in locale
handling. It is not OS dependant as I have the problem with Windows
XP.
In PHP < 4.3.0 I have a MySQL database with floats. To handle those
floats I had to make some convertions (with str_replace) as results
were not locale dependant (I use fr_FR). For instance if I had 1.234
stored in db, $row = mysql mysql_fetch_row($handle) would return in
$row[0] the value "1.234" and $row[0] * 100 would return 100 whereas of
123,4 (if outputed).
In PHP = 4.3.0 I do not need those convertion routines anymore (it was
a workaround in my opinion).
So starting with PHP 4.3:
$a = 1.234 ==> OK whatever locale is
$b = "1.234" ==> OK whatever locale is
$c = "1,234" ==> NOT OK whatever locale is
If I have some user inputs I have to convert from locale representation
to number representation before processing them... it would be great to
have a function that do the job for us (didn't find one, sorry!)... but
maybe that's not the good place to ask for this!
[2003-01-02 10:13:59] martin at mermaidconsulting dot com
I also ran across this problem and have been messing with it for like 3
days before i finally ran across this post.
If you do not consider it a bug I would recommend you at least include
it in the documentation and make it very clear that you cannot perform
calculations using thousands-seperators based on the locale settings.
If you have a look at the following sample you can see that user-inputs
will get totally messed up in case they use thousand-seperators.
";
//
displays the monetary decimal point used for the locale
echo "mon_thousands_sep: {$locale_info["mon_thousands_sep"]}";
//
displays the monetary thousands seperator used for the locale
echo "decimal_point: {$locale_info["decimal_point"]}"; //
displays the
decimal point used for the locale
echo "thousands_sep: {$locale_info["thousands_sep"]}"; //
displays the
thousands seperator used for the locale
// defines 2 variables that should be 100 and 75
$a = "1,000,000";
$b = "750,000";
print "A = $a";
print "B = $b";
// performing a simple calculation that illustrates how PHP handles
the
numbers
print "A * 1 = " . ($a*1) . "";
print "B * 1 = " . ($b*1) . "";
?>
Imho there is no point in having locale settings for currencies and
numeric values if you cannot use it for doing calculations.
Thanks
/Martin
[2002-12-16 19:45:14] [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
If you switch to a locale where the float separator is ',' then when it
comes to output the data back to the user the float decimal point will
be depedant on the specified locale. Internally however it'll always be
'.'.
[2002-12-16 08:56:08] jonathan at tricolon dot com
> You should not use ',' to represent floats
> ALWAYS use '.' regardless of locale.
This is exactly the problem. When the locale is changed to Dutch the
internal representation of floats is changed. The separator used is
changed to ','. This behaviour is incorrect and should be fixed. Check
my initial and second post for a detailed description.
Thanks,
Jonathan
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/17079
--
Edit this bug report at http://bugs.php.net/?id=17079&edit=1
#24503 [Opn->Csd]: writing newlines and multiline comments produces strange results
ID: 24503
Updated by: [EMAIL PROTECTED]
Reported By: troublegum at woltlab dot de
-Status: Open
+Status: Closed
Bug Type: Filesystem function related
Operating System: Windows 2000 Professional
PHP Version: 5CVS-2003-07-04 (dev)
New Comment:
Not really a bug in PHP, but a text-mode translation issue.
Yes, that comment was recently added to the manual pages.
Previous Comments:
[2003-07-05 06:11:49] troublegum at woltlab dot de
Well, this works for me now. Thank you.
I found this in the fopen manual entry. It was recently added, wasn't
it?
> It is strongly recommended that you always use the 'b'
> flag when opening files with fopen().
[2003-07-05 03:27:41] [EMAIL PROTECTED]
try fopen("file.php", "wb") instead.
[2003-07-04 17:52:02] troublegum at woltlab dot de
Description:
OS: Windows 2000 Professional
Server: Apache 1.3.27
PHP: Version 5.0.0b2-dev (cvs snapshot 07-04-2003) as apache module
I wanted to create .php files dynamically.
I tested the following test-script:
Reproduce code:
---
$val) {
fwrite($fp, "\$var_".$key." = \"".addcslashes($val,"$\"\\")."\";\n");
}
fwrite($fp, "\n?>");
// close file and show results
fclose($fp);
echo "file written\n";
show_source("./file.php");
?>
Expected result:
The expected content of the file "./file.php" should be the following:
Actual result:
--
Instead, the content which is written to "./file.php" is the
following:
So it is not surprising that show_source for this file results in
Warning: Unterminated comment starting line 2 in
c:\dev\htdocs\php5\fw.php on line 21
--
Edit this bug report at http://bugs.php.net/?id=24503&edit=1
#24495 [Opn->Bgs]: stream_socket_accept() timeout
ID: 24495 Updated by: [EMAIL PROTECTED] Reported By: fiderallalla at fiderallalla dot de -Status: Open +Status: Bogus Bug Type: Sockets related Operating System: suse linux 8.1 PHP Version: 5.0.0b1 (beta1) New Comment: 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 Blegh. Previous Comments: [2003-07-04 08:22:54] fiderallalla at fiderallalla dot de Description: Hi, in my opinion, the timeout for stream_socket_accept() should be handled the same way as in other functions (f.e. set_time_limit). That means, that a timeout of: 5 - would result in a timout of 5 seconds, 0 - would disable a timeout. In the moment we have to give a timeout of -1 to have no timeout. If we give a timeout of 0 - we have a timeout of 0 seconds (Where's the sense??). There could be an additional explanation of the timeout-feature in the documentation of this function as it is done at the documentation of set_time_limit(). Best regards, Hans Kuhlen -- Edit this bug report at http://bugs.php.net/?id=24495&edit=1
#24436 [Opn->Csd]: isset() and empty() produce errors with non-existent variables in classes
ID: 24436
Updated by: [EMAIL PROTECTED]
Reported By: Nico dot Laus dot 2002 at gmx dot de
-Status: Open
+Status: Closed
Bug Type: Zend Engine 2 problem
Operating System: WinXP SP1
PHP Version: 5CVS-2003-07-01 (dev)
New Comment:
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.
Previous Comments:
[2003-07-01 09:52:36] [EMAIL PROTECTED]
FYI: It wasn't a setting, it was me messing with the code ;-)
[2003-07-01 09:51:29] Nico dot Laus dot 2001 at gmx dot de
same with me - I had the same output with your code
and btw: I haven't found any setting for this in php.ini
[2003-07-01 09:43:09] postings-php-bug at hans-spath dot de
This is really weird:
===> CODE 1 <===
a[0][0]) ) echo 'empty($this->a[0][0])', N;
if( empty($this->a[0]) )echo 'empty($this->a[0])', N;
if( empty($this->a) ) echo 'empty($this->a)', N;
if( ! isset($this->a) ) echo 'isset($this->a)', N;
if( ! isset($this->a[0]) ) echo 'isset($this->a[0])', N;
if( ! isset($this->a[0][0]) ) echo 'isset($this->a[0][0])', N;
}
}
$x = new test();
===> OUTPUT (CODE 1) <===
test
empty($this->a[0][0])
empty($this->a[0])
empty($this->a)
isset($this->a)
isset($this->a[0])
isset($this->a[0][0])
===> CODE 2 <===
a[0][0]) ) echo 'empty($this->a[0][0])', N;
// if( empty($this->a[0]) )echo 'empty($this->a[0])', N;
// if( empty($this->a) ) echo 'empty($this->a)', N;
// if( ! isset($this->a) ) echo 'isset($this->a)', N;
// if( ! isset($this->a[0]) ) echo 'isset($this->a[0])', N;
if( ! isset($this->a[0][0]) ) echo 'isset($this->a[0][0])', N;
}
}
$x = new test();
===> OUTPUT (CODE 2) <===
PHP Notice: Undefined property: test::$a in M:\php\test.php on line
8
PHP Notice: Undefined property: test::$a in M:\php\test.php on line
13
test
Notice: Undefined property: test::$a in M:\php\test.php
on line 8
empty($this->a[0][0])
Notice: Undefined property: test::$a in M:\php\test.php
on line 13
isset($this->a[0][0])
===> PHP Version <===
PHP 5.0.0b2-dev (cgi-fcgi) (built: Jul 1 2003 12:10:02)
Copyright (c) 1997-2003 The PHP Group
Zend Engine v2.0.0-dev, Copyright (c) 1998-2003 Zend Technologies
[2003-07-01 09:40:12] Nico dot Laus dot 2001 at gmx dot de
hmmm, I will check my php.ini, maybe I can configure my php in the way
yours is, that no such errors are displayed (this is what I want)
-> I'll let you know whether I can change this with php.ini or it is
really a bug ;)
[2003-07-01 09:29:43] [EMAIL PROTECTED]
Ah, no, that was my fault, it gives errors now. But no errors *at all*
with this:
test[0][0])) { print "test1\n";}
if (!isset($this->test[0][0])) { print "test2\n";}
if (empty($this->test)) { print "test1\n";}
if (!isset($this->test)) { print "test2\n";}
}
}
$test1 = new test();
?>
Here it should have given 3 errors, for both the [0][0] ones, and the
empty($this->test) one.
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/24436
--
Edit this bug report at http://bugs.php.net/?id=24436&edit=1
#22901 [Opn->Bgs]: Error message for uncaught exception not very informative
ID: 22901
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Bogus
Bug Type: Zend Engine 2 problem
Operating System: Linux
PHP Version: 5CVS-2003-03-26 (dev)
New Comment:
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
Its informative enough :)
Previous Comments:
[2003-04-19 12:05:47] thekid at thekid dot de
[EMAIL PROTECTED]:~ > cat | php5
^D
Fatal error: Uncaught exception 'dummy_exception'! in Unknown on line
0
At least we've gotten a bit farther:)
[2003-03-26 19:14:48] [EMAIL PROTECTED]
Another small note:
No idea why it hast to be called "Uncaught exception!" with a trailing
bang but reading it in a message like
Fatal error: Uncaught exception! in Unknown on line 0
doesn't fit well.
Any plans to remove this?
[2003-03-26 08:29:51] [EMAIL PROTECTED]
The error message for uncaught exceptions is not very informative.
-8<
Example:
$ cat exception.php
$ php exception.php
Fatal error: Uncaught exception! in Unknown on line 0
Unknown(0) : Fatal error - Uncaught exception!
-8<
It doesn't matter whether the throw statement is in a function/class or
not.
A few things which should be considered worth improving this message:
- in which file is it thrown ("Unknown" ?)
- on which line is it thrown ("0" ?)
--
Edit this bug report at http://bugs.php.net/?id=22901&edit=1
#23783 [Asn->Csd]: NULL value in function indirection segfaults
ID: 23783 Updated by: [EMAIL PROTECTED] Reported By: leon at leonatkinson dot com -Status: Assigned +Status: Closed Bug Type: Reproducible crash Operating System: Linux PHP Version: 5CVS-2003-05-23 (dev) Assigned To: derick New Comment: 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. Previous Comments: [2003-05-23 11:47:19] leon at leonatkinson dot com The following example results in a segfault in PHP 5. It's OK in 4.3.0. -- Edit this bug report at http://bugs.php.net/?id=23783&edit=1
#21653 [Com]: Warning: fsockopen() [function.fsockopen]: php_hostconnect: connect failed
ID: 21653 Comment by: laudanp at yahoo dot com Reported By: support at hostcolor dot com Status: Closed Bug Type: Sockets related Operating System: RedHat 7.2 PHP Version: 4.3.3RC2-dev New Comment: Well its Independence weekend in the USA today, so its party time. Hopefully next week we can all get back to business. Happy Fourth all. Previous Comments: [2003-07-04 10:40:09] developer at yecc dot net HI ALL I download php 5 and install it on my computer that have RH7.3 But socket connection warning exists on php 5. What I must do? Developers of php what you do? Are you ok? [2003-07-01 09:16:47] larry at bowenaero dot com I'm also seeing this problem with SquirellMail 1.4.0 since my host upgraded to 4.3.2. SM worked flawlessly before the upgrade. The problem surfaces frequently, but with no obvious pattern. http://BowenAero.com/p.php Any help is appreciated. -LB [2003-07-01 06:38:08] laudanp at yahoo dot com Ok, I disabled any port blocking on my end this morning, and as it turns out I get the same messages as when port blocking was on: Warning: fsockopen(): unable to connect to xxx.xxx.xxx.xxx:21 in /var/www/html/testpaul.php on line 134 Connection Refused: Port 21 used by Nerte 7.8.1. This is odd indeed. [2003-06-30 08:27:35] laudanp at yahoo dot com CORRECTION TO THIS: So something is different between the TCP and UDP connections. Now, I'm running these scans from a box that is dropping the probes. Hence, since UDP is connectionless and TCP is connection oriented, the bug may have something to do with this? I haven't tested it on a system that is not running a firewall recently. What do your tests show now with the current snapshot? CORRECTED VERSION: *... Now, I'm running these scans from the server against a system that is dropping the probes via a firewall. ... I haven't tested it on a system that is not protected by a firewall (or disabled it). What do your tests show now with the current snapshot? ...* - Thanks [2003-06-30 08:24:33] laudanp at yahoo dot com Download: .bz2 (3.5M) .gz (4.3M) Built On: Jun 30, 2003 11:30 GMT php4-STABLE-200306301130 http://64.246.34.44/phpinfo.php http://64.246.34.44/testpaul.php Hi, I grabbed the latest stable cvs snapshot and it appears the problem persists. Its the same code, no change, since I started using it prior to PHP 4.2.3. For some reason, it doesn't work with 4.3.x. Now, for my UDP scanner (http://www.computercops.biz/modules.php?name=UDP_Scanner) on PHP 4.3.x I use the following code which works well with either 4.2.3 or 4.3.x: $handle = fsockopen($this-> targetIP, $portNumber, &$errno, &$errstr, 2); For the TCP Scanner (http://www.computercops.biz/modules.php?name=TCP_Scanner), I have this line: $handle = fsockopen($this-> targetIP, $index, $errno, $errstr, $this-> timeout); So something is different between the TCP and UDP connections. Now, I'm running these scans from a box that is dropping the probes. Hence, since UDP is connectionless and TCP is connection oriented, the bug may have something to do with this? I haven't tested it on a system that is not running a firewall recently. What do your tests show now with the current snapshot? Thanks (Phew, this is one elusive bug). P.S. Here is my configure statement: ./configure --with-mysql --with-apxs --with-gd --with-jpeg-dir=../jpeg-6b/ --with-zlib 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/21653 -- Edit this bug report at http://bugs.php.net/?id=21653&edit=1
#24402 [Com]: Compile Failure using --with-gettext (v. 0.12.x)
ID: 24402 Comment by: page at sca dot uqam dot ca Reported By: beckett at beckettmw dot com Status: Open Bug Type: Gettext related Operating System: Mac OS X/Darwin PHP Version: 5.0.0b1 (beta1) New Comment: I got: % grep LIBINTL main/php_config.h #define HAVE_LIBINTL 1 So everything seems fine for that variable in my case... Christian Pagé Previous Comments: [2003-07-02 20:32:50] beckett at beckettmw dot com > Can you please post the output of > > grep LIBINTL main/php_config.h #define HAVE_LIBINTL 1 > If it does not say "#define HAVE_LIBINTL 1", can you > please try: > > export LDFLAGS="$LDFLAGS -lintl" > make distclean > ./config.nice Well, grep *did* return that line as expected, but trying this altenative didn't work. Configure gets this far: | checking host system type... powerpc-apple-darwin6.6 | checking for gcc... gcc | checking whether the C compiler (gcc -lintl) works... no | configure: error: installation or configuration problem: C compiler cannot create executables. Please let me know if I can run any further tests, or if you can suggest a way to narrow down the problem. Thanks for your time!! [2003-07-02 15:20:48] [EMAIL PROTECTED] Can you please post the output of grep LIBINTL main/php_config.h (in the php directory). If it does not say "#define HAVE_LIBINTL 1", can you please try: export LDFLAGS="$LDFLAGS -lintl" make distclean ./config.nice [2003-07-02 12:13:09] page at sca dot uqam dot ca I have the same problem using php 4.3.2 with gettext 0.11.5 (from freeware.sgi.com). I am on SGI IRIX64 6.5.14m. Compilation fails with: /bin/sh /io/httpd/httpd-2.0.46/php-4.3.2/libtool -- silent --preserve-dup-deps --mode=compile cc -Iext/ gettext/ -I/io/httpd/httpd-2.0.46/php-4.3.2/ext/ gettext/ -DPHP_ATOM_INC -I/io/httpd/httpd-2.0.46/php- 4.3.2/include -I/io/httpd/httpd-2.0.46/php-4.3.2/main - I/io/httpd/httpd-2.0.46/php-4.3.2 -I/io/httpd/ apache_2.0.46/include -I/io/httpd/httpd-2.0.46/php- 4.3.2/Zend -I/usr/freeware/include -I/usr/freeware/ include/libxml2 -I/usr/local/mysql/include -I/io/httpd/ httpd-2.0.46/php-4.3.2/ext/xml/expat -D_XPG_IV -I/io/ httpd/httpd-2.0.46/php-4.3.2/TSRM -O2 -prefer-pic -c /io/httpd/httpd-2.0.46/php-4.3.2/ext/gettext/gettext.c -o ext/gettext/gettext.lo cc-1020 cc: ERROR File = /io/httpd/httpd-2.0.46/php- 4.3.2/ext/gettext/gettext.c, Line = 37 The identifier "zif_libintl_textdomain" is undefined. PHP_FE(textdomain, NULL) ^ cc-1020 cc: ERROR File = /io/httpd/httpd-2.0.46/php- 4.3.2/ext/gettext/gettext.c, Line = 38 The identifier "zif_libintl_gettext" is undefined. PHP_FE(gettext, NULL) ^ cc-1020 cc: ERROR File = /io/httpd/httpd-2.0.46/php- 4.3.2/ext/gettext/gettext.c, Line = 40 The identifier "zif_libintl_dgettext" is undefined. PHP_FE(dgettext,NULL) ^ cc-1020 cc: ERROR File = /io/httpd/httpd-2.0.46/php- 4.3.2/ext/gettext/gettext.c, Line = 41 The identifier "zif_libintl_dcgettext" is undefined. PHP_FE(dcgettext, NULL) ^ cc-1020 cc: ERROR File = /io/httpd/httpd-2.0.46/php- 4.3.2/ext/gettext/gettext.c, Line = 42 The identifier "zif_libintl_bindtextdomain" is undefined. PHP_FE(bindtextdomain, NULL) ^ cc-1020 cc: ERROR File = /io/httpd/httpd-2.0.46/php- 4.3.2/ext/gettext/gettext.c, Line = 44 The identifier "zif_libintl_ngettext" is undefined. PHP_FE(ngettext,NULL) ^ cc-1020 cc: ERROR File = /io/httpd/httpd-2.0.46/php- 4.3.2/ext/gettext/gettext.c, Line = 47 The identifier "zif_libintl_dngettext" is undefined. PHP_FE(dngettext, NULL) ^ cc-1020 cc: ERROR File = /io/httpd/httpd-2.0.46/php- 4.3.2/ext/gettext/gettext.c, Line = 50 The identifier "zif_libintl_dcngettext" is undefined. PHP_FE(dcngettext, NULL) ^ cc-1020 cc: ERROR File = /io/httpd/httpd-2.0.46/php- 4.3.2/ext/gettext/gettext.c, Line = 53 The identifier "zif_libintl_bind_textdomain_codeset" is undefined. PHP_FE(bind_textdomain_codeset, NULL) ^ 9 errors detected in the compilation of "/io/httpd/ httpd-2.0.46/php-4.3.2/ext/gettext/gettext.c". gnumake: *** [ext/gettext/gettext.lo] Error 1 [2003-06-30 10:15:35] beckett at beckettmw dot com Update: --- I have now tested PHP 4.3.1, 4.3.2, 5.0.0b1, as well as snaps dated 200306301330 of PHP4-STABLE, PHP4-CVS, and PHP5-CVS. In every case, PHP compiles with no errors if I use gettext 0.11.2. However, if I use gettext 0.12 or 0.12.1,
#24402 [Com]: Compile Failure using --with-gettext (v. 0.12.x)
ID: 24402 Comment by: page at sca dot uqam dot ca Reported By: beckett at beckettmw dot com Status: Open Bug Type: Gettext related Operating System: Mac OS X/Darwin PHP Version: 5.0.0b1 (beta1) New Comment: Also, I tried the config.nice, and configure does its jobs correctly, and in the compilation, it fails with the same errors. Christian Pagé Previous Comments: [2003-07-05 13:49:11] page at sca dot uqam dot ca I got: % grep LIBINTL main/php_config.h #define HAVE_LIBINTL 1 So everything seems fine for that variable in my case... Christian Pagé [2003-07-02 20:32:50] beckett at beckettmw dot com > Can you please post the output of > > grep LIBINTL main/php_config.h #define HAVE_LIBINTL 1 > If it does not say "#define HAVE_LIBINTL 1", can you > please try: > > export LDFLAGS="$LDFLAGS -lintl" > make distclean > ./config.nice Well, grep *did* return that line as expected, but trying this altenative didn't work. Configure gets this far: | checking host system type... powerpc-apple-darwin6.6 | checking for gcc... gcc | checking whether the C compiler (gcc -lintl) works... no | configure: error: installation or configuration problem: C compiler cannot create executables. Please let me know if I can run any further tests, or if you can suggest a way to narrow down the problem. Thanks for your time!! [2003-07-02 15:20:48] [EMAIL PROTECTED] Can you please post the output of grep LIBINTL main/php_config.h (in the php directory). If it does not say "#define HAVE_LIBINTL 1", can you please try: export LDFLAGS="$LDFLAGS -lintl" make distclean ./config.nice [2003-07-02 12:13:09] page at sca dot uqam dot ca I have the same problem using php 4.3.2 with gettext 0.11.5 (from freeware.sgi.com). I am on SGI IRIX64 6.5.14m. Compilation fails with: /bin/sh /io/httpd/httpd-2.0.46/php-4.3.2/libtool -- silent --preserve-dup-deps --mode=compile cc -Iext/ gettext/ -I/io/httpd/httpd-2.0.46/php-4.3.2/ext/ gettext/ -DPHP_ATOM_INC -I/io/httpd/httpd-2.0.46/php- 4.3.2/include -I/io/httpd/httpd-2.0.46/php-4.3.2/main - I/io/httpd/httpd-2.0.46/php-4.3.2 -I/io/httpd/ apache_2.0.46/include -I/io/httpd/httpd-2.0.46/php- 4.3.2/Zend -I/usr/freeware/include -I/usr/freeware/ include/libxml2 -I/usr/local/mysql/include -I/io/httpd/ httpd-2.0.46/php-4.3.2/ext/xml/expat -D_XPG_IV -I/io/ httpd/httpd-2.0.46/php-4.3.2/TSRM -O2 -prefer-pic -c /io/httpd/httpd-2.0.46/php-4.3.2/ext/gettext/gettext.c -o ext/gettext/gettext.lo cc-1020 cc: ERROR File = /io/httpd/httpd-2.0.46/php- 4.3.2/ext/gettext/gettext.c, Line = 37 The identifier "zif_libintl_textdomain" is undefined. PHP_FE(textdomain, NULL) ^ cc-1020 cc: ERROR File = /io/httpd/httpd-2.0.46/php- 4.3.2/ext/gettext/gettext.c, Line = 38 The identifier "zif_libintl_gettext" is undefined. PHP_FE(gettext, NULL) ^ cc-1020 cc: ERROR File = /io/httpd/httpd-2.0.46/php- 4.3.2/ext/gettext/gettext.c, Line = 40 The identifier "zif_libintl_dgettext" is undefined. PHP_FE(dgettext,NULL) ^ cc-1020 cc: ERROR File = /io/httpd/httpd-2.0.46/php- 4.3.2/ext/gettext/gettext.c, Line = 41 The identifier "zif_libintl_dcgettext" is undefined. PHP_FE(dcgettext, NULL) ^ cc-1020 cc: ERROR File = /io/httpd/httpd-2.0.46/php- 4.3.2/ext/gettext/gettext.c, Line = 42 The identifier "zif_libintl_bindtextdomain" is undefined. PHP_FE(bindtextdomain, NULL) ^ cc-1020 cc: ERROR File = /io/httpd/httpd-2.0.46/php- 4.3.2/ext/gettext/gettext.c, Line = 44 The identifier "zif_libintl_ngettext" is undefined. PHP_FE(ngettext,NULL) ^ cc-1020 cc: ERROR File = /io/httpd/httpd-2.0.46/php- 4.3.2/ext/gettext/gettext.c, Line = 47 The identifier "zif_libintl_dngettext" is undefined. PHP_FE(dngettext, NULL) ^ cc-1020 cc: ERROR File = /io/httpd/httpd-2.0.46/php- 4.3.2/ext/gettext/gettext.c, Line = 50 The identifier "zif_libintl_dcngettext" is undefined. PHP_FE(dcngettext, NULL) ^ cc-1020 cc: ERROR File = /io/httpd/httpd-2.0.46/php- 4.3.2/ext/gettext/gettext.c, Line = 53 The identifier "zif_libintl_bind_textdomain_codeset" is undefined. PHP_FE(bind_textdomain_codeset, NULL) ^ 9 errors detected in the compilation of "/io/httpd/ httpd-2.0.46/php-4.3.2/ext/gettext/gettext.c". gnumake: *** [ext/gettext/gettext.lo] Error 1 [2003-06-30 10:15:35] beckett at bec
#24305 [Bgs->Opn]: PHP cannot find script when called as CGI
ID: 24305 User updated by: ciaraldi at ciaraldi dot com Reported By: ciaraldi at ciaraldi dot com -Status: Bogus +Status: Open Bug Type: CGI related Operating System: Red Hat Linux 9 PHP Version: 4.3.2 New Comment: Does anyone have any further ideas on this? Specifically, PHP 4.3.2 looks at various environment variables to decide if it is being called as CGI, rather than being run directly from the shell. When it gets invoked by Apache, PHP decides it is being called as CGI, then looks in the environment variable PATH_TRANSLATED for the name of the script file. My Apache does not fill in this environment variable. Do I have to configure Apache to do this? As I mentioned earlier, this is the same Apache with the same httpd.conf file. The old PHP 4.2.1 worked fine with it, but 4.3.2 does not. Previous Comments: [2003-06-24 12:24:55] ciaraldi at ciaraldi dot com Can you be more specific? My Apache setup is the same as it has been for the last year, and PHP 4.2.1 worked fine with it. Is there a change to how Apache should be set up because of changes in PHP? [2003-06-23 21:56:45] [EMAIL PROTECTED] Setup your apache correctly and it works. [2003-06-23 21:11:06] ciaraldi at ciaraldi dot com Description: I had been running an old PHP (4.2.1) on my Linux box. When I upgraded to Red Hat 9, the old PHP binary immediately crashed, probably due to library changes. I downloaded PHP 4.3.2 and it compiled and installed fine. But when I tried to run PHP scripts as CGI under Apache 1.3.27 (the same scripts that ran fine before, and the same version of Apache, with the same INI files for both PHP and Apache), PHP gave the message "No input file specified." It seems that Apache passes the name of the script to PHP as a command-line argument, and this version of PHP is not looking for it there. I managed to patch cgi_main.c so it works, but I am not sure that I have not broken something else. See the next box for the patched code; I changed it in two places, marked with a comment which says "HACK". Reproduce code: --- Here is the patched code: http://poppy.ind.wpi.edu/~ciaraldi/cgi_main.c Typical script: #!/usr/local/bin/php Expected result: Hello Actual result: -- No input file specified. -- Edit this bug report at http://bugs.php.net/?id=24305&edit=1
#24507 [NEW]: Function for obfuscation/encryption
From: ensophic at hotmail dot com Operating system: Irrelevant PHP version: Irrelevant PHP Bug Type: Feature/Change Request Bug description: Function for obfuscation/encryption Description: I recommend that a code encryption function be added to PHP, similar to Zend Encoder or SourceGuardian Pro. For example: source_encrypt(code string, key string) could encrypt PHP code using a key. source_decrypt(encrypted_code string, key string) could decrypt PHP code and output the evaluated result of encrypted_code. This way, your PHP application could be a series of source_decrypt functions, and the end user wouldn't be able to access the PHP source code. I know this goes against open source, but many companies would greatly benefit from these functions (if not for speed, to save the money that would be spent on SourceGuardian Pro). -- Edit bug report at http://bugs.php.net/?id=24507&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=24507&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=24507&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=24507&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=24507&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=24507&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=24507&r=support Expected behavior: http://bugs.php.net/fix.php?id=24507&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=24507&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=24507&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=24507&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24507&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=24507&r=dst IIS Stability: http://bugs.php.net/fix.php?id=24507&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=24507&r=gnused
#24508 [NEW]: Different result of round()
From: erlendkb at online dot no Operating system: Windows XP PHP version: 5.0.0b1 (beta1) PHP Bug Type: *Math Functions Bug description: Different result of round() Description: This script gives different results in PHP4 (PHP 4.3.2) og PHP5 (5.0.0 BETA 1) Reproduce code: --- Expected result: PHP4: 4177.42 PHP5: 4177.41 Actual result: -- ... -- Edit bug report at http://bugs.php.net/?id=24508&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=24508&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=24508&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=24508&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=24508&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=24508&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=24508&r=support Expected behavior: http://bugs.php.net/fix.php?id=24508&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=24508&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=24508&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=24508&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24508&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=24508&r=dst IIS Stability: http://bugs.php.net/fix.php?id=24508&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=24508&r=gnused
#24508 [Com]: Different result of round()
ID: 24508 Comment by: robert at aristoteles dot xhaven dot net Reported By: erlendkb at online dot no Status: Open Bug Type: *Math Functions Operating System: Windows XP PHP Version: 5.0.0b1 (beta1) New Comment: It WFM @ Linux build (Apache 2.0.46, PHP5.0.0b1) - returns 4177.42 Previous Comments: [2003-07-05 16:00:13] erlendkb at online dot no Description: This script gives different results in PHP4 (PHP 4.3.2) og PHP5 (5.0.0 BETA 1) Reproduce code: --- Expected result: PHP4: 4177.42 PHP5: 4177.41 Actual result: -- ... -- Edit this bug report at http://bugs.php.net/?id=24508&edit=1
#24496 [Opn->Bgs]: mssql_select_db doesn't accept database names with whitespaces
ID: 24496
Updated by: [EMAIL PROTECTED]
Reported By: mheuser at a-tune dot de
-Status: Open
+Status: Bogus
Bug Type: MSSQL related
Operating System: Windows 2000 SP4
PHP Version: 4.3.2
New Comment:
The MSSQL syntax for handling white spaces in identifiers is to use []
arround the name.
$dbDatabase = "[030616 [EMAIL PROTECTED] mhe]";
// or
$dbDatabase = "[EMAIL PROTECTED] mhe 030616]";
Will work.
Previous Comments:
[2003-07-04 08:34:32] mheuser at a-tune dot de
Description:
The mssql_select_db function does not accept any whitespaces in the
database name string nor decimal numbers at the front. If I replace the
whitespaces with something else (like _) and cut the numbers out or let
them trail the string, no error occurs and the command is performed
correctly.
The code line given in the error messages at the bottom of this page,
are actually in the PEAR::MDB package. I located the line in the source
code:
if(!mssql_select_db($this->database_name, $this->connection)) {
return($this->mssqlRaiseError());
}
Reproduce code:
---
$dbDatabase = "030616 [EMAIL PROTECTED] mhe";
// or
$dbDatabase = "[EMAIL PROTECTED] mhe 030616";
mssql_select_db($dbDatabase); // Connection to DBMS server was already
made successfully
Expected result:
I'd expect no error message which means a successfully selected
database.
Actual result:
--
// Error message
Warning: mssql_select_db(): message: Zeile 1: Falsche Syntax in der
Nähe von '030616'. (severity 15) in C:\PHP\pear\MDB\mssql.php on line
417
// and for the second example
Warning: mssql_select_db(): message: Zeile 1: Falsche Syntax in der
Nähe von 'mhe'. (severity 15) in C:\PHP\pear\MDB\mssql.php on line 417
In both examples the error occurs when calling mssql_select_db (see
description on top of this page for the source code line).
--
Edit this bug report at http://bugs.php.net/?id=24496&edit=1
#24493 [Opn]: ./configure to check if --with-mssql and --with-sybase/--with-sybase_ct is set
ID: 24493 Updated by: [EMAIL PROTECTED] Reported By: mattias at segerdahl dot info Status: Open Bug Type: Feature/Change Request Operating System: All Nix Systems PHP Version: 5.0.0b1 (beta1) New Comment: I think we should exclude the mssql_* frunctions from the Sybase extensions when we compile on Windows or use --with-mssql on nix. #f !defined(HAVE_MSSQL) && !define(PHP_WIN32) ... #enif should fix this problem, at least one of the extensions are compiled as a shared object. Both modules uses libraries the expose the same object names so it is not possible to link both extensions in the same binary (unless they both link with freetds). Previous Comments: [2003-07-04 07:30:21] [EMAIL PROTECTED] Extra informations: Both extensions register the same functions, that's why they should not be enabled together at the same time. [2003-07-04 07:28:36] mattias at segerdahl dot info Description: Please configure the configuration script to check if both --with-sybase(_ct) and --with-mssql has been choosen when ./configure is running. This to prevent both modules to register the mssql_* functions -- Edit this bug report at http://bugs.php.net/?id=24493&edit=1
#24397 [Com]: Apache 1.3.27 inconsistencies with PHP5
ID: 24397 Comment by: phpbugs at localpin dot com Reported By: jlim at natsoft dot com Status: Open Bug Type: Apache related Operating System: Windows XP PHP Version: 5.0.0b1 (beta1) New Comment: To me it's a no brainer that all the dlls for v5 should be called php5apache.dll etc. Even if the code INSIDE is IDENTICAL to v4. Who cares what the code is doing INSIDE? Outside, if it says it's v5 everyone is happy (I think?!) - OK, some poor disks everywhere gotta store a php5.dll and a php4.dll which are identical, but the usability gain everywhere is huge. I see 2 choices: a) you call the dlls php4xyz.dll (v4), php5xyz.dll (v5) etc. b) you call the dlls phpxyz.dll and distribute different version with each version. Nobody expects php.exe in v4 to be the same as php.exe in v5 for example. regards, Hugh, someone desperately and unsuccessfully struggling to get PHP5 working with Windows XP and Apache 1.3.something (I could tell you what the something was if I could get it running) but I get the message I've seen a lot in these bug reports: "Cannot load c:/php/sapi/php4apache.dll into server: (126) The specified module could not be found" I've got a v5 copy of php4ts.dll almost everywhere (c:\php, c:\windows\system32, in with the Apache .exe). Did I miss one? ;) I've named the php4_module line to php5_module (sure can't miss that one reading these bug reports!): LoadModule php5_module c:/php/sapi/php4apache.dll AddType application/x-httpd-php .php If anyone can point me to the source of knowledge on getting this working I would sure appreciate it. Previous Comments: [2003-07-02 09:50:03] mike at digitalstruct dot com I believe that the file should also be called php5apache. The php4apache breaks consistancy and also makes it harder to run both 4 and 5 side by side. [2003-06-30 07:25:26] jlim at natsoft dot com Sorry The extension directory problem is bogus. I confused the php4 php.ini with the php5 php.ini settings. The other bugs mentioned are still relevant. [2003-06-29 23:56:56] jlim at natsoft dot com Description: Note the funky inconsistency below in the httpd.conf script that i had to use: php4apache.dll but php5_module Also the search path for php.ini and other files is WINDOWS/WINNT directory first. Shouldn't the current directory be first, eg: .;C:\WINDOWS like in PHP 4.3.2? Lastly, although the extension directory is correctly set (checked in phpinfo()), extensions do not appear to load. Reproduce code: --- # from httpd.conf script: LoadModule php5_module c:\php5\php5b1\php4apache.dll AddModule mod_php5.c AddType application/x-httpd-php .php -- Edit this bug report at http://bugs.php.net/?id=24397&edit=1
#24397 [Opn]: Apache 1.3.27 inconsistencies with PHP5
ID: 24397 Updated by: [EMAIL PROTECTED] Reported By: jlim at natsoft dot com Status: Open Bug Type: Apache related Operating System: Windows XP PHP Version: 5.0.0b1 (beta1) New Comment: This is not a support forum, and this bug of name inconsistencies is being worked on (note that it's an open bug report). Please use http://www.php.net/support for support questions. Previous Comments: [2003-07-05 18:00:32] phpbugs at localpin dot com To me it's a no brainer that all the dlls for v5 should be called php5apache.dll etc. Even if the code INSIDE is IDENTICAL to v4. Who cares what the code is doing INSIDE? Outside, if it says it's v5 everyone is happy (I think?!) - OK, some poor disks everywhere gotta store a php5.dll and a php4.dll which are identical, but the usability gain everywhere is huge. I see 2 choices: a) you call the dlls php4xyz.dll (v4), php5xyz.dll (v5) etc. b) you call the dlls phpxyz.dll and distribute different version with each version. Nobody expects php.exe in v4 to be the same as php.exe in v5 for example. regards, Hugh, someone desperately and unsuccessfully struggling to get PHP5 working with Windows XP and Apache 1.3.something (I could tell you what the something was if I could get it running) but I get the message I've seen a lot in these bug reports: "Cannot load c:/php/sapi/php4apache.dll into server: (126) The specified module could not be found" I've got a v5 copy of php4ts.dll almost everywhere (c:\php, c:\windows\system32, in with the Apache .exe). Did I miss one? ;) I've named the php4_module line to php5_module (sure can't miss that one reading these bug reports!): LoadModule php5_module c:/php/sapi/php4apache.dll AddType application/x-httpd-php .php If anyone can point me to the source of knowledge on getting this working I would sure appreciate it. [2003-07-02 09:50:03] mike at digitalstruct dot com I believe that the file should also be called php5apache. The php4apache breaks consistancy and also makes it harder to run both 4 and 5 side by side. [2003-06-30 07:25:26] jlim at natsoft dot com Sorry The extension directory problem is bogus. I confused the php4 php.ini with the php5 php.ini settings. The other bugs mentioned are still relevant. [2003-06-29 23:56:56] jlim at natsoft dot com Description: Note the funky inconsistency below in the httpd.conf script that i had to use: php4apache.dll but php5_module Also the search path for php.ini and other files is WINDOWS/WINNT directory first. Shouldn't the current directory be first, eg: .;C:\WINDOWS like in PHP 4.3.2? Lastly, although the extension directory is correctly set (checked in phpinfo()), extensions do not appear to load. Reproduce code: --- # from httpd.conf script: LoadModule php5_module c:\php5\php5b1\php4apache.dll AddModule mod_php5.c AddType application/x-httpd-php .php -- Edit this bug report at http://bugs.php.net/?id=24397&edit=1
#24510 [NEW]: Unable to access global variables
From: chuayw2000 at hotmail dot com Operating system: Windows XP (Professional) SP1 PHP version: 5.0.0b1 (beta1) PHP Bug Type: Variables related Bug description: Unable to access global variables Description: I am unable to access variables like $REMOTE_ADDR even though register_globals and track_vars are set to on. I can't even access the $_POST or $_GET variables. The page below is requested with a query of trial=trial (page.php?trial=trial) Reproduce code: --- "; echo $_GET["trial"]; ?> Expected result: An ip address (in my case 127.0.0.1 cos I am running using localhost) and a newline with the text "trial" should have been seen. Actual result: -- The page returned with nothing but only a "" html tag. However, the variables are present in the phpinfo() function. -- Edit bug report at http://bugs.php.net/?id=24510&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=24510&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=24510&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=24510&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=24510&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=24510&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=24510&r=support Expected behavior: http://bugs.php.net/fix.php?id=24510&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=24510&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=24510&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=24510&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24510&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=24510&r=dst IIS Stability: http://bugs.php.net/fix.php?id=24510&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=24510&r=gnused
