[PHP-DEV] Bug #15432 Updated: fopen does not work with password-protected URLs

2002-02-07 Thread edink 

 ID:   15432
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: HTTP related
 Operating System: Windows 2000
 PHP Version:  4.1.0
 New Comment:

cURL can handle redirects on pages with password protection. PHP cannot
do that yet. There must be something special about that page since I
can read pages protected by password under my Apache server with no
problems.

As a temporary workaround I suggeest you use cURL extension until we
can find a publicly available site where this problem can be
reproduced.


Previous Comments:


[2002-02-07 17:54:51] [EMAIL PROTECTED]

curl (like wget) can fetch the page, so I don't think there are any
redirects.

This is what I get if I remove the @ before fopen:


Warning:  fopen("http:[EMAIL PROTECTED]/Status.htm";, "r") - No
error in C:\Xitami\webpages\test.php on line 5
Can't fetch the page
(http://user:[EMAIL PROTECTED]/Status.htm), so I am giving up !!



[2002-02-07 17:48:06] [EMAIL PROTECTED]

I cannot reproduce this neither on Linux nor on Windows 2000. Does that
URL create any http redirects? Do you get any error messages if you
remove @ before fopen?



[2002-02-07 16:14:58] [EMAIL PROTECTED]

Both curl and the web browser can fetch the document using the notation
below, no problem (so, the user/password is correct).

I was also able to fetch a password-protected page from dhs.org via
PHP, so I am not sure why it is failing for the Linksys web server.
Maybe if I could debug what is being sent/received over the wire.





[2002-02-07 14:01:52] [EMAIL PROTECTED]

  I am trying to fetch the web page from my Linksys ADSL router, which
is password-protected, but fopen does not seem to understand the URL
format where a user/password is provided (like with FTP). See below.

http://user:[EMAIL PROTECTED]/Status.htm";;
$f_page = @fopen ($linksys_info_url, "r");
if ($f_page) {
$page_contents = fread ($f_page, 1024);
fclose ($f_page);
print ($page_contents);
} else {
echo "Can't fetch the page ($linksys_info_url), so I am giving up
!!";
}
?>




-- 
Edit this bug report at http://bugs.php.net/?id=15432&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Bug #15432 Updated: fopen does not work with password-protected URLs

2002-02-07 Thread edink 

 ID:   15432
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: HTTP related
 Operating System: Windows 2000
 PHP Version:  4.1.0
 New Comment:

I cannot reproduce this neither on Linux nor on Windows 2000. Does that
URL create any http redirects? Do you get any error messages if you
remove @ before fopen?


Previous Comments:


[2002-02-07 16:14:58] [EMAIL PROTECTED]

Both curl and the web browser can fetch the document using the notation
below, no problem (so, the user/password is correct).

I was also able to fetch a password-protected page from dhs.org via
PHP, so I am not sure why it is failing for the Linksys web server.
Maybe if I could debug what is being sent/received over the wire.





[2002-02-07 14:01:52] [EMAIL PROTECTED]

  I am trying to fetch the web page from my Linksys ADSL router, which
is password-protected, but fopen does not seem to understand the URL
format where a user/password is provided (like with FTP). See below.

http://user:[EMAIL PROTECTED]/Status.htm";;
$f_page = @fopen ($linksys_info_url, "r");
if ($f_page) {
$page_contents = fread ($f_page, 1024);
fclose ($f_page);
print ($page_contents);
} else {
echo "Can't fetch the page ($linksys_info_url), so I am giving up
!!";
}
?>




-- 
Edit this bug report at http://bugs.php.net/?id=15432&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Bug #15378 Updated: 3d array variables not usable in double quotes

2002-02-05 Thread edink 

 ID:   15378
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: Arrays related
 Operating System: Linux 2.4, Apache 1.3.22
 PHP Version:  4.1.1
 New Comment:

The correct syntax is:
echo "My first name is ".$var[name][first]."!";

You cannot have comples variables inside quotes.


Previous Comments:


[2002-02-05 00:34:07] [EMAIL PROTECTED]

I should add that the the first level of the array works fine, it is
just the second (& following) levels that cannot be used.

 array(
'first' => 'Caleb',
'last' => 'Maclennan'
  )
  );

echo "My first name is $var[name][first]!";

?>

Acutal Result:
My first name is Array[first]!

Correct Result:
My first name is Caleb!

This get's really nasty when useing 3 dimentional arrays to put data in
SQL querys. The above example can easily be done by takeing the
variable out of the quotes and useing "." to add it to the end, but
there are other cases where the only solution is to do like this:







-- 
Edit this bug report at http://bugs.php.net/?id=15378&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Bug #13437 Updated: PHP cores on exit; memory deallocation problem?

2002-02-04 Thread edink 

 ID:   13437
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Bogus
+Status:   Open
 Bug Type: Reproducible crash
 Operating System: Linux & Solaris
 PHP Version:  4.1.1
 New Comment:

On user request status => open


Previous Comments:


[2002-02-04 16:06:43] [EMAIL PROTECTED]

This problem still happens with PHP 4.1.1.

The edit submission page does not permit me to reopen bugs; I can't
change that status. Can someone else please reopen this? Thanks.



[2002-02-04 02:20:39] [EMAIL PROTECTED]

The version of PHP that this bug was reported in is too old. Please
try to reproduce this bug in the latest version of PHP (available
from http://www.php.net/downloads.php

If you are still 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".



[2001-12-11 09:51:44] [EMAIL PROTECTED]

I tried using apache_child_terminate() as suggested, however, this
doesn't help any. (It might be beneficial if this function and its
required configuration option were documented somewhere.)



[2001-12-10 22:32:39] [EMAIL PROTECTED]

Could you try calling apache_child_terminate() at the end 
of your script?




[2001-12-04 10:54:55] [EMAIL PROTECTED]

This helps with my problem of apache children being left in unusable
states with large memory allocations. However, it is still entirely
unreasonable that memory that takes only a few seconds to allocate
should need several minutes to be disposed of. I just watched PHP take
*six* minutes to dispose of 70 megs of memory it allocated, and on
prior occasions when no one was watching, I've found it to have be
running for *hours* cleaning up after itself.



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/13437

-- 
Edit this bug report at http://bugs.php.net/?id=13437&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Bug #12748 Updated: changing allow_url_fopen from "off" to "on" crashes fopen()

2002-02-04 Thread edink 

 ID:   12748
 Updated by:   [EMAIL PROTECTED]
-Summary:  changing allow_url_fopen from "off" to "on" crashes
   fopen()
 Reported By:  [EMAIL PROTECTED]
-Status:   Bogus
+Status:   Open
 Bug Type: Reproducible crash
 Operating System: redhat-7.1b
-PHP Version:  4.1.0
+PHP Version:  CVS-2002-02-04
 New Comment:

This one is still not fixed.


Previous Comments:


[2002-02-04 03:44:45] [EMAIL PROTECTED]

I haven't got the latest snapshot handy - or a machine to test on just
at the moment, but I did a quick test on 4.1.0 and segmentation faults
appear in my log, so it looks like the bug still exists. I'll try a
proper test when I get a chance.

I don't seem to be able to change it the status to Open using this bug
reporter however.

Thanks



[2002-02-04 02:15:35] [EMAIL PROTECTED]

The version of PHP that this bug was reported in is too old. Please
try to reproduce this bug in the latest version of PHP (available
from http://www.php.net/downloads.php

If you are still 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".



[2001-10-10 19:01:52] [EMAIL PROTECTED]

See #13633 which describes a similar problem - I am not 
alone :-)






[2001-08-18 05:56:51] [EMAIL PROTECTED]

Also, phpinfo() shows a blank cell for the 'Master Value' 
and "1" for the 'Local Value' of 'allow_url_fopen' when 
using; 

in php.ini:
allow_url_fopen = Off

& in httpd.conf
php_admin_flag allow_url_fopen On

I tried using "allow_url_fopen = 0" (Master Value becomes 
"0", fopen() still crashes).

I also tried "php_admin_value allow_url_fopen 1" (Local 
Value still "1", fopen() still crashes).

When I leave out the setting in httpd.conf, and just have 
"allow_url_fopen = Off" in the php.ini file, phpinfo() has 
"no value" written for the Master Value and Local Value.

Maybe this helps?






[2001-08-18 05:23:43] [EMAIL PROTECTED]

Todays snapshot - php4-200108180135.tar.bz2 - still shows 
the problem. Same config, same test script. 

redhat-7.1b == redhat 7.1 Beta (Fisher)

Backtrace from today:

Program received signal SIGSEGV, Segmentation fault.
0x402c0ad1 in zend_hash_find (ht=0x40395ae0, 
arKey=0x810c8dc "http://www.php.net";,
nKeyLength=4, pData=0xbfffe208) at zend_hash.c:861
861 p = ht->arBuckets[nIndex];

#0  0x402c0ad1 in zend_hash_find (ht=0x40395ae0,
arKey=0x810c8dc "http://www.php.net";, nKeyLength=4, 
pData=0xbfffe208)
at zend_hash.c:861
#1  0x402ca732 in php_fopen_url_wrapper (path=0x810c8dc 
"http://www.php.net";,
mode=0x81075cc "r", options=4, issock=0xbfffe248, 
socketd=0xbfffe24c,
opened_path=0x0) at fopen_wrappers.c:533
#2  0x4030aa87 in php_if_fopen (ht=2, 
return_value=0x81075ac, this_ptr=0x0,
return_value_used=1) at file.c:661
#3  0x402adaf8 in execute (op_array=0x810750c) at 
./zend_execute.c:1590
#4  0x402bbd05 in zend_execute_scripts (type=8, 
file_count=3) at zend.c:806
#5  0x402c945f in php_execute_script 
(primary_file=0xb740) at main.c:1310
#6  0x402c562e in apache_php_module_main (r=0x8101264, 
display_source_mode=0)
at sapi_apache.c:90
#7  0x402c6112 in send_php (r=0x8101264, 
display_source_mode=0, filename=0x0)
at mod_php4.c:575
#8  0x402c6166 in send_parsed_php (r=0x8101264) at 
mod_php4.c:590
#9  0x08055823 in ap_invoke_handler () at eval.c:41
#10 0x080695b3 in process_request_internal () at eval.c:41
#11 0x08069614 in ap_process_request () at eval.c:41
#12 0x08060ab9 in child_main () at eval.c:41
#13 0x08060c64 in make_child () at eval.c:41
#14 0x08060dd8 in startup_children () at eval.c:41
#15 0x08061427 in standalone_main () at eval.c:41
#16 0x08061c43 in main () at eval.c:41
#17 0x400ca6b7 in __libc_start_main (main=0x80618ac 
, argc=2,
ubp_av=0xbb84, init=0x804ea24 <_init>, 
fini=0x80968fc <_fini>,
rtld_fini=0x4000db64 <_dl_fini>, stack_end=0xbb7c)
at ../sysdeps/generic/libc-start.c:129

(gdb) print *ht
$7 = {nTableSize = 0, nTableMask = 0, nNumOfElements = 0, 
nNextFreeElement = 0,
  pInternalPointer = 0x0, pListHead = 0x0, pListTail = 
0x0, arBuckets = 0x0,
  pDestructor = 0, persistent = 0 '\000', nApplyCount = 0 
'\000',
  bApplyProtection = 0 '\000'}

Looks like 'fopen_url_wrappers_hash' in fopen_wrappers.c 
isn't being setup right? I'm lost though - I don't see how 
the apache directives work.





The re

[PHP-DEV] Bug #15304 Updated: if imap and sybase are compiled in mssql_connect does not find host

2002-01-31 Thread edink 

ID: 15304
Updated by: edink
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Feedback
Bug Type: IMAP related
Operating System: Debian Linux 2.2
PHP Version: 4.1.1
New Comment:

I belive this to be a recode problem. It happens to me if I compile
recode and mysql as shared extensions and then list recode after
mysql.

Do you compile recode and imap as shared modules? If so try putting
recode before imap in php.ini and see what happens.


Previous Comments:


[2002-01-31 06:48:39] [EMAIL PROTECTED]


Just in case: phptest() claims my configure script looks like this:

./configure --with-apxs --with-pear --with-exec-dir \
  --with-openssl=/opt/local --with-zlib-dir --with-zlib \
  --enable-bcmath --with-bz2=/opt/local \
  --enable-calendar --with-jpeg-dir --with-tiff-dir \
  --enable-ctype --with-curl=/opt/local \
  --enable-dba=shared --with-gdbm --with-ndbm \
  --with-db3=/opt/local --with-dbm --enable-dbase \
  --enable-dbx --with-dom=/opt/local --enable-exif \
  --enable-filepro --enable-ftp --with-gd=/opt/local \
  --enable-gd-native-ttf --with-png-dir=/opt/local \
  --with-xpm-dir=/usr/X11R6 \
  --with-freetype-dir=/opt/local --with-gettext
  --with-gmp=/opt/local --with-iconv \
  --with-imap-ssl=/opt/local \
  --with-java=/opt/jdk1.3.1_01 --with-ldap=/opt/local \
  --enable-mailparse --enable-mbstring \
  --with-mcal=/opt/local --with-mhash=/opt/local
  --with-mnogosearch=/opt/local/mnogosearch \
  --with-mysql=/usr --with-pcre-regex=/opt/local \
  --enable-trans-sid --with-snmp=/opt/local \
  --enable-ucd-snmp-hack --enable-sockets \
  --with-regex=system --with-regex=apache \
  --with-regex=php --with-sybase=/opt/sybase-11.9.2 \
  --enable-sysvsem --enable-sysvshm \
  --with-expat-dir=/opt/local --with-xmlrpc=/opt/local \
  --enable-xslt --with-xslt-sablot=/opt/local \
  --with-yaz=/opt/local --with-zip=/opt/local \
  --enable-versioning --disable-debug --enable-bc \
  --enable-sablot-errors-descriptive --enable-shmop \
  --with-pspell=/opt/local --with-mcrypt=/opt/local \
  --with-recode=/opt/local




[2002-01-31 06:37:36] [EMAIL PROTECTED]


I'm changing this to IMAP-related.
Reason:
when compiling with recode and imap apache
crashes at startup removing either one
cures the problem.
I like to blame imap for both problems.




[2002-01-30 16:46:20] [EMAIL PROTECTED]


When compiled with --with-sybase=/opt/sybase-11.9.2 and
--with-imap=/opt/local
where imap version is 2001a (or older) mssql_connect acts strangely:

- it claims it cannot find the specified entry in the interfaces file
- it does an /etc/hosts / DNS-Lookup $host  where $host is the
   name of the entry in the interfaces file. It does not help to
   rename the entry to the hostname of tzhe database server.

if --with-imap is removed everything works.

This must be a naming conflict of some functions, I guess.






Edit this bug report at http://bugs.php.net/?id=15304&edit=1


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #15148 Updated: Troubbles with setcookie (on Unix Solaris php)

2002-01-21 Thread edink 

ID: 15148
Updated by: edink
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Bogus
Bug Type: *General Issues
Operating System: Solaris 5.8
PHP Version: 4.1.1
New Comment:

Please make sure that nothing is printed from
db-include.old. If something gets printed (anything: space,
error message) the headers get sent so it is impossible
to add cookie headers at that point.



Previous Comments:


[2002-01-21 10:31:44] [EMAIL PROTECTED]

Hi guys...
I had a script (sw.php) who works fine on php 4.1.1 on Windows NT, but
when I try to run it on Solaris show me the following error:

Warning: Cannot add header information - headers already sent by
(output started at /www/htdocs/db-include.old:2) in /www/htdocs/sw.php
on line 46

sw.php, call via OCI8 an Oracle8 database through db-include.old file
who assigns username, password and string connection:

< sw.php ->

$rut=$HTTP_COOKIE_VARS["rut_alum"];
require('db-include.old');
$Connection = OCILogon(DB_USER,DB_PASS,DB_NAME);
$q_semeinsc =  "select ...";

$statement1 = ociparse($Connection, $q_semeinsc);
ociexecute($statement1, OCI_DEFAULT);

while (OCIFetchinto($statement1, &$semeinsc,
OCI_ASSOC+OCI_RETURN_NULLS))
{
$vanual = $semeinsc[VAR];
...
}
if(!isset($nsemestre))
{
$server_name = getenv("SERVER_NAME");
$http_host = getenv("HTTP_HOST");
setcookie("nsemestre", $vanual, time()+3600);
}
< End ->

The warning points to the setcookie line. The script fetch the results
of Database, but show that ugly warning...

Can u help me? I'm very desperated...

Greetings Alexis from Chile
(sorry for my english)







Edit this bug report at http://bugs.php.net/?id=15148&edit=1


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #14588 Updated: --with-bz2 doesn't listen to =dir

2002-01-20 Thread edink 

ID: 14588
Updated by: edink
Old Summary: --with-bz2 doesn't listen to =dir
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Closed
Bug Type: Bzip2 Related
Operating System: linux 2.4.16 - redhat 6.2
PHP Version: 4.1.0
New Comment:

It seems that this is not a php bug but a problem
with the way libtool works and how RedHat packages
the libraries. There is an easy workaround:

mv /usr/lib/libbz2.la /usr/lib/libbz2.la.old

Then configure and compile php. This should fix
the problem. If it does not, please reopen the report.

To answer your other questions:

1. Have a look at pear/Mail/smtp.php

2. Yes. It's probably going to make it into the next major
   release of php.


Previous Comments:


[2001-12-19 01:22:13] [EMAIL PROTECTED]


The kicker about this problem is that it only shows up when php is
being compiled as a CGI. I always compile twice

Php bzip2 support requires >= 1.0.0

Redhat 6.2 bzip2-0.9.5d-2
Upgradng the stock bzip2 is not an option, there are too many packages
that require the shared object files from this version.

When I first tried adding bzip2 support to php I had the same errors as
you'll see below.

So to solve this, I installed bzip2-1.0.1 into /www
and told php where it is with --with-bz2=/www
all earlier releases of php 4.X worked fine with this.
Until 4.1.0, which seemingly is trying to use the headers from /usr
which brings us back to php-4.1.0 is ignoring =/www for the --with-bz2
compile option.

Redhat 7.0 bzip2-1.0.1-3
This problem doesn't exist.

Redhat 7.1 bzip2-1.0.1-3
This problem doesn't exist.


Ok, here's the error

make[1]: Entering directory `/usr/src/web/build/php-4.1.0'
/bin/sh /usr/src/web/build/php-4.1.0/libtool --silent --mode=link gcc
-I. -I/usr/src/web/build/php-4.1.
0/ -I/usr/src/web/build/php-4.1.0/main -I/usr/src/web/build/php-4.1.0
-I/usr/src/web/build/php-4.1.0/Ze
nd -I/www/include -I/www/include/freetype2/freetype
-I/usr/include/mysql -I/usr/src/web/build/php-4.1.0
/ext/xml/expat  -I/usr/src/web/build/php-4.1.0/TSRM -g -O2   -o php
-export-dynamic  stub.lo libphp
4.la 
./.libs/libphp4.a(bz2.o): In function `zm_info_bz2':
/usr/src/web/build/php-4.1.0/ext/bz2/bz2.c:97: undefined reference to
`BZ2_bzlibVersion'
./.libs/libphp4.a(bz2.o): In function `zif_bzopen':
/usr/src/web/build/php-4.1.0/ext/bz2/bz2.c:127: undefined reference to
`BZ2_bzopen'
/usr/src/web/build/php-4.1.0/ext/bz2/bz2.c:132: undefined reference to
`BZ2_bzdopen'
./.libs/libphp4.a(bz2.o): In function `zif_bzread':
/usr/src/web/build/php-4.1.0/ext/bz2/bz2.c:171: undefined reference to
`BZ2_bzread'
./.libs/libphp4.a(bz2.o): In function `zif_bzwrite':
/usr/src/web/build/php-4.1.0/ext/bz2/bz2.c:211: undefined reference to
`BZ2_bzwrite'
./.libs/libphp4.a(bz2.o): In function `zif_bzflush':
/usr/src/web/build/php-4.1.0/ext/bz2/bz2.c:230: undefined reference to
`BZ2_bzflush'
./.libs/libphp4.a(bz2.o): In function `zif_bzcompress':
/usr/src/web/build/php-4.1.0/ext/bz2/bz2.c:319: undefined reference to
`BZ2_bzBuffToBuffCompress'
./.libs/libphp4.a(bz2.o): In function `zif_bzdecompress':
/usr/src/web/build/php-4.1.0/ext/bz2/bz2.c:370: undefined reference to
`BZ2_bzBuffToBuffDecompress'
./.libs/libphp4.a(bz2.o): In function `php_bz2_close':
/usr/src/web/build/php-4.1.0/ext/bz2/bz2.c:391: undefined reference to
`BZ2_bzclose'
./.libs/libphp4.a(bz2.o): In function `php_bz2_error':
/usr/src/web/build/php-4.1.0/ext/bz2/bz2.c:411: undefined reference to
`BZ2_bzerror'
collect2: ld returned 1 exit status
make[1]: *** [php] Error 1
make[1]: Leaving directory `/usr/src/web/build/php-4.1.0'
make: *** [install-recursive] Error 1


While I have your attention I've got a few unrelated questions.

1) Unix smtp server option was going to be added to 4.0.4, yet has
still not been added. Any date set for this?

2) Php compiled as a module and as a cgi was supposed to have been
changed so only 1 compile was necessary. Is this still in the plans?

Thanks.

Dan



[2001-12-18 14:03:59] [EMAIL PROTECTED]


ah heck ok I'll recompile, but it's still a waste. I'll go for a
coffee. :-)



[2001-12-18 13:58:03] [EMAIL PROTECTED]


The php developer who added/maintains bzip2 support will know what I am
talking about. I am not going to compile when I know this! It would be
a waste of my time.



[2001-12-18 13:46:26] [EMAIL PROTECTED]

Please recompile so that you can tell us te exact errors.

Derick



[2001-12-18 13:39:06] [EM

[PHP-DEV] Bug #9041 Updated: Extra #! at top of web output.

2002-01-20 Thread edink 

ID: 9041
Updated by: edink
Reported By: [EMAIL PROTECTED]
Old Status: Analyzed
Status: Closed
Bug Type: *General Issues
Operating System: Solaris 7.
PHP Version: 4.0.4pl1
New Comment:

I have applied the patch to the current CVS.


Previous Comments:


[2001-08-31 11:53:34] [EMAIL PROTECTED]

Diff copied from #8898:

*** sapi/cgi/cgi_main.c.origSun Dec  3 02:09:13 2000
--- sapi/cgi/cgi_main.cWed Jan 24 16:39:34 2001
***
*** 719,725 
  return FAILURE;
  }
  file_handle.filename = argv0;
! } else if (file_handle.handle.fp && file_handle.handle.fp!=stdin) {
  /* #!php support */
  c = fgetc(file_handle.handle.fp);
  if (c == '#') {
--- 719,726 
  return FAILURE;
  }
  file_handle.filename = argv0;
! }
! if (file_handle.handle.fp && file_handle.handle.fp!=stdin) {
  /* #!php support */
  c = fgetc(file_handle.handle.fp);
  if (c == '#') {



[2001-06-17 04:41:01] [EMAIL PROTECTED]

This will be fixed when we split the commandline and cgi modules apart.
moving back to analysed.

- James



[2001-05-09 11:40:05] [EMAIL PROTECTED]

Here's a quick and dirty fix.

18:39  oK open cgi_main.c
18:39  and goto line 720
18:40  See that else if .
18:40  } else if (file_handle.handle.fp &&
file_handle.handle.fp!=stdin) {
18:40  make it read }
18:41  and then loose the } 11 lines down



[2001-02-24 12:06:51] [EMAIL PROTECTED]

Suspending this until a decision about what should be the correct
behaviour from PHP should be.



[2001-02-05 16:34:55] [EMAIL PROTECTED]

Here are the CGI's I'm using:


#!/opt/php/bin/php




#!/bin/sh
echo Content-type: text/html\\n\\n;
echo "foo!"


Now this might not help any, but I truss'd the web server process
(Netscape, remember.) and here a few snippits output.

sh CGI.
read(23, " C o n t e n t - t y p e".., 8192)= 31
send(17, " H T T P / 1 . 1   2 0 0".., 118, 0)  = 118
send(17, "\n f o o !\n", 6, 0)  = 6

PHP CGI.
read(22, " X - P o w e r e d - B y".., 8192)= 5120
send(17, " H T T P / 1 . 1   2 0 0".., 146, 0)  = 146
send(17, " # ! / o p t / p h p / b".., 5065, 0) = 5065

Graphic for PHP CGI page.
send(19, " H T T P / 1 . 1   2 0 0".., 146, 0)  = 146
send(19, " G I F 8 9 a82\0 C\0D5FF".., 2962, 0) = 2962

I can't tell if the web server is inserting this line or if PHP is.
However, when I run these two CGIs on the command line, I never see
this extra line. I guess I'm thinking that PHP does weird shit when
it's not run in a shell.

Any other information I can provide?



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/?id=9041


Edit this bug report at http://bugs.php.net/?id=9041&edit=1


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #15126: Segfalt on startup when compiled with oci8

2002-01-20 Thread edink 

From: [EMAIL PROTECTED]
Operating system: RedHat Linux 6.2
PHP version:  4.0CVS-2002-01-20
PHP Bug Type: Apache2 related
Bug description:  Segfalt on startup when compiled with oci8

Apache 2 segfaults on startup when php is configured with:
./configure --enable-debug --with-oci8 --with-apx2

Apache was configured with:
./configure  --enable-maintainer-mode --with-mpm=prefork --enable-so

On the same platform Apache 1.3 + Oracle 8.0.5 + php any
version function with no problems.

Backtrace:

#0  php_apache_sapi_send_headers (sapi_headers=0x812d660,
tsrm_ls=0x812d5f8) at sapi_apache2.c:106
#1  0x2ad21d8c in sapi_send_headers (tsrm_ls=0x812d5f8) at SAPI.c:578
#2  0x2ad7dc1e in php_header () at head.c:58
#3  0x2ad26d71 in php_ub_body_write (str=0x7fffe3ec "OCIDebug: START
php_mshutdown_oci\n", 
str_length=40, tsrm_ls=0x812d5f8) at output.c:461
#4  0x2ad2615c in php_body_write (str=0x7fffe3ec "OCIDebug: START
php_mshutdown_oci\n", 
str_length=40, tsrm_ls=0x812d5f8) at output.c:99
#5  0x2ad1bf37 in php_printf (format=0x2add0db0 "OCIDebug: %s\n") at
main.c:355
#6  0x2ad41c82 in oci_debug (format=0x2add09c8 "START php_mshutdown_oci")
at oci8.c:1031
#7  0x2ad410a9 in zm_shutdown_oci (type=1, module_number=7,
tsrm_ls=0x812d5f8) at oci8.c:591
#8  0x2ad12a53 in module_destructor (module=0x81671a8) at zend_API.c:1124
#9  0x2ad147b3 in zend_hash_destroy (ht=0x2adfdc40) at zend_hash.c:541
#10 0x2ad0f3dc in zend_shutdown (tsrm_ls=0x812d5f8) at zend.c:490
#11 0x2ad1d7c7 in php_module_shutdown (tsrm_ls=0x812d5f8) at main.c:1000
#12 0x2ad1d78f in php_module_shutdown_wrapper (sapi_globals=0x2ade1000) at
main.c:977
#13 0x2ad1b223 in php_apache_server_shutdown (tmp=0x0) at
sapi_apache2.c:408
#14 0x2aae93ec in run_cleanups (c=0x812c2d8) at apr_pools.c:1713
#15 0x2aae876a in apr_pool_clear (pool=0x80aca60) at apr_pools.c:524
#16 0x807b7ce in main (argc=2, argv=0x7994) at main.c:458
-- 
Edit bug report at: http://bugs.php.net/?id=15126&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #12219 Updated: Command Line Arguments not being passed correctly

2002-01-19 Thread edink 

ID: 12219
Updated by: edink
Reported By: [EMAIL PROTECTED]
Old Status: Analyzed
Status: Closed
Bug Type: URL related
Operating System: Redhat 7.0
PHP Version: 4.0.5
New Comment:

This issue is resolved by inclussion of
cli sapi in the current cvs. You can download the
latest cvs snapshot from http://snaps.php.net/php4-latest.tar.gz.

The new cli interpreter is built in $srcdir/sapi/cli.
make install will install it in $bindir/php
(/usr/local/bin/php by default).


Previous Comments:


[2001-07-18 11:37:08] [EMAIL PROTECTED]

Ack! What was I doing? :) Thanks for catching this!





[2001-07-18 10:21:42] [EMAIL PROTECTED]

Zak, IIRC this _is_ a bug, or at least a misfeature. the TODO file
says:

* when used in standalone (skell-script like) mode don't urldecode
  arguments passed to php. right now it's not possible to say
/usr/local/bin/php somescript.php dog+cat.txt
  as "dog+cat.txt" will arrive in php as "dog cat.txt". 

BTW, AFAICT the manual page you linked here contains _nothing_ about
this particular issue (I even read all the notes on the page).




[2001-07-17 22:33:26] [EMAIL PROTECTED]

This is not a bug.
Review http://www.php.net/manual/en/language.variables.external.php



[2001-07-17 20:31:03] [EMAIL PROTECTED]

./grab_meta
http://altavista.com/sites/search/web?q=task+management&pg=q&kl=XX 3

The following command line argument doesn't work because of the plus
sign (+).  This also hold true when the second argument is enclosed in
qutoes (") || (').
The plus sign (+) causes the second argument to split up into two
smaller arguments.  BUG?





Edit this bug report at http://bugs.php.net/?id=12219&edit=1


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #12450 Updated: Segfaults if recode is loaded after mysql or imap

2002-01-16 Thread edink 

ID: 12450
Updated by: edink
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Open
Bug Type: Recode related
Old Operating System: Red Hat Linux 6.2
Operating System: Red Hat Linux 6.2-7.2
Old PHP Version: 4.0.6
PHP Version: 4.1.1
New Comment:

I can reproduce this:

Starting program: /usr/bin/php -v

Program received signal SIGSEGV, Segmentation fault.
0x1f91 in ?? () at eval.c:41
41  eval.c: No such file or directory.
in eval.c
(gdb) bt
#0  0x1f91 in ?? () at eval.c:41
#1  0x409d4e9e in find_alias (outer=0x81ae688, name=0x40a8bca0 "data",
find_type=SYMBOL_CREATE_CHARSET) at names.c:299
#2  0x409d66d0 in register_all_modules (outer=0x81ae688) at
outer.c:457
#3  0x409d6cdd in recode_new_outer (auto_abort=true) at outer.c:550
#4  0x408f8f17 in zm_startup_recode (type=1, module_number=18) at
recode.c:79
#5  0x0808d3b2 in php_dl (file=0x816c0a0, type=1,
return_value=0xb6e0) at dl.c:177
#6  0x08062f4e in php_load_function_extension_cb (arg=0x816c0a0) at
php_ini.c:185
#7  0x080e8fc5 in zend_llist_apply (l=0x814f7bc,
func=0x8062f2c ) at
zend_llist.c:186
#8  0x08063235 in php_ini_delayed_modules_startup () at php_ini.c:302
#9  0x08060dbd in php_module_startup (sf=0x8146400) at main.c:946
#10 0x0805f009 in main (argc=2, argv=0xb994) at cgi_main.c:445
#11 0x405b8507 in __libc_start_main (main=0x805ee98 , argc=2,
ubp_av=0xb994, init=0x805d0f8 <_init>, fini=0x8122610 <_fini>,
rtld_fini=0x4000dc14 <_dl_fini>, stack_end=0xb98c)
at ../sysdeps/generic/libc-start.c:129



Previous Comments:


[2002-01-11 17:19:08] [EMAIL PROTECTED]

Can you:
  - try this with 4.1.1
  - provide a usefull backtrace: 
http://bugs.php.net/bugs-generating-backtrace.php



[2001-07-28 14:19:43] [EMAIL PROTECTED]

PHP segfaults if recode.so (php's recode extension as a shared library)
is loaded _after_ the imap or mysql extensions. Re-ordering the php.ini
file so that the "extension=recode.so" line is the first
"extension=..."-line stops the segfaults.

Recode versions tested: 3.5d, 3.6.

PHP versions tested: 4.0.6.

config.nice:


#! /bin/sh
#
# Created by configure

"./configure" \
"--prefix=/usr" \
"--libdir=/usr/lib/php4" \
"--includedir=/usr/include" \
"--datadir=/usr/share/php" \
"--with-config-file-path=/etc" \
"--enable-discard-path" \
"--enable-inline-optimization" \
"--enable-magic-quotes" \
"--enable-track-vars" \
"--enable-memory-limit" \
"--enable-wddx" \
"--enable-bcmath" \
"--enable-sigchild" \
"--with-xml" \
"--with-mm" \
"--with-openssl" \
"--enable-ftp=shared" \
"--enable-exif=shared" \
"--with-gd=shared,/usr" \
"--with-ttf" \
"--enable-gd-imgstrttf" \
"--with-png-dir=/usr" \
"--with-jpeg-dir=/usr" \
"--enable-sysvsem=shared" \
"--enable-sysvshm=shared" \
"--enable-shmop=shared" \
"--with-unixODBC=shared" \
"--with-mysql=shared,/usr" \
"--with-ldap=shared" \
"--with-pgsql=shared" \
"--with-gettext=shared" \
"--with-pspell=shared" \
"--with-snmp=shared" \
"--enable-ucd-snmp-hack" \
"--with-sybase-ct=shared,/usr" \
"--with-pdflib=shared" \
"--with-oci8=shared" \
"--with-swf=shared,/home/troels/rpm/BUILD/php-4.0.6/swflib" \
"--enable-sockets=shared" \
"--with-gmp=shared" \
"--with-dom=shared" \
"--with-qtdom=shared,/usr/lib/qt-2.3.0" \
"--with-iconv=shared" \
"--with-curl=shared" \
"--enable-apc=shared" \
"--with-ming=shared" \
"--with-imlib=shared" \
"--with-recode=shared" \
"--with-zlib=/usr" \
"$@"

php.ini:


extension_dir   =   /usr/lib/php4

;; Global PHP defaults

warn_plus_overloading   =   On  ; warn if the + operator is
used with strings
track_errors=   On  ; Store the last error/warning
message in $php_errormsg (boolean)
track_vars  =   On  ; enable the $HTTP_*_VARS[]
arrays, where * is one of

magic_quotes_gpc=   On  ; magic quotes for incoming
GET/POST/Cookie data
; many people think that the
system is a pain in the
; a**, but it probably does
represent a security
; feature for in-experienced
PHP developers. Turn it

[PHP-DEV] Bug #14930 Updated: CLI header suppression problems

2002-01-11 Thread edink 

ID: 14930
Updated by: edink
Reported By: [EMAIL PROTECTED]
Old Status: Analyzed
Status: Closed
Bug Type: Output Control
Operating System: linux 2.4.9
PHP Version: 4.1.1
New Comment:

After some research on the subject I found out
that there is no good and
portable way of solving this. Some unix systems
simply allow only one argument in the #! line. One
of those systems is Linux. Some others limit the
line length to 32 characters.

For a good description of these limitations see
http://groups.google.com/groups?q=shell+limit+one+argument&hl=en&selm=qij4tk2zgp9.fsf%40lambda.ai.mit.edu&rnum=7


Workarounds:
* You can put all the options that do not require
  parameters as one, for example -qC
* Use PHPRC env variable to set the php.ini path



Previous Comments:


[2002-01-10 16:32:04] [EMAIL PROTECTED]

I don't think this is a glibc issue.  Its (AFAIK) the kernel's
responsibility to set this stuff up.  Take a look at load_script() in
fs/binfmt_script.c of the linux source.  It seems that only one
argument is allowed, and everything after the interpreter
(/usr/local/bin/php) up until the EOL is considered one argument.  I'm
sure there is a reason for implementing it this way, I just don't know
what it is.

Sean



[2002-01-08 19:29:05] [EMAIL PROTECTED]

I was able to reproduce this. However it does not appear
to be a php bug. Most likely a glibc bug.

If I put this line on top of my script:
#!/usr/bin/php -q -c /path/to/ini/file -C

the following values get passed to
php's main() function.

argc=3
argv[0]: php
argv[1]: -q -c /path/to/ini/file -C
argv[2]: ./test (which is the name of the script)

With parameters passed like that, php has
no chance of passing them correctly.

FreeBSD systems appear to be free of this problem.



[2002-01-08 10:54:04] [EMAIL PROTECTED]

I don't know if this should go under output control but 
anyways...

The command line executable is having problems suppressing 
the headers using the -q option in combination with the -c 
option if you're running the script as, well, a script. For 
instance, take this small script:

#!/usr/local/bin/php -c /path/to/ini/file -q


The headers won't be suppressed if you try running the 
script with a command like

$ ./smallscript.php
X-Powered-By: PHP/4.1.1
Content-type: text/html

hello world

However, running the script like so:

$ php -q -c /path/to/ini/file smallscript.php
hello world

produces the expected result, without the headers.

Also, this may or may not be an associated bug, but if you 
put the -q option before the -c option in the command line 
for a script, i.e.

#!/usr/local/bin/php -q -c /some/path


An error is produced, which looks something like this:

Error in argument 1, char 3: option not found
Error in argument 1, char 4: option not found -
Error in argument 1, char 3: option not found

along with the output from "php -h". This doesn't happen 
when you execute directly from the command line, only when 
the command line is in the script file itself.

J






Edit this bug report at http://bugs.php.net/?id=14930&edit=1


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #14930 Updated: CLI header suppression problems

2002-01-08 Thread edink 

ID: 14930
Updated by: edink
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Analyzed
Bug Type: Output Control
Operating System: linux 2.4.9
PHP Version: 4.1.1
New Comment:

I was able to reproduce this. However it does not appear
to be a php bug. Most likely a glibc bug.

If I put this line on top of my script:
#!/usr/bin/php -q -c /path/to/ini/file -C

the following values get passed to
php's main() function.

argc=3
argv[0]: php
argv[1]: -q -c /path/to/ini/file -C
argv[2]: ./test (which is the name of the script)

With parameters passed like that, php has
no chance of passing them correctly.

FreeBSD systems appear to be free of this problem.

Previous Comments:


[2002-01-08 10:54:04] [EMAIL PROTECTED]

I don't know if this should go under output control but 
anyways...

The command line executable is having problems suppressing 
the headers using the -q option in combination with the -c 
option if you're running the script as, well, a script. For 
instance, take this small script:

#!/usr/local/bin/php -c /path/to/ini/file -q


The headers won't be suppressed if you try running the 
script with a command like

$ ./smallscript.php
X-Powered-By: PHP/4.1.1
Content-type: text/html

hello world

However, running the script like so:

$ php -q -c /path/to/ini/file smallscript.php
hello world

produces the expected result, without the headers.

Also, this may or may not be an associated bug, but if you 
put the -q option before the -c option in the command line 
for a script, i.e.

#!/usr/local/bin/php -q -c /some/path


An error is produced, which looks something like this:

Error in argument 1, char 3: option not found
Error in argument 1, char 4: option not found -
Error in argument 1, char 3: option not found

along with the output from "php -h". This doesn't happen 
when you execute directly from the command line, only when 
the command line is in the script file itself.

J






Edit this bug report at http://bugs.php.net/?id=14930&edit=1


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #14938 Updated: No htmlescape() function for PHP4

2002-01-08 Thread edink 

ID: 14938
Updated by: edink
Reported By: [EMAIL PROTECTED]
Status: Open
Old Bug Type: Unknown/Other Function
Bug Type: Documentation problem
Operating System: Linux
PHP Version: 4.1.1
New Comment:

You can use htmlspecialchars() htmlentities().

Filled as a documentation problem.

Previous Comments:


[2002-01-08 17:29:58] [EMAIL PROTECTED]

As you can find PHP Faq at:http://www.php.net/manual/en/faq.html.php,
there is a function of htmlescape() to escape string for html syntax.
unfortunately, i can not find htmlescape() function from php function
table, and wonder what is going on here.
would you kindly please let me about it? thanx a ton!
Jackey





Edit this bug report at http://bugs.php.net/?id=14938&edit=1


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #14921 Updated: Shared Memory problem! BUG!

2002-01-07 Thread edink 

ID: 14921
Updated by: edink
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Bogus
Bug Type: Unknown/Other Function
Operating System: FreeBSD 4.4
PHP Version: 4.1.1
New Comment:

If you are talking about --with-sysvshm shared memory
there was a change of parameters for some functions
like shm_remove. It use to take shm_key as the argument,
while it take mem_id now.

The documentation is updated and should give you
enough info to fix the problems.

http://www.php.net/manual/en/ref.sem.php

If this does not solve your problem,
please reopen the bug report with some more info.

Previous Comments:


[2002-01-07 18:18:23] [EMAIL PROTECTED]

Your shared memory implementation is buggy in 4.1.1. You can attach a
shmem segment, but you can not detach it.

This is a real bug.

If I try to detach an existing and valid shmem segment, I get this:

Warning: The parameter is not a valid shm_indentifier in ...

I am using shared memory in a production environment at it is very
important that someone gives me a feedback.

There were no problems with shmem on php4 but this time its buggy.






Edit this bug report at http://bugs.php.net/?id=14921&edit=1


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #14905 Updated: open() does not accept other ports than 80

2002-01-07 Thread edink 

ID: 14905
Updated by: edink
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Feedback
Bug Type: URL related
Operating System: Linux
PHP Version: 4.1.0
New Comment:

I cannot reproduce this problem. This example:

$infile = file
("http://scpno.proventum.net:8087/index.php?context=10";);
print implode("", $infile);

works fine for me. Could you please provide us with 
a publicly available URL that does not work.

Previous Comments:


[2002-01-07 06:59:23] [EMAIL PROTECTED]

Although mentioned in the bug database that this has been fixed, the
4.1.0 does not accept this:

$infile = file('http://127.0.0.1:/servlet/MyServlet?mode=get');

When will port numbers be available for open/fopen()

Maximilian Eberl

mailto:[EMAIL PROTECTED]





Edit this bug report at http://bugs.php.net/?id=14905&edit=1


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #14214 Updated: getcwd() and `pwd` return wrong directory

2002-01-07 Thread edink 

ID: 14214
Updated by: edink
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: Filesystem function related
Operating System: Linux
PHP Version: 4.0.6
New Comment:

For a descrioption of a problem and a solution
plaese see: http://bugs.php.net/bug.php?id=14839

Previous Comments:


[2002-01-07 02:22:47] [EMAIL PROTECTED]

Closed it should be.



[2001-12-17 07:14:32] [EMAIL PROTECTED]

No feedback. Closing.



[2001-11-26 02:44:36] [EMAIL PROTECTED]

What is your configure line?

Derick



[2001-11-24 18:47:19] [EMAIL PROTECTED]

I've written a small shell script in PHP, which should return the
current working directory:

-
#!/usr/bin/php -q

-

I've stored the script as /scripts/test.php and on the shell, I'm in
/scripts/Testing.  When I run the script with »../test.php«, it returns
»/scripts« two times.  I'd expect it to return »/scripts/Testing« two
times.

However, HTTP_ENV_VARS['PWD'] and HTTP_SERVER_VARS['PWD'] both contain
the correct (ie. /scripts/Testing) path.





Edit this bug report at http://bugs.php.net/?id=14214&edit=1


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #14819 Updated: str_replace used with serialize

2002-01-05 Thread edink 

ID: 14819
Updated by: edink
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Feedback
Bug Type: Strings related
Operating System: Linux
PHP Version: 4.0.5
New Comment:

Cannot reporoduce this:

$mystring="don't";
$myarray[ 0 ] = "s1";
$myarray[ 1 ] = "s2";
$myarray[ 2 ] = str_replace( "'", "", $mystring );
$myserial = serialize( $myarray );
print $myserial."\n";

prints correctly:

a:3:{i:0;s:2:"s1";i:1;s:2:"s2";i:2;s:4:"dont";}

in PHP 4.0.5, PHP 4.1.1, adn PHP 4.2.0-dev.

Does this example work for you? If it does
could you please provide a complete example
that produces incorrect output.


Previous Comments:


[2002-01-04 20:55:32] [EMAIL PROTECTED]

Here are my configuration options:

'./configure' '--prefix=/usr/local'
'--with-apache=/usr/local/src/Apachetoolbox-1.5.19/apache_1.3.19'
'--enable-exif' '--enable-memory-limit=yes' '--enable-track-vars'
'--with-calendar=shared' '--enable-safe-mode' '--enable-magic-quotes'
'--enable-trans-sid' '--enable-wddx' '--enable-ftp' '--with-mysql'
'--with-mysql=/usr/local/mysql' '--with-openssl'




[2002-01-03 03:56:56] [EMAIL PROTECTED]

Status -> feedback



[2002-01-03 01:28:09] [EMAIL PROTECTED]

Just tested it with 4.0.6 and 4.1.0
All seems to be ok.

Can you send me your configuration options?





[2002-01-02 23:49:09] [EMAIL PROTECTED]

Two lines like this:
$myarray[ 2 ] = str_replace( "'", "", $mystring );
$myserial = serialize( $myarray );

produce a serialized array in $myserial but it contains the wrong length
or sometimes the wrong value for the string I inserted.  It sometimes
deletes the "'" and the following character, sometimes deletes just the
"'" but has the wrong length of the string encoded in the serialized
variable.  

An example of $myserial would be:
a:3:{i:0;s:2:"s1";i:1;s:2:"s2";i:2;s:5:"dont";} 
Which encodes the wrong length for the final string.

It works correctly when I break it into three lines:
$mystring = str_replace( "'", "", $mystring );
$myarray[ 2 ] = $mystring;
$myserial = serialize( $myarray );

An example of $myserial would be:
a:3:{i:0;s:2:"s1";i:1;s:2:"s2";i:2;s:4:"dont";} 
Which encodes the correct length for the final string.

This only appears to happen if there is a str_replace match in the
string.  If there is no match for the str_replace function, the glitch
doesn't seem to appear.  Thanks.





Edit this bug report at http://bugs.php.net/?id=14819&edit=1


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #14839 Updated: getcwd() and `pwd` report incorrect directory

2002-01-04 Thread edink 

ID: 14839
Updated by: edink
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Closed
Bug Type: *Directory/Filesystem functions
Operating System: Linux, FreeBSD, Solaris
PHP Version: 4.0.5
New Comment:

Closing the report.

Previous Comments:


[2002-01-04 05:01:54] [EMAIL PROTECTED]

There is nothing wrong with getcwd(). The problem
is that php changes current working directory to 
the script's.

This makes sense if you think of CGI scripts,
but makes no sense if you write command line programs.

That's way a new command line switch (-C) was introduced
in PHP 4.1.0 which prevents PHP from chdir'ing into
script's directory.

So changing the first line of your script to

#!/usr/local/bin/php -qC

(and upgrading to 4.1) should fix the problem.




[2002-01-04 00:47:58] [EMAIL PROTECTED]

Ok, some comments, if i may.

Firstly, I have verified this behaviour, however (and I could be wrong),
this is not unexpected.

The script executes relavtive to the directory it exists 
within, not the directory you are currently in. 

I can't particularly explain why, but this kind of makes sense. If you
had a script in some unsafe directory, allowing the moving and deleting
of files, and you could run it in a secured directory, in which the php
process had sufficient access, and affect the files there, would that
not present potential security risks?

Anyhow, i could be wrong, so don't take what i said as corret.



[2002-01-04 00:22:32] [EMAIL PROTECTED]

Oh, I suppose you want my configure line, even though it really doesn't
make a difference.  Here it is:

CONFIGURE_COMMAND = './configure' '--with-gd=/usr/local' '--with-mysql'
'--with-openssl' '--with-apxs=/usr/local/sbin/apxs'
'--prefix=/usr/local'



[2002-01-04 00:16:48] [EMAIL PROTECTED]

This problem was previously reported by someone against PHP 4.0.6 in Bug
ID # 14214.  Latest comment on the that reports says they are going to
close it for lack of information.

This bug has existed in every version of PHP I've used since 1999.  It
fails on Linux, FreeBSD and Solaris.

Both mistaken report the directory which contains the script being run,
NOT the current working directory.

This fails when run from a directory other than where the script is
saved:

#! /usr/local/bin/php -q


Under any POSIX-compliant OS, or just about any version of Unix, calling
the getcwd(3) library routine should get the correct result.  It appears
the PHP interpreter startup is changing directories without saving this
value first, since even calling the OS gives incorrect values.





Edit this bug report at http://bugs.php.net/?id=14839&edit=1


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #14839 Updated: getcwd() and `pwd` report incorrect directory

2002-01-04 Thread edink 

ID: 14839
Updated by: edink
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: *Directory/Filesystem functions
Operating System: Linux, FreeBSD, Solaris
PHP Version: 4.0.5
New Comment:

There is nothing wrong with getcwd(). The problem
is that php changes current working directory to 
the script's.

This makes sense if you think of CGI scripts,
but makes no sense if you write command line programs.

That's way a new command line switch (-C) was introduced
in PHP 4.1.0 which prevents PHP from chdir'ing into
script's directory.

So changing the first line of your script to

#!/usr/local/bin/php -qC

(and upgrading to 4.1) should fix the problem.


Previous Comments:


[2002-01-04 00:47:58] [EMAIL PROTECTED]

Ok, some comments, if i may.

Firstly, I have verified this behaviour, however (and I could be wrong),
this is not unexpected.

The script executes relavtive to the directory it exists 
within, not the directory you are currently in. 

I can't particularly explain why, but this kind of makes sense. If you
had a script in some unsafe directory, allowing the moving and deleting
of files, and you could run it in a secured directory, in which the php
process had sufficient access, and affect the files there, would that
not present potential security risks?

Anyhow, i could be wrong, so don't take what i said as corret.



[2002-01-04 00:22:32] [EMAIL PROTECTED]

Oh, I suppose you want my configure line, even though it really doesn't
make a difference.  Here it is:

CONFIGURE_COMMAND = './configure' '--with-gd=/usr/local' '--with-mysql'
'--with-openssl' '--with-apxs=/usr/local/sbin/apxs'
'--prefix=/usr/local'



[2002-01-04 00:16:48] [EMAIL PROTECTED]

This problem was previously reported by someone against PHP 4.0.6 in Bug
ID # 14214.  Latest comment on the that reports says they are going to
close it for lack of information.

This bug has existed in every version of PHP I've used since 1999.  It
fails on Linux, FreeBSD and Solaris.

Both mistaken report the directory which contains the script being run,
NOT the current working directory.

This fails when run from a directory other than where the script is
saved:

#! /usr/local/bin/php -q


Under any POSIX-compliant OS, or just about any version of Unix, calling
the getcwd(3) library routine should get the correct result.  It appears
the PHP interpreter startup is changing directories without saving this
value first, since even calling the OS gives incorrect values.





Edit this bug report at http://bugs.php.net/?id=14839&edit=1


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #14842 Updated: fopen

2002-01-04 Thread edink 

ID: 14842
Updated by: edink
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Feedback
Bug Type: *URL Functions
Operating System: linux red hat7.2
PHP Version: 4.1.1
New Comment:

I cannot reproduce this.
Could you be more specific about the problem. Do you get any error
messages?

Previous Comments:


[2002-01-04 01:49:59] [EMAIL PROTECTED]

$file="http://s105.now.net.cn/try.php";;
fopen ($file, "r")
it is okay 
but when I change to port to 81 
I test it okay in browser  but 
$file="http://s105.now.net.cn:81/try.php";;
fopen ($file, "r")
can't work 
it seems that it still in port 80 
it's a bug ?








Edit this bug report at http://bugs.php.net/?id=14842&edit=1


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #10996 Updated: fopen of url results in invlaid file handle

2001-12-17 Thread edink 

ID: 10996
Updated by: edink
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Closed
Bug Type: Filesystem function related
Operating System: linux
PHP Version: 4.0.5
New Comment:

This has been fixed in PHP 4.1.0

Previous Comments:


[2001-12-17 02:32:49] [EMAIL PROTECTED]

tested this with 4.2.0-dev and appears to be fixed.

could somebody check with 4.1.0?




[2001-05-21 14:41:53] [EMAIL PROTECTED]

Reproduced with PHP 4.0.6RC1.

--Jani





[2001-05-21 14:19:26] [EMAIL PROTECTED]

#!/usr/local/bin/php
http://cnn.com";, "r");
$text2 = fread($fp2, 100);
fclose($fp2);
?>

CGI version of php 4.0.5 (4.0.2 did the same too) with default "./configure"

default php.ini too

The URL fopen usually goes through (meaning the server of the called URL usually gets 
the request), but the response is unreadable since the file-handle isn't valid. If I'm 
missing something totally obvious I apologize in advance. Thanks so much. 
-Graham Warden






Edit this bug report at http://bugs.php.net/?id=10996&edit=1


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #14152 Updated: foreach() can create objects with blank property names

2001-11-22 Thread edink 

ID: 14152
Updated by: edink
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Class/Object related
Operating System: Linux 2.2.16-enterprise
PHP Version: 4.0.5
New Comment:

Much easier to reproduce by:

$a->$b="c";

Foreach loop should of course read

foreach($myarray as $key=>$value)


Previous Comments:


[2001-11-20 13:22:53] [EMAIL PROTECTED]

Using the following code (which someone may do accidentally):

$myarray = array("X" => "A", "Y" => "B", "Z" => "C");
foreach($myarray as $key->$value) {
  ...
}

causes PHP (on each iteration) to create an object $key with the value of the current 
array element in a property with a blank name (because $value has just been created, 
and is therefore empty).

The following var_dump() output illustrates:

object(stdClass)(1) {
  [""]=>
  string(1) "A"
}

The creation of objects with blank property names seems like it shouldn't be possible 
(even unintentionally)!





Edit this bug report at http://bugs.php.net/?id=14152&edit=1


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #13836 Updated: With Apache multiview support, $HTTP_GET_VARS always NULL

2001-10-26 Thread edink 

ID: 13836
Updated by: edink
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Duplicate
Bug Type: Apache related
Operating System: Windows 2000
PHP Version: 4.0.6
New Comment:

Already reported (and probably Apache bug):

http://bugs.apache.org/index.cgi/full/8582
http://bugs.php.net/bug.php?id=13704

Previous Comments:


[2001-10-26 07:41:30] [EMAIL PROTECTED]

PHP 4.0.6 WIN32 precompiled binary
Apache 1.3.22 WIN32 precompiled binary
Apache has content negotiation (multiview) enabled

test script: test.php 

if I access the file via

http://localhost/test.php?i=1, it works

but if I use

http://localhost/test?i=1, $HTTP_GET_VARS becomes null






Edit this bug report at http://bugs.php.net/?id=13836&edit=1


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #13512 Updated: The backtick operator only returns stdout, not stderr

2001-10-04 Thread edink 

ID: 13512
Updated by: edink
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Closed
Bug Type: Feature/Change Request
Operating System: FreeBSD
PHP Version: 4.0.5
New Comment:

What you want can be probably be achieved with:

$output = `command 2>&1`;


Previous Comments:


[2001-10-02 10:27:43] [EMAIL PROTECTED]

If I use the backtick operator, like:

 $output = `command goes here`;

and if the program 'command' returns its output to stderr and not stdout, then it's 
not easy to get the output.

Right now, it can be solved by adding:

 2> /tmp/file/here

and then reading the file in the script, but that's not a good solution.





Edit this bug report at http://bugs.php.net/?id=13512&edit=1


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #13145 Updated: Postgres module ignores php.ini

2001-09-08 Thread edink 

ID: 13145
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Closed
Bug Type: PostgreSQL related
Operating System: Linux (Redhat 6.2)
PHP Version: 4.0.6
New Comment:

Bitten by the fact that php looks for php.ini in the / directory first. So beware that 
you don't have one there, php will ignore all other php.ini location specifications 
(env PHPRC, configure paramaters)...

Previous Comments:


[2001-09-05 03:57:43] [EMAIL PROTECTED]

Postgres module ignores php.ini pgsql.* directives when compiled and loaded as dso.





Edit this bug report at http://bugs.php.net/?id=13145&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #13145: Postgres module ignores php.ini

2001-09-05 Thread edink 

From: [EMAIL PROTECTED]
Operating system: Linux (Redhat 6.2)
PHP version:  4.0.6
PHP Bug Type: PostgreSQL related
Bug description:  Postgres module ignores php.ini

Postgres module ignores php.ini pgsql.* directives when compiled and loaded
as dso.
-- 
Edit bug report at: http://bugs.php.net/?id=13145&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #12909 Updated: CGI sapi compilation fails

2001-08-28 Thread edink 

ID: 12909
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Compile Failure
Old Operating System: RedHat Linux 6.2
Operating System: RedHat Linux 6.2-7.1
PHP Version: 4.0CVS-2001-08-22
New Comment:

It seems that extensions as dso's and cgi sapi don't mix well in PHP 4.0.7 RC1.

I've tried to reduce the example to the smallest possible:

So this is what I do:

1. CVS checkout of PHP_4_0_7 branch
2. ./buildconf
3. ./configure \
--with-recode=shared \
--without-mysql \
--without-gd \
--without-xml \
4. make

I get the compilation error:

Making all in .
make[1]: Entering directory `/home/ek/compile/cvs-php'
gcc -I. -I/home/ek/compile/cvs-php/ -I/home/ek/compile/cvs-php/main 
-I/home/ek/compile/cvs-php -I/home/ek/compile/cvs-php/Zend  
-I/home/ek/compile/cvs-php/TSRM -g -O2  -c stub.c && touch stub.lo
/bin/sh /home/ek/compile/cvs-php/libtool --silent --mode=link gcc -I. 
-I/home/ek/compile/cvs-php/ -I/home/ek/compile/cvs-php/main -I/home/ek/compile/cvs-php 
-I/home/ek/compile/cvs-php/Zend  -I/home/ek/compile/cvs-php/TSRM -g -O2   -o 
libphp4.la -rpath /home/ek/compile/cvs-php/libsstub.lo  Zend/libZend.la 
sapi/cgi/libsapi.la main/libmain.la regex/libregex.la ext/pcre/libpcre.la 
ext/posix/libposix.la ext/session/libsession.la ext/standard/libstandard.la 
TSRM/libtsrm.la -lpam -ldl -lcrypt -lresolv -lm -ldl -lnsl -lresolv -lcrypt
stub.lo: file not recognized: File truncated
collect2: ld returned 1 exit status
make[1]: *** [libphp4.la] Error 1
make[1]: Leaving directory `/home/ek/compile/cvs-php'
make: *** [all-recursive] Error 1

Previous Comments:


[2001-08-22 15:56:08] [EMAIL PROTECTED]

./configure \
--prefix=/data/php \
--with-config-file-path=/data/php \
--disable-debug \
--enable-sigchild 
--disable-magic-quotes \
--disable-short-tags \
--enable-dba=shared \
--with-gdbm=shared,/usr \
--enable-ftp=shared \
--with-gd=shared,/usr \
--with-gettext=shared,/usr \
--with-mysql=shared,/usr/local/mysql \
--with-oci8=shared,/ora01/app/oracle/product/8.1.6 \
--with-pcre-regex=shared \
--with-pgsql=shared,/usr \
--with-recode=shared,/usr \
--enable-shmop \
--with-regex=system \
--enable-sysvsem \
--enable-sysvshm \
--disable-memory-limit \
--with-ldap=shared,/ora01/app/oracle/product/8.1.6/ \
--with-imap=shared,/data/src/imap \
--with-zlib=shared,/usr \
--enable-sockets=shared \
--with-apxs=/data/apache/bin/apxs



[2001-08-22 15:47:42] [EMAIL PROTECTED]

And your configure line was..?

--Jani




[2001-08-22 15:40:24] [EMAIL PROTECTED]

I did a checkout with -r PHP_4_0_7 so I'm talking about that branch of the cvs tree.

The error message:

Making all in .
make[1]: Entering directory `/data/src/cvs-php'
gcc -I. -I/data/src/cvs-php/ -I/data/src/cvs-php/main -I/data/src/cvs-php 
-I/data/src/cvs-php/Zend -I/data/src/imap/c-client 
-I/ora01/app/oracle/product/8.1.6//ldap/public -I/usr/local/mysql/include/mysql 
-I/ora01/app/oracle/product/8.1.6/rdbms/public 
-I/ora01/app/oracle/product/8.1.6/rdbms/demo 
-I/ora01/app/oracle/product/8.1.6/network/public -I/data/src/cvs-php/ext/xml/expat  
-I/data/src/cvs-php/TSRM -g -O2  -c stub.c && touch stub.lo
/bin/sh /data/src/cvs-php/libtool --silent --mode=link gcc -I. -I/data/src/cvs-php/ 
-I/data/src/cvs-php/main -I/data/src/cvs-php -I/data/src/cvs-php/Zend 
-I/data/src/imap/c-client -I/ora01/app/oracle/product/8.1.6//ldap/public 
-I/usr/local/mysql/include/mysql -I/ora01/app/oracle/product/8.1.6/rdbms/public 
-I/ora01/app/oracle/product/8.1.6/rdbms/demo 
-I/ora01/app/oracle/product/8.1.6/network/public -I/data/src/cvs-php/ext/xml/expat
 -I/data/src/cvs-php/TSRM -g -O2   -o libphp4.la -rpath /data/src/cvs-php/libs
stub.lo  Zend/libZend.la sapi/cgi/libsapi.la main/libmain.la  ext/posix/libposix.la 
ext/session/libsession.la ext/shmop/libshmop.la ext/standard/libstandard.la 
ext/sysvsem/libsysvsem.la ext/sysvshm/libsysvshm.la ext/xml/libxml.la TSRM/libtsrm.la 
-lpam -ldl -lcrypt -lpam -lgd -lcrypt -lresolv -lm -ldl -lnsl -lresolv -lcrypt
stub.lo: file not recognized: File truncated
collect2: ld returned 1 exit status
make[1]: *** [libphp4.la] Error 1
make[1]: Leaving directory `/data/src/cvs-php'
make: *** [all-recursive] Error 1

builconf says:

./buildconf
buildconf: checking installation...
buildconf: autoconf version 2.13 (ok)
buildconf: automake version 1.4 (ok)
buildconf: libtool version 1.4 (ok)
rebuilding Makefile templates
automake: configure.in: installing `Zend/ylwrap'
rebuilding configure
rebuilding acconfig.h
rebuilding main/php_config.h.in

Apache sapi version compiles and builds fine





Edit this bug report at http://bugs.php.net/?id=129

[PHP-DEV] Bug #12909 Updated: CGI sapi compilation fails

2001-08-22 Thread edink 

ID: 12909
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Open
Bug Type: Compile Failure
Operating System: RedHat Linux 6.2
PHP Version: 4.0CVS-2001-08-22
New Comment:

./configure \
--prefix=/data/php \
--with-config-file-path=/data/php \
--disable-debug \
--enable-sigchild 
--disable-magic-quotes \
--disable-short-tags \
--enable-dba=shared \
--with-gdbm=shared,/usr \
--enable-ftp=shared \
--with-gd=shared,/usr \
--with-gettext=shared,/usr \
--with-mysql=shared,/usr/local/mysql \
--with-oci8=shared,/ora01/app/oracle/product/8.1.6 \
--with-pcre-regex=shared \
--with-pgsql=shared,/usr \
--with-recode=shared,/usr \
--enable-shmop \
--with-regex=system \
--enable-sysvsem \
--enable-sysvshm \
--disable-memory-limit \
--with-ldap=shared,/ora01/app/oracle/product/8.1.6/ \
--with-imap=shared,/data/src/imap \
--with-zlib=shared,/usr \
--enable-sockets=shared \
--with-apxs=/data/apache/bin/apxs

Previous Comments:


[2001-08-22 15:47:42] [EMAIL PROTECTED]

And your configure line was..?

--Jani




[2001-08-22 15:40:24] [EMAIL PROTECTED]

I did a checkout with -r PHP_4_0_7 so I'm talking about that branch of the cvs tree.

The error message:

Making all in .
make[1]: Entering directory `/data/src/cvs-php'
gcc -I. -I/data/src/cvs-php/ -I/data/src/cvs-php/main -I/data/src/cvs-php 
-I/data/src/cvs-php/Zend -I/data/src/imap/c-client 
-I/ora01/app/oracle/product/8.1.6//ldap/public -I/usr/local/mysql/include/mysql 
-I/ora01/app/oracle/product/8.1.6/rdbms/public 
-I/ora01/app/oracle/product/8.1.6/rdbms/demo 
-I/ora01/app/oracle/product/8.1.6/network/public -I/data/src/cvs-php/ext/xml/expat  
-I/data/src/cvs-php/TSRM -g -O2  -c stub.c && touch stub.lo
/bin/sh /data/src/cvs-php/libtool --silent --mode=link gcc -I. -I/data/src/cvs-php/ 
-I/data/src/cvs-php/main -I/data/src/cvs-php -I/data/src/cvs-php/Zend 
-I/data/src/imap/c-client -I/ora01/app/oracle/product/8.1.6//ldap/public 
-I/usr/local/mysql/include/mysql -I/ora01/app/oracle/product/8.1.6/rdbms/public 
-I/ora01/app/oracle/product/8.1.6/rdbms/demo 
-I/ora01/app/oracle/product/8.1.6/network/public -I/data/src/cvs-php/ext/xml/expat
 -I/data/src/cvs-php/TSRM -g -O2   -o libphp4.la -rpath /data/src/cvs-php/libs
stub.lo  Zend/libZend.la sapi/cgi/libsapi.la main/libmain.la  ext/posix/libposix.la 
ext/session/libsession.la ext/shmop/libshmop.la ext/standard/libstandard.la 
ext/sysvsem/libsysvsem.la ext/sysvshm/libsysvshm.la ext/xml/libxml.la TSRM/libtsrm.la 
-lpam -ldl -lcrypt -lpam -lgd -lcrypt -lresolv -lm -ldl -lnsl -lresolv -lcrypt
stub.lo: file not recognized: File truncated
collect2: ld returned 1 exit status
make[1]: *** [libphp4.la] Error 1
make[1]: Leaving directory `/data/src/cvs-php'
make: *** [all-recursive] Error 1

builconf says:

./buildconf
buildconf: checking installation...
buildconf: autoconf version 2.13 (ok)
buildconf: automake version 1.4 (ok)
buildconf: libtool version 1.4 (ok)
rebuilding Makefile templates
automake: configure.in: installing `Zend/ylwrap'
rebuilding configure
rebuilding acconfig.h
rebuilding main/php_config.h.in

Apache sapi version compiles and builds fine





Edit this bug report at http://bugs.php.net/?id=12909&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #12909: CGI sapi compilation fails

2001-08-22 Thread edink 

From: [EMAIL PROTECTED]
Operating system: RedHat Linux 6.2
PHP version:  4.0CVS-2001-08-22
PHP Bug Type: Compile Failure
Bug description:  CGI sapi compilation fails

I did a checkout with -r PHP_4_0_7 so I'm talking about that branch of the
cvs tree.

The error message:

Making all in .
make[1]: Entering directory `/data/src/cvs-php'
gcc -I. -I/data/src/cvs-php/ -I/data/src/cvs-php/main -I/data/src/cvs-php
-I/data/src/cvs-php/Zend -I/data/src/imap/c-client
-I/ora01/app/oracle/product/8.1.6//ldap/public
-I/usr/local/mysql/include/mysql
-I/ora01/app/oracle/product/8.1.6/rdbms/public
-I/ora01/app/oracle/product/8.1.6/rdbms/demo
-I/ora01/app/oracle/product/8.1.6/network/public
-I/data/src/cvs-php/ext/xml/expat  -I/data/src/cvs-php/TSRM -g -O2  -c
stub.c && touch stub.lo
/bin/sh /data/src/cvs-php/libtool --silent --mode=link gcc -I.
-I/data/src/cvs-php/ -I/data/src/cvs-php/main -I/data/src/cvs-php
-I/data/src/cvs-php/Zend -I/data/src/imap/c-client
-I/ora01/app/oracle/product/8.1.6//ldap/public
-I/usr/local/mysql/include/mysql
-I/ora01/app/oracle/product/8.1.6/rdbms/public
-I/ora01/app/oracle/product/8.1.6/rdbms/demo
-I/ora01/app/oracle/product/8.1.6/network/public
-I/data/src/cvs-php/ext/xml/expat
 -I/data/src/cvs-php/TSRM -g -O2   -o libphp4.la -rpath
/data/src/cvs-php/libsstub.lo  Zend/libZend.la sapi/cgi/libsapi.la
main/libmain.la  ext/posix/libposix.la ext/session/libsession.la
ext/shmop/libshmop.la ext/standard/libstandard.la ext/sysvsem/libsysvsem.la
ext/sysvshm/libsysvshm.la ext/xml/libxml.la TSRM/libtsrm.la -lpam -ldl
-lcrypt -lpam -lgd -lcrypt -lresolv -lm -ldl -lnsl -lresolv -lcrypt
stub.lo: file not recognized: File truncated
collect2: ld returned 1 exit status
make[1]: *** [libphp4.la] Error 1
make[1]: Leaving directory `/data/src/cvs-php'
make: *** [all-recursive] Error 1

builconf says:

./buildconf
buildconf: checking installation...
buildconf: autoconf version 2.13 (ok)
buildconf: automake version 1.4 (ok)
buildconf: libtool version 1.4 (ok)
rebuilding Makefile templates
automake: configure.in: installing `Zend/ylwrap'
rebuilding configure
rebuilding acconfig.h
rebuilding main/php_config.h.in

Apache sapi version compiles and builds fine
-- 
Edit bug report at: http://bugs.php.net/?id=12909&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #11554 Updated: Apache processes get stuck

2001-06-20 Thread edink 

ID: 11554
User Update by: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Closed
Bug Type: PostgreSQL related
Operating system: Linux 2.2 (RH 7.0)
PHP Version: 4.0.5
Description: Apache processes get stuck

It has indeed been fixed. 4.0.6RC4 runs fine.

Previous Comments:
---

[2001-06-19 21:21:04] [EMAIL PROTECTED]
Please try the latest RC of PHP 4.0.6:

http://www.php.net/~andi/php-4.0.6RC4.tar.gz

I believe this is already fixed..


---

[2001-06-19 08:38:50] [EMAIL PROTECTED]
I forgot to say that php is compiled as dso with apache 1.3.19. I have tried to 
compile postgresql extension both as php dso and to compile it into the php module, 
with the same result.

---

[2001-06-19 05:05:17] [EMAIL PROTECTED]
After adding PostgreSQL module to an Apache webserver, the load on the machine went up 
to 20. There was no PostgreSQL code invoved, just pgsql.so was activated in php.ini. 
Here is the backtrace of a runaway process:

#0  0x4068eb1a in pqFlush () from /usr/lib/libpq.so.2
#1  0x4068e25a in pqPutBytes () from /usr/lib/libpq.so.2
#2  0x4068e475 in pqPutnchar () from /usr/lib/libpq.so.2
#3  0x4068c3b3 in PQsendQuery () from /usr/lib/libpq.so.2
#4  0x4068ceb0 in PQexec () from /usr/lib/libpq.so.2
#5  0x40678d33 in _rollback_transactions (rsrc=0x81738f8) at pgsql.c:168
#6  0x4029a556 in zend_hash_apply (ht=0x4033a834, apply_func=0x40678d00 
<_rollback_transactions>)
at zend_hash.c:692
#7  0x40678f48 in php_rshutdown_pgsql (type=1, module_number=20) at pgsql.c:246
#8  0x402972b9 in module_registry_cleanup (module=0x81506a8) at zend_API.c:785
#9  0x4029a556 in zend_hash_apply (ht=0x4033a9e0, apply_func=0x4029728c 
)
at zend_hash.c:692
#10 0x40296420 in zend_deactivate_modules () at zend.c:522
#11 0x402a748c in php_request_shutdown (dummy=0x0) at main.c:670
#12 0x402a4fb9 in php_apache_request_shutdown (dummy=0x0) at mod_php4.c:290
#13 0x8051374 in run_cleanups ()
#14 0x804fb76 in ap_clear_pool ()
#15 0x804fbf6 in ap_destroy_pool ()
#16 0x80600b5 in child_main ()
#17 0x80602cf in make_child ()
#18 0x8060380 in startup_children ()
#19 0x80609cd in standalone_main ()
#20 0x806120f in main ()

PHP 4.0.5
PostgreSQL 7.1
RedHat Linux 7.0

---


Full Bug description available at: http://bugs.php.net/?id=11554


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #11554 Updated: Apache processes get stuck

2001-06-19 Thread edink 

ID: 11554
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: PostgreSQL related
Operating system: Linux 2.2 (RH 7.0)
PHP Version: 4.0.5
Description: Apache processes get stuck

I forgot to say that php is compiled as dso with apache 1.3.19. I have tried to 
compile postgresql extension both as php dso and to compile it into the php module, 
with the same result.

Previous Comments:
---

[2001-06-19 05:05:17] [EMAIL PROTECTED]
After adding PostgreSQL module to an Apache webserver, the load on the machine went up 
to 20. There was no PostgreSQL code invoved, just pgsql.so was activated in php.ini. 
Here is the backtrace of a runaway process:

#0  0x4068eb1a in pqFlush () from /usr/lib/libpq.so.2
#1  0x4068e25a in pqPutBytes () from /usr/lib/libpq.so.2
#2  0x4068e475 in pqPutnchar () from /usr/lib/libpq.so.2
#3  0x4068c3b3 in PQsendQuery () from /usr/lib/libpq.so.2
#4  0x4068ceb0 in PQexec () from /usr/lib/libpq.so.2
#5  0x40678d33 in _rollback_transactions (rsrc=0x81738f8) at pgsql.c:168
#6  0x4029a556 in zend_hash_apply (ht=0x4033a834, apply_func=0x40678d00 
<_rollback_transactions>)
at zend_hash.c:692
#7  0x40678f48 in php_rshutdown_pgsql (type=1, module_number=20) at pgsql.c:246
#8  0x402972b9 in module_registry_cleanup (module=0x81506a8) at zend_API.c:785
#9  0x4029a556 in zend_hash_apply (ht=0x4033a9e0, apply_func=0x4029728c 
)
at zend_hash.c:692
#10 0x40296420 in zend_deactivate_modules () at zend.c:522
#11 0x402a748c in php_request_shutdown (dummy=0x0) at main.c:670
#12 0x402a4fb9 in php_apache_request_shutdown (dummy=0x0) at mod_php4.c:290
#13 0x8051374 in run_cleanups ()
#14 0x804fb76 in ap_clear_pool ()
#15 0x804fbf6 in ap_destroy_pool ()
#16 0x80600b5 in child_main ()
#17 0x80602cf in make_child ()
#18 0x8060380 in startup_children ()
#19 0x80609cd in standalone_main ()
#20 0x806120f in main ()

PHP 4.0.5
PostgreSQL 7.1
RedHat Linux 7.0

---


Full Bug description available at: http://bugs.php.net/?id=11554


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #11554: Apache processes get stuck

2001-06-19 Thread edink 

From: [EMAIL PROTECTED]
Operating system: Linux 2.2 (RH 7.0)
PHP version:  4.0.5
PHP Bug Type: PostgreSQL related
Bug description:  Apache processes get stuck

After adding PostgreSQL module to an Apache webserver, the load on the machine went up 
to 20. There was no PostgreSQL code invoved, just pgsql.so was activated in php.ini. 
Here is the backtrace of a runaway process:

#0  0x4068eb1a in pqFlush () from /usr/lib/libpq.so.2
#1  0x4068e25a in pqPutBytes () from /usr/lib/libpq.so.2
#2  0x4068e475 in pqPutnchar () from /usr/lib/libpq.so.2
#3  0x4068c3b3 in PQsendQuery () from /usr/lib/libpq.so.2
#4  0x4068ceb0 in PQexec () from /usr/lib/libpq.so.2
#5  0x40678d33 in _rollback_transactions (rsrc=0x81738f8) at pgsql.c:168
#6  0x4029a556 in zend_hash_apply (ht=0x4033a834, apply_func=0x40678d00 
<_rollback_transactions>)
at zend_hash.c:692
#7  0x40678f48 in php_rshutdown_pgsql (type=1, module_number=20) at pgsql.c:246
#8  0x402972b9 in module_registry_cleanup (module=0x81506a8) at zend_API.c:785
#9  0x4029a556 in zend_hash_apply (ht=0x4033a9e0, apply_func=0x4029728c 
)
at zend_hash.c:692
#10 0x40296420 in zend_deactivate_modules () at zend.c:522
#11 0x402a748c in php_request_shutdown (dummy=0x0) at main.c:670
#12 0x402a4fb9 in php_apache_request_shutdown (dummy=0x0) at mod_php4.c:290
#13 0x8051374 in run_cleanups ()
#14 0x804fb76 in ap_clear_pool ()
#15 0x804fbf6 in ap_destroy_pool ()
#16 0x80600b5 in child_main ()
#17 0x80602cf in make_child ()
#18 0x8060380 in startup_children ()
#19 0x80609cd in standalone_main ()
#20 0x806120f in main ()

PHP 4.0.5
PostgreSQL 7.1
RedHat Linux 7.0


-- 
Edit Bug report at: http://bugs.php.net/?id=11554&edit=1



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9730: When following redirects, username and password ignored

2001-03-13 Thread edink 

From: [EMAIL PROTECTED]
Operating system: Linux
PHP version:  4.0 Latest CVS (13/03/2001)
PHP Bug Type: *URL Functions
Bug description:  When following redirects, username and password ignored

fopen() and friends when opening "http://user:pass@site"  do not send username and 
password when following a redirect.

This patch would solve the problem:

Index: http_fopen_wrapper.c
===
RCS file: /repository/php4/ext/standard/http_fopen_wrapper.c,v
retrieving revision 1.7
diff -u -3 -p -r1.7 http_fopen_wrapper.c
--- http_fopen_wrapper.c2001/02/26 06:07:17 1.7
+++ http_fopen_wrapper.c2001/03/13 18:45:50
@@ -71,9 +71,9 @@
 FILE *php_fopen_url_wrap_http(char *path, char *mode, int options, int *issock, int 
*socketd, char **opened_path)
 {
FILE *fp=NULL;
-   php_url *resource=NULL;
+   php_url *resource=NULL, *resource_new=NULL;
char tmp_line[128];
-   char location[512];
+   char location[512], location_new[512];
char hdr_line[8192];
int body = 0;
char *scratch;
@@ -269,12 +269,42 @@ FILE *php_fopen_url_wrap_http(char *path
if (!reqok) {
SOCK_FCLOSE(*socketd);
*socketd = 0;
-   free_url(resource);
if (location[0] != '\0') {
zval **response_header_new, *entry, **entryp;
+
+   if (resource->user == NULL || resource->pass == NULL) {
+ strcpy(location_new, location);
+   } else {   /* we have username and password */
+ resource_new = url_parse((char *) location);
+ if (resource_new == NULL) {
+   php_error(E_WARNING, "Invalid redirect URL, %s", location);
+   *issock = BAD_URL;
+   free_url(resource);
+   return NULL;
+ }
+
+ /* use port 80 if one wasn't specified */
+ if (resource_new->port == 0) {
+   resource_new->port = 80;
+ }
+
+ snprintf (location_new, sizeof(location_new), 
+"http://%s:%s@%s:%d", resource->user, resource->pass, resource_new->host, 
+resource_new->port);
+
+ if (resource_new->path != NULL) {
+   strlcat (location_new, resource_new->path, sizeof 
+(location_new));
+ }
+ if (resource_new->query != NULL) {
+   strlcat (location_new, "?", sizeof(location_new));
+   strlcat (location_new, resource_new->query , 
+sizeof(location_new));
+ }
+ free_url(resource_new);
+   }
+
+
+   free_url(resource);
ELS_FETCH();
 
-   fp = php_fopen_url_wrap_http(location, mode, options, issock, 
socketd, opened_path);
+   fp = php_fopen_url_wrap_http(location_new, mode, options, 
+issock, socketd, opened_path);
if (zend_hash_find(EG(active_symbol_table), 
"http_response_header", sizeof("http_response_header"), (void **) 
&response_header_new) == SUCCESS) {
entryp = &entry;
MAKE_STD_ZVAL(entry);
@@ -289,6 +319,7 @@ FILE *php_fopen_url_wrap_http(char *path
}
goto out;
} else {
+   free_url(resource);
fp = NULL;
goto out;
}



-- 
Edit Bug report at: http://bugs.php.net/?id=9730&edit=1



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]