[PHP-DEV] PHP 4.0 Bug #9540: Dumping html files to error log

[shane]

From: [EMAIL PROTECTED]
Operating system: Linux
PHP version:  4.0.4pl1
PHP Bug Type: Reproduceable crash
Bug description:  Dumping html files to error log

Hi,

PHP seems to have a bug where if the client closes the
connection too quickly,it can write the output to the error
log if output buffering is enabled.  The following script
should do it.

large html file here.


If the request is interrupted, the following is printed in
Apache's error log.

[Sat Mar  3 14:58:29 2001] [info] [client 151.197.242.152]
(32)Broken pipe: client stopped connection before rwrite
completed
Directly after this point, the requested html is printed
after being processed by PHP.  No timestamps, just
appearing in the error log as is.  If output buffering is
disabled, the above message does appear if LogLevel is
low enough but the html file doesn't follow.

Note: if LogLevel is above info in httpd.conf, you won't
see the above warning message, just the html file.

Shane


-- 
Edit Bug report at: http://bugs.php.net/?id=9540&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] PHP 4.0 Bug #9909: session_start() fails to write data file

[shane]

From: [EMAIL PROTECTED]
Operating system: Mac OS X Server
PHP version:  4.0.4pl1
PHP Bug Type: *Session related
Bug description:  session_start() fails to write data file

PHP 4.04pl1 compiled as a DSO
Apache 1.3.19



session_start() fails to write out its data file, causing 
the session to not be initialized and the following error 
to be displayed:

Warning: open(/tmp/sess_aeb08199d769529594e751c17ea3ffa7, 
O_RDWR) failed: m (13) in  on line 2

PHP does not seem to be able to write out the file 
anywhere; permissions on the directory are normal. 

PHP compiled like so:

./configure \
--with-apxs=/usr/local/sbin/apxs \ 
--with-mysql=/usr/local/mysql \
--enable-ftp \
--with-xml \
--enable-discard-path \ 
--with-config-file-path=/Local/Library/WebServer/Configurat
ion \
--disable-debug \
--enable-track-vars

This was working with an Apache 1.3.14 and an earlier 
version of PHP4 (sorry, can't say which but probably 4.01 
or 4.02)


-- 
Edit Bug report at: http://bugs.php.net/?id=9909&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 #9909 Updated: session_start() fails to write data file

[shane]

ID: 9909
User Update by: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: *Session related
Description: session_start() fails to write data file

False alarm, sorry . . . turns out that Apache changed the way it writes temp files (I 
think the "child" servers now write files, rather than the parent servers) so it 
couldn't write to /tmp. Hmmph.

Previous Comments:
---

[2001-03-21 23:23:20] [EMAIL PROTECTED]
PHP 4.04pl1 compiled as a DSO
Apache 1.3.19



session_start() fails to write out its data file, causing 
the session to not be initialized and the following error 
to be displayed:

Warning: open(/tmp/sess_aeb08199d769529594e751c17ea3ffa7, 
O_RDWR) failed: m (13) in  on line 2

PHP does not seem to be able to write out the file 
anywhere; permissions on the directory are normal. 

PHP compiled like so:

./configure 
--with-apxs=/usr/local/sbin/apxs  
--with-mysql=/usr/local/mysql 
--enable-ftp 
--with-xml 
--enable-discard-path  
--with-config-file-path=/Local/Library/WebServer/Configurat
ion 
--disable-debug 
--enable-track-vars

This was working with an Apache 1.3.14 and an earlier 
version of PHP4 (sorry, can't say which but probably 4.01 
or 4.02)

---


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


-- 
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 #13242: Issues compiling with IMAP support

[shane]

From: [EMAIL PROTECTED]
Operating system: Redhat Linux 7.0
PHP version:  4.0.6
PHP Bug Type: Compile Failure
Bug description:  Issues compiling with IMAP support

Having issues compiling PHP with IMAP 4.7 with Redhat 7.0

When I use the --with-imap=/usr/lib I get the same problem as in bug 8485
(Compiles fine, but get an SSL Error when restarting apache)

When I add the --with-imap-ssl=/usr/lib, php compiles, apache works, but
the imap module does not function correctly, whereas the postgres module
works.

When I use BOTH --with-imap=/usr/lib and --with-imap-ssl=/usr/lib i get an
error with the ./configure script replies that the imap program does not
support SSL.
(configure: error: This c-client library does not support SSL. Recompile or
remove --with-imap-ssl from configure line)

System Configuration:

Redhat 7.0
IMAP 4.7 RPM with Dev Packages
OpenSSH RPM with Dev Packages
Apache RPM with Dev Packages

Configure script:
./configure --with-pgsql --with-apxs=/usr/sbin/apxs --enable-track-vars
--with-imap=/usr/lib/ --with-kerberos 
(Using with Kerberos support as mentioned in bug database when compiling
with RedHat.)

Upgrading Redhat to support another version imap or imap2000 is not an
option as I have software that relies on RH7.0 and is not supported by 7.1
:(

If you require more information, please let me know.

Please Help?

Cheers,
Shane.


-- 
Edit bug report at: http://bugs.php.net/?id=13242&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]

Re: [PHP-DEV] Re: #21659 [Com]: sprintf

[Shane Caraveo]

Ilia A. wrote:

On January 15, 2003 10:27 am, Adam Wright wrote:


Last ditch effort of "NotAPHPBug"? ;)



This too may not be a correct solution all the time. Consider 75th duplicate 
report of an invalid or even a resolved bug report. It may have been a bug at 
some point, but certainly is not anymore. It is bogus, because the user chose 
not to search in the bug database for similar reports before posting their 
report. Surely you can agree that such a report is bogus.

Your definition of bogus is very broad.  Personally I think bogus was a 
bad idea in the first place.

Anyway, in the situation above, it's a duplicate, not a bogus.  Marking 
it a duplicate informes the user (for the 75th time) that the bug was 
already reported, and even if that bug is fixed, it then points the user 
to the fix as well.

Shane


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

Re: [PHP-DEV] 4.3.1 (was: [PHP-CVS] cvs: php4(PHP_4_3) /main SAPI.h)

[Shane Caraveo]

As a matter of fact I think it would be good idea to go for 4.3.1 in
February because number of bugfixes in PHP_4_3 branch is already significant
and since no major new features have been added there the QA process
shouldn't take that long either.




And I have a pretty bad bug I'm still trying to repro (just got access 
to a box with the bug) that needs to get into a 4.3.1.

There were some, for example Sascha's addition. This alone would qualify 
a full QA, and not a short and fast one. Our general idea was to NOT add 
new code to release branches, but at the moment developers are still 
doing this because *they* need a new function and dont want to wait for 
5.0.0. I can understand that they dont want to wait for PHP 5, but what 
I dont understand is that they think less about the general stability 
and QA processes for the PHP 4.3.x series. 

Derick

And thus the need to have a pure 4_3 tree that 4_3_1 can be branched 
from.  Those people who need to add new features can do so on 4_3_head, 
but they might not ever make it into an official 4.x release depending 
on QA and the time cycle for 5.

Shane



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

[PHP-DEV] INI_STR usage in browscap (and others) causes crash

[Shane Caraveo]

Hello,

We have several places in our code (specificly in browscap.c) where we 
have bugs due to either improper usage of INI_STR, or improper results 
from zend_ini.c:zend_ini_string.

The code:

if (INI_STR("browscap")) {
   zend_hash_destroy(&browser_hash);
}

Will fail if there is no 'browscap' entry in php.ini since 
zend_ini_string returns "".  Adding 'browscap = ;' to php.ini fixes 
that, but causes an error on startup because the init cannot open ''.

The fix would be:

char *browscap = INI_STR("browscap");
if (browscap && *browscap) {
   zend_hash_destroy(&browser_hash);
}

A quick search in the code shows we have this problem in several places 
(php_imap.c, browscap.c, mail.c, sendmail.c, possibly more depending on 
usage of variables).

For some reason, this but only sporadicaly appears for me, but most 
often does when loading (any) debugger extension on linux.  In the case 
of the browscap, I actually get a segfault in the mshutdown.

So, is it improper usage of INI_STR, or is it incorrect results from 
zend_ini_string?  I'd like to get these fixed for 4.3.1.

Shane





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

Re: [PHP-DEV] Feature Request #5919 case-insensitive version of str_replace()

[Shane Caraveo]

Derick Rethans wrote:

On Wed, 29 Jan 2003, Sara Golemon wrote:



I've got an implementation put together, the patch for which can be
viewed at:

http://169.229.139.97/test/str_ireplace.diff.txt



After some comments on IRC, here's an alternate version to the above
patch.  This second approach avoids creating php_memnstri by simply
searching through a copy of haystack which is strtolowered against a
strtolowered version of needle (no need to copy that part).

http://169.229.139.97/test/str_ireplace.diff-2.txt

Should be quicker and cleaner at the cost of a small malloc in the
estrndup call.



I still don;t see no real use for this function, you can easily do this 
with eregi_replace() or preg_replace().

Derick

I may be wrong since I haven't profiled this, but my understanding is 
that str_replace is much faster than doing either of the regex 
replacements.  For that reason alone, there is a use for it.

Shane



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

Re: [PHP-DEV] Feature Request #5919 case-insensitive version of str_replace()

[Shane Caraveo]

Ilia A. wrote:

I may be wrong since I haven't profiled this, but my understanding is
that str_replace is much faster than doing either of the regex
replacements.  For that reason alone, there is a use for it.


Normally it would be quite faster, however once case sensitivity is added to 
the mix I believe the speed difference would be minimal. I've done some 
benchmarks and the speed difference between str_replace() and preg_replace() 
is only about 1/2 second in across 10 executions (5 replaces per 
instance). Another .6 of a second is added when preg_replace() is used with 
'i' flag which makes it case insensitive. I have not benchmarked the 
stri_replace code but I imagine it would be in the same ballpark, meaning 
that we are adding a fairly large chunk of code for performance benefit of a 
1 microsecond (1 millionth of a second) per instance.

Ilia


What's the benchmark code?  How is the benchmark difference on large 
text (ie. 100K of text) vs. small text (1K or smaller)?

Shane


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

Re: [PHP-DEV] [PATCH] sapi/nsapi/nsapi.c

[Shane Caraveo]

Excelent, The CGI vars are correct.  One less sapi module to deal with :)
Shane

Uwe Schindler wrote:

The variables you explain are surely there. But a lot of scripts depend 
on other headers, which the client sent.
The SAPI module only creates Variables for a subset of them 
(HTTP_USER_AGENT). But not for all like
the other SAPI modules. So with this patch you get for example the 
missing HTTP_HOST-Header (HTTP/1.1)
because the patch creates for every variable in the request a 
HTTP_XXX-Variable. So you can see all headers the client have sent.
This is the way the other SAPI modules (APACHE) and the normal CGI 
environment works. Without it about 50% of the currently available PHP 
scripts do not run correctly.

You can try it with: http://www.emarcon.net/test.php which runs the 
patched Version. Yo will see all headers sent by your client not only 
the ones explained below and HTTP_USER_AGENT and HTTP_ACCEPT_*

Greetings from Germany,
Uwe

At 15:52 02.02.2003 -0800, you wrote:

Hi Uwe,
I haven't looked at the patch, but I am wondering if the nsapi sapi 
module creates variables for php that conform to the cgi spec.  Can 
you try the following url against a phpinfo(); script:

http://localhost/info.php/test/path?query=string

You should get:

PATH_INFO=/test/path
PATH_TRANSLATED=/your_web_document_root/test/path
QUERY_STRING=query=string
SCRIPT_NAME=/info.php
PHP_SELF=/info.php

If you do not, then the sapi module is not conformant to cgi spec, and 
still needs some work.
Shane

Uwe Schindler wrote:

I submit a patch for the NSAPI SAPI module and hope that it fixes a 
lot of problems I have (and others as seen in the bug database).
As a lot of variables which are needed by a lot of PHP scripts which 
use $_SERVER["..."] are not transferred correctly to the PHP script 
that runs in iPlanet Webserver (4 or 6). An example are the "Host" 
and "X-Forwarded" headers. This is so, because the transferred 
variables are static in the SAPI module.
The new nsapi.c file now transfers _ALL_ variables from 
rc->rq->headers to 
php_register_variable("HTTP_"+headername_uppercase, ...).
Also missing variables like "SERVER_SOFTWARE" are added.
A lot of customers complain about memory leaks in this module. I hope 
they are also fixed by freeing the by nsapi allocated strings (the 
return value of session_dns and http_uri2url).
The patch should work with Netscape/iPlanet Servers from version 3 on 
(I used no newer API calls).
If you are interested I could eventually create a patch for 
supporting the "virtual servers" in SunONE/iPlanet Web Server 6, 
because some vars only get the default-hostname not the real virtual 
server name (for example $_SERVER["SERVER_URL"] which is often used 
in scripts to refer together with $_SERVER["PHP_SELF"]). But this mut 
be done with #ifdefs because some new functions are in the nsapi 
since version 6. A good fix would be also to map 
$_SERVER["SERVER_URL"] to "http://$SERVER["HTTP_HOST"]";, because in 
iPlanet-Servers the Host variable is everytime available (if not in 
original HTTP-headers it is defined to be the default hostname).
Greetings,
Uwe

-
Uwe Schindler
Addr 1: Bamberger Str. 24a, D-96049 Bamberg
Addr 2: Drausnickstr. 153, D-91052 Erlangen
http://www.thetaphi.de - http:///www.schindlers-software.de
eMails: [EMAIL PROTECTED] (private); [EMAIL PROTECTED] (company)
Tel./Fax: +49 700 PCLATEIN (+49 700 72528346)
Schindlers Software - Home of Schindlers PC-LATEIN 3.10
DIE Software zum Lateinlernen!


-
Uwe Schindler
Addr 1: Bamberger Str. 24a, D-96049 Bamberg
Addr 2: Drausnickstr. 153, D-91052 Erlangen
http://www.thetaphi.de - http:///www.schindlers-software.de
eMails: [EMAIL PROTECTED] (private); [EMAIL PROTECTED] (company)
Tel./Fax: +49 700 PCLATEIN (+49 700 72528346)

Schindlers Software - Home of Schindlers PC-LATEIN 3.10
DIE Software zum Lateinlernen!  







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

[PHP-DEV] proc_open() patch

[Shane Caraveo]

The attached patch adds 2 optional parameters to proc_open().  The 
first, cwd, and the second is an array for executing with a custom 
environment.  I've tested this on w2k and osx.  Comments, fixes, 
changes, and testing on Linux, would be appreciated.

Shane
Index: ext/standard/proc_open.c
===
RCS file: /repository/php4/ext/standard/proc_open.c,v
retrieving revision 1.3
diff -u -d -u -r1.3 proc_open.c
--- ext/standard/proc_open.c24 Jan 2003 16:45:34 -  1.3
+++ ext/standard/proc_open.c10 Feb 2003 07:31:43 -
@@ -56,6 +56,111 @@
 
 static int le_proc_open;
 
+/* {{{ _php_array_to_envp */
+static char *_php_array_to_envp(zval *environment, int is_persistent TSRMLS_DC)
+{
+   zval **element;
+   char *envp, *p;
+#ifndef PHP_WIN32
+   char **myenvp, **ep;
+#endif
+   char *string_key, *data;
+   uint string_length, cnt, l, sizeenv=0, el_len;
+   ulong num_key;
+   HashTable *target_hash;
+   HashPosition pos;
+
+   if (!environment) return NULL;
+   cnt = zend_hash_num_elements(Z_ARRVAL_P(environment));
+   if (cnt < 1) return NULL;
+
+   target_hash = HASH_OF(environment);
+   if (!target_hash) return NULL;
+
+   /* first, we have to get the size of all the elements in the hash */
+   for (zend_hash_internal_pointer_reset_ex(target_hash, &pos);
+zend_hash_get_current_data_ex(target_hash, (void **) &element, &pos) 
+== SUCCESS;
+zend_hash_move_forward_ex(target_hash, &pos)) {
+   
+   convert_to_string_ex(element);
+   el_len = Z_STRLEN_PP(element);
+   if (el_len == 0) continue;
+   sizeenv += el_len+1;
+   switch (zend_hash_get_current_key_ex(target_hash, &string_key, 
+&string_length, &num_key, 0, &pos)) {
+   case HASH_KEY_IS_STRING:
+   if (string_length == 0) continue;
+   sizeenv += string_length+1;
+   }
+   }
+
+#ifndef PHP_WIN32
+   ep = myenvp = (char **) calloc(cnt+1,sizeof(char *));
+#endif
+   p = envp = (char *) calloc(sizeenv+4,1);
+
+   for (zend_hash_internal_pointer_reset_ex(target_hash, &pos);
+zend_hash_get_current_data_ex(target_hash, (void **) &element, &pos) 
+== SUCCESS;
+zend_hash_move_forward_ex(target_hash, &pos)) {
+   
+   convert_to_string_ex(element);
+   el_len = Z_STRLEN_PP(element);
+   if (el_len == 0) continue;
+   data = Z_STRVAL_PP(element);
+   switch (zend_hash_get_current_key_ex(target_hash, &string_key, 
+&string_length, &num_key, 0, &pos)) {
+   case HASH_KEY_IS_STRING:
+   if (string_length == 0) continue;
+   l = string_length + el_len + 1;
+   memcpy(p, string_key, string_length);
+   strcat(p, "=");
+   strcat(p, data);
+   if (PG(magic_quotes_gpc)) {
+   php_stripslashes(p,&l TSRMLS_CC);
+   }
+#ifndef PHP_WIN32
+   *ep = p;
+   ++ep;
+#endif
+   p += l;
+   break;
+   case HASH_KEY_IS_LONG:
+   memcpy(p,data,el_len);
+   if (PG(magic_quotes_gpc)) {
+   php_stripslashes(p,&el_len TSRMLS_CC);
+   }
+#ifndef PHP_WIN32
+   *ep = p;
+   ++ep;
+#endif
+   p += el_len + 1;
+   break;
+   case HASH_KEY_NON_EXISTANT:
+   break;
+   }
+   }   
+
+   assert(p-envp <= sizeenv);
+   zend_hash_internal_pointer_reset_ex(target_hash, &pos);
+#ifdef PHP_WIN32
+   return envp;
+#else
+   return (char *)myenvp;
+#endif
+}
+/* }}} */
+
+/* {{{ _php_free_envp */
+static void _php_free_envp(char *envp)
+{
+   if (envp) {
+#ifndef PHP_WIN32
+   free(*envp);
+#endif
+   free(envp);
+   }
+}
+/* }}} */
+
+
 static void proc_open_rsrc_dtor(zend_rsrc_list_entry *rsrc TSRMLS_DC)
 {
struct php_process_handle *proc = (struct php_process_handle*)rsrc->ptr;
@@ -98,7 +203,7 @@
 #else
FG(pclose_ret) = -1;
 #endif
-
+   _php_free_envp(proc->envp);
pefree(proc->command, proc->is_persistent);
pefree(proc, proc->is_persistent);

@@ -166,8 +271,6 @@
 }
 /* }}} */
 
-
-
 PHP

Re: [PHP-DEV] Performance degradation

[Shane Caraveo]

Rasmus Lerdorf wrote:
So, I am just starting out down the path to figure out why PHP 4.3 has
gotten so much slower than 4.2.  "strace -c" provides the first clue.  A
straight "./configure --enable-inline-optimization && make" command-line
build for 4.2, 4.3 and 5.0 run on a simple hello world script reveals that
we have gone from 219 system calls in 4.2 to 233 in 4.3 to 236 in 5.0.
This is a bad trend and we really need to make an effort to reverse this.
4.2 Hello World from command-line:

CGI, right?  Part of this may be from the path_info handling I've added. 
 There is a stat call in there to determine if the path provided by the 
webserver includes path_info also, if it does have path_info (stat 
failed), it walks up the path doing a stat to determine the script 
filename and path_info correctly.  the ini setting cgi.fix_pathinfo 
turns this on or off.  It also uses a handfull putenv and getenv calls 
in straightening things out.  I'm sure this adds some of that, but I 
don't think it would add as much an increase as you are seeing, unless 
you're using some long path_info paths.

Shane



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

Re: [PHP-DEV] Performance degradation

[Shane Caraveo]

Rasmus Lerdorf wrote:
On Sun, 23 Feb 2003, Shane Caraveo wrote:


CGI, right?  Part of this may be from the path_info handling I've added.



The extra realpath() and fstat() calls are not cgi specific, so if what
you added only affects cgi, then that isn't the big problem.
-Rasmus

ok, it's only in CGI.

Shane

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

Re: [PHP-DEV] [WARNING] Release process for 4.3.2 starts RSN..

[Shane Caraveo]

I wanted to run through all the cgi stuff in detail again for 432, but 
likely wont have the time by the 26th to do that.
Shane

Jani Taskinen wrote:
To get this thing started, I'm going to roll PHP 4.3.2-pre1
on Wednesday, 26th Feb, around 3pm EEST. And I'll announce
it on php-general too, to get some more people testing it
before we start with any RCs.
Following is collection of bugs marked as critical and verified
which should be looked into and dealt with. If not fixed,
then please, PLEASE add some comment why they won't ever
be fixed and bogus the out.


Critical:
 
  http://bugs.php.net/bug.php?id=20190&edit=1 
  . Random mem corruption: zend_get_executed_filename() mismatch

  http://bugs.php.net/bug.php?id=21820&edit=1 
  . bc break in parser: "$arr[val]" vs "$arr['val']"

  http://bugs.php.net/bug.php?id=22372&edit=1
  . Don't forget to bump the PHP API number for 4.3.2 release
Verified bugs (Scripting Engine related):

  http://bugs.php.net/bug.php?id=15209&edit=1
. register_shutdown_function() broke between 4.0.x to 4.1.x
- Zeev: Either close as bogus saying it's intended behaviour or 
finally get around and FIX IT. ([EMAIL PROTECTED] has a patch?)

  http://bugs.php.net/bug.php?id=21513&edit=1
. shutdown functions not executed if timed out [win32 only]
  
  http://bugs.php.net/bug.php?id=15438&edit=1
. include_once fails when comparing output to a value

  http://bugs.php.net/bug.php?id=17997&edit=1
. got wanning when combing switch & reference
  
  http://bugs.php.net/bug.php?id=20548&edit=1
. Decrement ("$x[$y]--") doesn't work on uninitiated variable

  http://bugs.php.net/bug.php?id=21478&edit=1
. Zend/zend_alloc.c :: shutdown_memory_manager produces segfault
  
  http://bugs.php.net/bug.php?id=22367&edit=1
. undefined variable has a value
. RFC: Just bogus with "Don't do this." ?

  http://bugs.php.net/bug.php?id=21918&edit=1
. strange behaviour of mixed type in array-keys
. See #21788

  http://bugs.php.net/bug.php?id=21788&edit=1
. array_multisort() changes array keys unexpectedly given numeric strings as keys
. See #21918

  Last two are related to each other, afaics, and need some discussion
  what we should do about it or if nothing. Also related to these
  is http://bugs.php.net/bug.php?id=8325.
   
--Jani







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

Re: [PHP-DEV] Piping to the PHP binary

[Shane Caraveo]

4.3.1 works fine.
Shane
Dan Hardiker wrote:
Hey all,

echo "" | /path/to/php

That works on php v4.2.x but Ive got 3 machines on v4.3.x and none of them
seem to respond to the piping of the php config.

v4.2.x Response

[13:56:[EMAIL PROTECTED]:~$ echo "" |
/usr/local/bin/php
X-Powered-By: PHP/4.2.3
Content-type: text/html
hi[13:56:[EMAIL PROTECTED]:~$

v4.3.x Response

[13:58:[EMAIL PROTECTED]:~$ echo "" |
/usr/local/bin/php
Status: 404
Content-type: text/html
X-Powered-By: PHP/4.3.2-dev
No input file specified.
[13:59:[EMAIL PROTECTED]:~$

Anyone else with the same results on a v4.3.x cgi-binary?
Is this modified behavoir limited to me, or expected?
I tried asking php-general@ but no response.




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

Re: [PHP-DEV] Tie'ing variables

[Shane Caraveo]

So I'm not clear on how I am should expect this to work.  A simple script:

error_reporting(2047);
print_r($_ENV);
is now completely broken unless you turn on register_long_arrays.  If 
that is expected behaviour, register_long_arrays must be on by default.

Shane

Zeev Suraski wrote:
I wanted to do this for some time, but until recently, it wasn't very 
feasible, because the order of registration could be designated by the 
user (gpc_order, variables_order, etc.).  Now that register_globals is 
off by default, and that we have the auto-globals, it's much more feasible.

I implemented this optimization in CVS, so far only for $_ENV and 
$_SERVER.  This alone pushed nearly-empty-page req/sec pages from about 
285 to about 400 on my Windows box.  I'll look into fixing the other 
ones later.

Pre-requisites for this optimization to kick in:
1.  register_globals being off
2.  register_long_arrays (HTTP_*_VARS) being off
If you want to benchmark w/ vs. w/o, you can disable the optimization by 
initializing cb to 0 in php_startup_auto_globals() and 
jit_initialization to 0 in php_hash_environment(), both in 
main/php_variables.c.

Zeev

At 18:26 01/03/2003, Sterling Hughes wrote:

Hi,

Analyzing PHP's routines a bit, it seems that the slowest part of a
"generic" request is populating the special arrays, $_ENV, $_GET, etc.
I was wondering if it might be possible to "tie" these arrays to a
function (if you don't understand that, look at Perl for a definition).
One could populate them as an overloaded object, and then array accesses
would work - I guess.  But I would prefer a cleaner mechanism.
This would prevent a costly overhead for elements that don't really need
to be there, and yield only a slight performance cost when accessing
overloaded elements in these arrays.
-Sterling

--
"The computer programmer is a creator of universes for which he
 alone is responsible. Universes of virtually unlimited complexity
 can be created in the form of computer programs."
- Joseph Weizenbaum
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php







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

[PHP-DEV] magic_quotes on the environment?

[Shane Caraveo]

Even though magic_quotes_gpc is documented to addslashes to 
get/post/cookie, it also does it to the environment.  This probably 
doesn't effect linux as much as windows, where all paths get escaped if 
magic_quotes_gpc is on.

I find this rather anoying since I am trying to build environments for 
process execution (executing php again) and nothing was working due to 
magic_quotes_gpc (ie. I was not escaping env vars I was creating, then 
php would unescape the data prior to executing).

I'm not convinced that escaping environment data is the correct thing to 
do in the first place, and I would like to change php to not escape env 
vars if magic_quotes_gpc is on.  Any opinions on this?

Shane

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

Re: [PHP-DEV] magic_quotes on the environment?

[Shane Caraveo]

Rasmus Lerdorf wrote:
I'm not convinced that escaping environment data is the correct thing to 
do in the first place, and I would like to change php to not escape env 
vars if magic_quotes_gpc is on.  Any opinions on this?


This changed somewhere along the line then.  Originally magic quotes only 
touched GPC data.  I never noticed it also did it to the environment and 
I'd consider that to be a bug.

-Rasmus

Hmm, actually, *any* variable passed through php_register_variable() 
will get escaped if magic_quotes_gpc is on, irregardless of what array 
it is getting registered into, so this effects _ENV, _SERVER and _FILES 
in addition to _GET,_POST and _COOKIE.  I also don't know if any other 
stuff happens to use php_register_variable that may not want escaping.

Shane

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

Re: [PHP-DEV] $GLOBALS broken?

[Shane Caraveo]

It's a patch to ze2 that was done over the weekend, there is a new ini 
setting that if you turn it on will fix the problem, just cannot 
remember what it was right now...
Shane

Sebastian Bergmann wrote:
  Notice: Undefined variable: GLOBALS in E:\test.php on line 7

1 


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

Re: [PHP-DEV] $GLOBALS broken?

[Shane Caraveo]

Shane Caraveo wrote:
It's a patch to ze2 
Actually, it may not have been to ze2 itself.

that was done over the weekend, there is a new ini
setting that if you turn it on will fix the problem, just cannot 
remember what it was right now...
Shane

Sebastian Bergmann wrote:

  Notice: Undefined variable: GLOBALS in E:\test.php on line 7

1 





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

Re: [PHP-DEV] Moderate PHP-DEV

[Shane Caraveo]

Sascha Schumann wrote:
if even that description doesn't work, then nothing would work, not even
changing the name.


Well, it is obvious that some folks don't read that
description and simply move forward, because "php-dev" sounds
about right.  They are "PHP developers" and so a list called
"php-dev" makes absolute sense to them.
- Sascha

A couple thoughts

Aside from renaming the php-dev list, we should remove the 'PHP and Zend 
Engine internals lists' from the regular mailing list page, put them in 
a 'developers' section (name isn't important) that describes cvs access, 
dev email lists, how to build (ie. win32 libraries), etc.  That way it 
is completely removed from the regular stuff that normal php users will 
gravitate towards.  It would help to clarify what is for the php 
community at large, and what is for the community of developers that 
work on php itself.

Then another item that might be considered if it is not already done, 
allowing posts only from those that have cvs access.  A second 
conditional list of allowed posters can be added that are people who do 
not have cvs access, but we want to allow to post.  Otherwise, the list 
can be readable by all.  A post rejected message could tell them to try 
a different email list, but if they really feel the email is for the dev 
list, send it to [EMAIL PROTECTED] and it will be reviewed by someone when 
they get the time.

Shane

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

Re: [PHP-DEV] Moderate PHP-DEV

[Shane Caraveo]

Sascha Schumann wrote:
Aside from renaming the php-dev list, we should remove the 'PHP and Zend
[snip]

Sounds good.


Then another item that might be considered if it is not already done,
allowing posts only from those that have cvs access.  A second
conditional list of allowed posters can be added that are people who do
not have cvs access, but we want to allow to post.  Otherwise, the list
can be readable by all.  A post rejected message could tell them to try
a different email list, but if they really feel the email is for the dev
list, send it to [EMAIL PROTECTED] and


This however sounds too restrictive to me.  I'm convinced
that the main php development list should stay as open as
possible.  The issue of a few misdirected emails should not
serve as an excuse for closing down the main development
list.  We should not become an ivory tower.

it will be reviewed by someone when they get the time.


This manual review effectively implies censorship which is
undesirable in an open environment.  I doubt it would serve
the PHP community in any way.
- Sascha
Well, it is just an idea, but my desire is not to implement censorship 
or to make the list closed, but rather to 'protect the purpose and use' 
of the list.  I rather think that the first item I sent is the only one 
that is realy needed, and that it would solve 90% of any existing 
problems.

But for the sake of writing...here's another idea.

So how about a first post response system, similar to the subscription 
response.  That first post would not actually be posted to the email 
list, but rather an email would be sent back to the poster stating the 
purpose of the email list, and what kind of materials are expected on 
the list.  If the post does not match this criteria, please send it to 
on of the other lists, otherwise respond to this email and your original 
message will go out.

Shane



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

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /tests/classes interface_class.phptinterface_doubled.phpt interface_implemented.phpt interface_instantiate.phptinterface_member.phpt interface_method.phpt interface_method_final.phptinterface_method_private.phpt interface_must_be_implemented.phpt

[Shane Caraveo]

Andrei Zmievski wrote:
On Wed, 12 Mar 2003, Sebastian Bergmann wrote:

 I have seen extended interfaces quite often in the Java world.

 IIRC, the following code currently runs without problems and it should
 stay that way, if it does not harm us in any way:
   


I wasn't talking about interfaces extending interfaces - that is
perfectly fine. I was saying that "class blah extends " and
"class blah implements " is confusing.
-Andrei   http://www.gravitonic.com/
A class extending an interface seems just weird to me.  classes should 
only extend classes, and implement interfaces.  interfaces can extend 
interfaces.  I haven't been following the interfaces stuff (I'm going to 
have to backtrack and read it all, very happy if this stuff will do what 
I want), but I would hope we have some capability of implementing 
multiple interfaces in a class somehow.

interface JAZ {}
interface FOO {}
interface BAR extends FOO {}
class foo implements FOO {}
class foobar extends foo implements (BAR,JAZ) {}
Shane

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

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /tests/classes interface_class.phptinterface_doubled.phpt interface_implemented.phpt interface_instantiate.phptinterface_member.phpt interface_method.phpt interface_method_final.phptinterface_method_private.phpt interface_must_be_implemented.phpt

[Shane Caraveo]

Marcus Börger wrote:
At 20:20 12.03.2003, Andrei Zmievski wrote:

On Wed, 12 Mar 2003, Marcus Börger wrote:
> This works even though i do not like  extends FOO.
Why? Both C# and Java (AFAIR) allow interfaces to extend other
interfaces.


Because of the second part of the answer. It is a little bit strange that
an interface can extend and implement an interface but a class can
only implement interfaces. Also it is a bit weired that i can implement
multiple interface but extend only one.
An interface should not implement an interface, only classes should 
implement interfaces.  'implement' infers that actual executable code is 
provided that implements an interface.  Again, I haven't followed the 
interface stuff, and sorry for writting without reading the background, 
but I'm working off the assumption that interfaces are kind of like IDL.

ok:
interface extends interface
class extends class implements interface
not ok:
interfaces implements interface
class extends interface
Shane

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

Re: [PHP-DEV] PATCH: debug_backtrace() function for 4.3-dev/ZE1

[Shane Caraveo]

Thies, just commit the patch and let this thread die.  

Shane




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

Re: [PHP-DEV] PATCH: debug_backtrace() function for 4.3-dev/ZE1

[Shane Caraveo]

>
> It took us a long time to get php-dev@ moving on the new version 
> because most of them were still using PHP 3 for their production sites.
> The fact that you guys are so strongly in favor of putting this cool 
> feature into ZE1 proves that not putting it in could give ZE2 a big 
> boost of momentum. Everyone feels very strongly about this feature. 
> (On a side note, at least that makes me happy that people liked this 
> revolutionary/negligible performance impact patch :)

>
> I think we need this new momentum. A new version of the engine is very 
> important if we want PHP to compete with the latest technologies. If 
> PHP doesn't get moving on its next version I'm afraid it won't be able 
> to maintain its current position in the market.
> The only person I have seen thinking of what he'd like to get done for 
> PHP 5 is Wez.
> By the way, the only personal gain I have in getting ZE2 out of there 
> is that it's my code and that PHP will do much better. I think that 
> PHP is going to loose out big time if things don't start gaining some 
> momentum. Backporting is definitely a momentum breaker *especially* as 
> everyone really really wants to backport it badly. That's exactly my 
> point. If you guys want it so badly then work for it! :)
>
> Andi


One difference between now and the 2->3->4 transition was that then 
there was a much smaller development group, and one that was invested in 
and focused on the new versions.  Decisions were made primarily by a 
small group, so even our arguments could be thrashed out fairly quickly. 
 This is not so true today.  It's a much larger group of developers, 
more focused on features needed to do their stuff, rather than the 
language itself.  I don't think that is a bad thing, PHP can use ever 
more features, but I think PHP has gotten big enough that a smaller 
group needs to sit down and outline a roadmap and proceedures that will 
help move towards the goals outlined by the roadmap.  The roadmap can't 
of course prevent someone from implementing stuff not in the roadmap, 
but at least it would give PHP development a more visible and focused 
direction than it has now, and what must be done for each version.   I 
suggest a smaller group, because by experience, talking about this stuff 
in large groups, such as php-dev, leads to never ending cycles of 
discussion and argument that lead nowhere.  The larger group can comment 
on the roadmap, providing possibly valuable feedback, but it cannot 
provide the focus necessary to drive development in a targeted direction.

Personally, I would trash 4.3, and focus on the next major version 
including ze2.  Do it now, get it over with.  Having this non-descript 
4.3 between now and ze2 is somewhat distracting.  There can be minor 
point releases to backport bug fixes, etc.  Modules can be independently 
released via PECL if necessary.

Afterthought, the only important language item I can think of for 4.3 
that shouldn't wait is getting pear in there.  I'm sure someone will 
dissagree.

Shane




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

Re: [PHP-DEV] PHP 4.3 and PHP 5

[Shane Caraveo]

>
>
>
> o Decide if we are or are not going to support the iPlanet system.  If we
>are, it needs to be drastically fixed, if we're not we need to drop it.
>Really.  Look at the bug reports.
>  
>
It should simply be marked EXPERIMENTAL, but not removed.  On the other 
hand, it doesn't have to be included in the distribution if it simply 
does not work correctly.

Shane



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

Re: [PHP-DEV] PHP 4.3 and PHP 5

[Shane Caraveo]

Rasmus Lerdorf wrote:
> But how do you propose we come up with perfect Apache 2.0 support? 

FastCGI :)

> If we
> limit it to the pre-fork mpm, we can probably get quite close to perfect
> stability, but for any of the threaded mpms we are completely at the mercy
> of the threadsafetyness of all the various third party libraries on all
> the various platforms that PHP runs on. There is simply no way to ensure
> that PHP against Apache 2.0 with a threaded mpm will be production
> quality. The best we can do is pick a small set of extensions and a small
> set of platforms and say that with the limited set of extensions, against
> a specific set of versions of addon libraries on a specific version of
> that OS, yes, it should be production quality - maybe.
> 
> -Rasmus

Sounds like windows now ;)

Shane


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

Re: [PHP-DEV] ISAPI Crash Debugging Notes

[Shane Caraveo]

> Either way - starting threads from an ISAPI filter/extension is 
> completely forbidden (or at least strongly discouraged) so even if there 
> is some bug in there, starting our own thread is not an option.  Can you 
> give me the data I mentioned in the previous letter?
> 
> Zeev

It's not forbidden or even discouraged, in fact, it's quite the oposite. 
  The sdk comes with examples of creating worker threads in isapi 
modules, and I've done that plenty.  I have had it in the back of my 
head to port over some of the isapi work I've done in the fastcgi 
extension to the php isapi module since it uses a couple techniques 
suggested by MS for performance (such as creating worker threads and 
async read/write).

Shane




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

Re: [PHP-DEV] mbstring

[Shane Caraveo]

Jim Winstead wrote:
> Yasuo Ohgaki <[EMAIL PROTECTED]> wrote:
> 
>>Marcus B?rger wrote:
>>
>>>We already had some discussion on some IF statements in ini
>>>files already. I guess we might call to another mail thread here
>>>and hope we find a volunteer. I will not invent any work here since
>>>that would be totally useless.
>>
>>I think having a IF in php.ini is good idea.
> 
> 
> it's too bad we don't have an implementation of a complete programming
> language laying around.
> 
> jim

Yeah, sure would be usefull, then we could just get rid of ini, and use 
the language...

Shane



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

Re: [PHP-DEV] sockets extension...pecl it

[Shane Caraveo]

Dan Kalowsky wrote:
> Because the user can see how active such functionality is by looking at
> the CVS logs, and doing a search on php-dev conversations.

Sorry, but that's a copout.  It expects way to much of the user.  If 
it's going to remain experimental, OR the api is going to continue to 
change in incompatible ways, it shouldn't be part of the standard PHP 
distribution.  We have a means to distribute extensions outside of PHP 
now, IMO experimental extensions should not be allowed into the core PHP 
distribuation any longer.  PECL it.

Shane



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

Re: [PHP-DEV] RFC: ODBC and PHP

[Shane Caraveo]

Hmm, is there no way to make the functions work with both odbc versions? 
  Have an odbc_set_version(int) function that can set the version of 
odbc to use.  The default can be version 3.  This way, with the addition 
of a single function call, scripts can provide BC.
Shane

Dan Kalowsky wrote:
> To Whom It May Concern,
> 
> I've been working for the last few months (delayed often, but mostly the
> last few weeks) on what I've been tenatively calling ODBC2.  Basically
> this is what I'd like to see PHP v 5 have as it's default ODBC system.
> 
> Some general notes about it:
> 
> - It will break BC.  I have tried to conform and keep things the same,
> but I'm not making any promises to keep BC at this time.
> 
> - It will support ODBC v 3.0 and greater only.  With the needs of many DBs
> to include larger typesets (like TEXT, NTEXT, IMAGE, etc) and UNICODE, I
> see this as being a necessity.
> 
> Some implementation notes:
> 
> - So far my testing is being done using iODBC, unixODBC, and Windows ODBC
> drivers.  I have no way of checking any of the others... help on this
> front would be appriciated.
> 
> Some of the features already added to it:
> 
> - Ability to control the ODBC environment handles before and after a
>   connection is created.
> - Ability to specify a CURSOR for use in statements.
> - More strongly enforced safe_mode restrictions.
> - The ability to connect to data sources without being defined locally.
> - A user can force the PHP system to create a new connection now.
> - An attempt to make the ODBC API look more like the MySQL/PostgreSQL APIs
>   feature setwise.
> - An option for the user to turn on which can allow dynamic sizing of a
>   result set text field (currently it's static).
> - Use of the default_user, default_db, and default_passwd in the php.ini.
> - Hopefully more detailed error messages.
> - Native support for returning results from functions, and SQL based
>   constructs (outside of SELECT statements).
> 
> If you have any specific functionality you would like to see, please send
> it to me, and I will see what I can do about adding this in.
> 
> I would like to add this into the current PHP system, to allow users to
> start playing with and testing as well.  Well probably just as soon as I
> finish some more of the odbc2_exec/odbc2_execute() cleanups.  This code is
> not optimized in any way, shape, or form.  It's not even believed to work
> with a lot of systems.  Because of this, I would like to hear back
> commentary back on any suggested recourse from those who've done this
> already.
> 
> Hopefully this will prove to be a useful change, and people will be happy
> :)  As always send your comments to me.
> 
> 
>>---<
> 
> Dan Kalowsky  "I'll walk a thousand miles just
> http://www.deadmime.org/~dank  to slip this skin."
> [EMAIL PROTECTED]  - "Streets of Philadelphia",
> [EMAIL PROTECTED]  Bruce Springsteen
> 
> 



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

Re: [PHP-DEV] RFC: ODBC and PHP

[Shane Caraveo]

Ok, then I would be for ODBC 3 for PHP 5 as the standard.  An ODBC 2 
extension can be shuttled out to PECL for those who may need it.  But 
for BC issues, there is still the nameing convention.  I would personaly 
prefer that the odbc functions stay odbc_*, rather than to start 
iterating through odbc2...odbc3 and so forth.  Don't know an easy 
solution right now.
Shane

Dan Kalowsky wrote:
> On Tue, 10 Sep 2002, Shane Caraveo wrote:
> 
> 
>>Hmm, is there no way to make the functions work with both odbc versions?
>>  Have an odbc_set_version(int) function that can set the version of
>>odbc to use.  The default can be version 3.  This way, with the addition
>>of a single function call, scripts can provide BC.
> 
> 
> This is a tricky question really.  Theoretically, yes it should be
> possible to allow this.  You may run into issues with some of the result
> sets, but the connections should still be the same.  You couldn't really
> do it with a function like odbc_set_version, as my understanding of ODBC
> states you must declare which version type you are using at compile time.
> If you have some documentation stating otherwise, I'd be interested in
> reading it.
> 
> The reality is, I don't know.  All ODBC3 drivers should be able to utilize
> the deprecated functionality just fine, but the mapping is an unknown
> and dependent upon vendor implementation.  Going the other way, of course,
> is not going to work.
> 
> But I don't see a reason to keep such BC at this point.  The problem with
> the current system can be seen with bugs in the result sets.  The one
> area specifically mentioned above.  Users are still going to ask "Why
> doesn't my select work?" while using NTEXT or something non-compliant.
> The CURSOR type cannot be changed with the current system.  This in itself
> leads to a slower implementation, a (unnecessarily) larger memory
> footprint, and in DB2 systems a memory leak.
> 
> Hey at least I haven't gone as drastic as I originally thought, and asked
> to drop support specific for things like DB2, Solid, Empress, etc, and
> only support multi-driver systems (unixODBC, i-ODBC, and Windows ODBC).  :)
> Although I still think that would make the most sense and be the easiest
> to support on our end of things.
> 
> 
>>---<
> 
> Dan Kalowsky  "I'll walk a thousand miles just
> http://www.deadmime.org/~dank  to slip this skin."
> [EMAIL PROTECTED]  - "Streets of Philadelphia",
> [EMAIL PROTECTED]  Bruce Springsteen
> 
> 
> 



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

[PHP-DEV] 4.3 fastcgi

[Shane Caraveo]

I'd like to make sure fastcgi is well supported in 4.3.  I spent some
time over the weekend working on this and have some patches that I'll
try to get into the tree in the next day or so.  I haven't commited them
yet as I am having problems getting it to work with
apache2-win32/mod_fastcgi (a mod_fastcgi configuration issue I'm trying
to figure out).  I don't have the time however to do any testing on
linux with this, and linux also needs build changes (more on this below).

Some months ago I integrated the fastcgi sapi module into the cgi module
for a couple reasons.  One was the lack of support for a bunch of stuff
in the fastcgi module which the cgi module already had.  I felt that
rather than maintaining the same code/features in two different modules,
that a single module would be better.  Another reason was that I wanted
one executable rather than multiple executables (I still see php-cli and
php-cgi seperation as a downside).  There is also a somewhat customized
libfcgi under sapi/cgi directory.  This primarily contains bug fixes for
win32, and changes to make the library a better fit for PHP (ie. not
calling exit on errors).

The build system needs updating to support building this on Linux
systems.  I'm thinking that --with-cgi-fastcgi would build the
cgi/fastcgi module, and --with-fastcgi would build the seperate fastcgi
sapi module.   --with-cgi-fastcgi should be default when building the
php-cgi module, and a --without-cgi-fastcgi available to turn it off.
Another option, --libfcgi= to use a library different that the one
included in the source tree.

One of the items in my uncommited patch is to integrate the last changes
that happened in the fastcgi sapi module, which is support for running
PHP as a fastcgi socket server.  One difference between the to is the
way that is initated:

php-fastcgi 

php-cgi -b 

If anyone sees any issue with getting this into 4.3 please let me know.

A future feature (after 4.3) I want to implement for fastcgi is a
multithreaded fastcgi socket server.  This would allow for more
configurability in how php is used (single process/request, single
process/multiple requests), and provide a way to run out-of-process
multithreaded php.

Shane



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

[PHP-DEV] php_variables patch

[Shane Caraveo]

I'm working on getting mod_fastcgi/apache2/php4.3 to work together 
smoothly.  One thing mod_fastcgi does is, when it starts the fastcgi 
processes (php in this instance) very little environment is given to the 
process.  The environment is sent via the fastcgi protocol for each 
request.  To deal with this a hacky overwriting of the environment was 
done on every request.  Other than being a hack, it was also a memory 
leak.  I've fixed that by introducing a way for me to override the 
php_import_environment_variables function in PHP.  This should introduce 
no side effects for anyone, but I want to pass the patch by dev before 
commiting.  I've finished my patches to cgi_main.c, but those patches 
require this.

Shane


Index: php_variables.c
===
RCS file: /repository/php4/main/php_variables.c,v
retrieving revision 1.44
diff -u -d -u -r1.44 php_variables.c
--- php_variables.c 8 Sep 2002 00:27:05 -   1.44
+++ php_variables.c 13 Oct 2002 07:26:09 -
@@ -28,6 +28,9 @@

  #include "zend_globals.h"

+/* for systems that need to override reading of environment variables */
+void _php_import_environment_variables(zval *array_ptr TSRMLS_DC);
+PHPAPI void (*php_import_environment_variables)(zval *array_ptr 
TSRMLS_DC) = _php_import_environment_variables;

  PHPAPI void php_register_variable(char *var, char *strval, zval 
*track_vars_array TSRMLS_DC)
  {
@@ -318,8 +321,7 @@
}
  }

-
-void php_import_environment_variables(zval *array_ptr TSRMLS_DC)
+void _php_import_environment_variables(zval *array_ptr TSRMLS_DC)
  {
char **env, *p, *t;

Index: php_variables.h
===
RCS file: /repository/php4/main/php_variables.h,v
retrieving revision 1.13
diff -u -d -u -r1.13 php_variables.h
--- php_variables.h 11 Dec 2001 15:31:05 -  1.13
+++ php_variables.h 13 Oct 2002 07:26:09 -
@@ -31,7 +31,7 @@
  #define PARSE_STRING 3

  void php_treat_data(int arg, char *str, zval* destArray TSRMLS_DC);
-PHPAPI void php_import_environment_variables(zval *array_ptr TSRMLS_DC);
+extern PHPAPI void (*php_import_environment_variables)(zval *array_ptr 
TSRMLS_DC);
  PHPAPI void php_register_variable(char *var, char *val, pval 
*track_vars_array TSRMLS_DC);
  /* binary-safe version */
  PHPAPI void php_register_variable_safe(char *var, char *val, int 
val_len, pval *track_vars_array TSRMLS_DC);


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

RE: [PHP-DEV] php_variables patch

[Shane Caraveo]

Actually, I'm not sure when I'll be able to return to this so I'll just 
commit it since this is all working, and people can complain later if 
they want.
Shane



---
I'm working on getting mod_fastcgi/apache2/php4.3 to work together
smoothly.  One thing mod_fastcgi does is, when it starts the fastcgi
processes (php in this instance) very little environment is given to the
process.  The environment is sent via the fastcgi protocol for each
request.  To deal with this a hacky overwriting of the environment was
done on every request.  Other than being a hack, it was also a memory
leak.  I've fixed that by introducing a way for me to override the
php_import_environment_variables function in PHP.  This should introduce
no side effects for anyone, but I want to pass the patch by dev before
commiting.  I've finished my patches to cgi_main.c, but those patches
require this.

Shane


Index: php_variables.c
===
RCS file: /repository/php4/main/php_variables.c,v


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

re: [PHP-DEV] sapi/fhttpd + other sapi/cgi related things..

[Shane Caraveo]

Seems I got unsubscribed and missed this email.

sapi/fastgi is lacking in code that exists already in sapi/cgi, so I 
combined them several months ago.  The idea is to depricate sapi/fastcgi 
in favor of the combined cgi/fastcgi module.  libfcgi code from 
fastcgi.com is full of calls to exit() making it a bad thing since you 
generaly want to clean up if there is an error.  I've done the work on 
the windows side to remove that issue, so that is why there is a libfcgi 
directory under sapi/cgi.

The build system for linux needs to introduce a --with-fastcgi or even 
better, --without-fastcgi, which will set the define PHP_FASTCGI for the 
sapi/cgi compile, and include the libfci library as needed.

Shane

List: php-dev
Subject:  [PHP-DEV] sapi/fhttpd + other sapi/cgi related things..
From: Jani Taskinen <[EMAIL PROTECTED]>
Date: 2002-10-12 6:31:04
[Download message RAW]


 While trying to make Andrei happy and come up with --disable-cgi
 option, I noticed that there is really nice little mess in there..

 First of all, status of fhttpd...last version of it was released
 in 17-May-99..also last real updates to this code seem to have
 happened in PHP3. Can we get rid of this (most likely not even working)
 piece of code?

 Second issue, why is the fastcgi related files all over the place? :)
 There is sapi/fastcgi/ directory which has the config.m4 file and
 some other stuff. Then there is also some files under sapi/cgi/libfcgi/
 which don't seem to be used anywhere? Why aren't those under
 sapi/fastcgi/ ??

 --Jani


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

Re: [PHP-DEV] Xerces?

[Shane Caraveo]

Xalan and Xerces have both java and c versions.

Markus Fischer wrote:
> Since Xalan is written java, won't ext/java do that work
> anyway?
> 
> On Wed, Oct 16, 2002 at 02:56:50PM -0700, Alex Black wrote : 
> 
>>Hi all,
>>
>>I have done limited looking but as far as I can tell Xerces is not supported
>>by PHP.
>>
>>A) hopefully I am wrong and just didn't look hard enough.
>>B) If not, any validating parsers that are supported that do DTD validation?
>>
>>It looks like there's an experimental Xalan ext out there, but no Xerces. I
>>have a vague memory of the XML setup being generalized to allow (x) parsers,
>>did that happen, etc?
>>
>>In any case, if there aren't any validating parsers supported by PHP...
>>There should be :)
>>
>>Please respond to the binarycloud-dev list also...
>>
>>Thanks,
>>
>>_alex
>>
>>
>>-- 
>>PHP Development Mailing List 
>>To unsubscribe, visit: http://www.php.net/unsub.php
> 
> 



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

Re: [PHP-DEV] Work is beginning on cURL and PHP again

[Shane Caraveo]

Sterling Hughes wrote:

On Mon, 2002-10-21 at 22:15, Jon Parise wrote:


On Mon, Oct 21, 2002 at 10:12:55PM +0200, Sterling Hughes wrote:



* Autogenerating much of the interface between cURL and PHP, allowing
PHP to support multiple versions of the underlying cURL library


By what mechanism do you plan on implementing this?




Well, currently i plan on using a Perl script to read the curl.h
definition file, and generate the code for all options that don't meet
the following criterium:


What, you can't write a simple parser in php?  Off with his head! ;)

Shane



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

Re: [PHP-DEV] Work is beginning on cURL and PHP again

[Shane Caraveo]

Sterling Hughes wrote:

On Tue, 2002-10-22 at 01:38, Alan Knowles wrote:


Non blocking connections would be nice...

- On the generating stuff - why do you want to generate the code on the 
users system? -
all the re2c stuff in CVS is 'pre-genereated'

It would be nice to have extension generator that could be built upon, 
that didnt involve re-reading all those perl/awk manuals, just to add 
features to it. :)
Any idea if  finding 'generic' bits in the php-gtk generator is possible?


Well, the reason for the generator, is it will build an extension that
mimics the current version of cURL installed which will allow the cURL
extension to support multiple versions of the library without a lot of
maintanence and stuff :)

-Sterling


Actually, the pre-generated stuff should be done, it will make windows 
life easier.

Shane


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

Re: [PHP-DEV] short_open_tag

[Shane Caraveo]

Brad LaFountain wrote:

It would be very bad for php if short tags were disabled.
I 100% agree with andi. There are ways of dealing with xml and php
without pissing off the WHOLE php user world. I don't even use
long tags EVER, nor will I want to start.
 - Brad


Damn, that comes from a SOAP developer too ;)  Just wait till he starts 
embeding php in xsl :)

Shane


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

Re: [PHP-DEV] RFC: run-tests.php & errors/warnings

[Shane Caraveo]

The tests can only be performed using the cgi/cli sapis since they require a 
command line PHP binary. So, this is a non-issue. If we must display error 
messages then I would prefer using display_errors=1 instead of log_errors=1.

Ilia

I'm working with another person on a web version of the test script, and 
on a multithreaded test script.  Purpose is to test multithread support, 
and hopefully start finding the issues, under IIS and Apache 2.

Shane





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

Re: [PHP-DEV] Re: [PHP-DOC] Apache 2 installation instructions

[Shane Caraveo]

I did more work and testing with fastcgi and apache 2, and have php 4.3 
running under apache 2.  Since it's out of process, no multithread 
issues which are one of the major issues.  I didn't write docs, but 
there are some in sapi/cgi/README.fastcgi

Shane


As far as I can see, we should not not put into the PHP documentation that
Apache 2 is not production ready, but PHP is not production ready for
Apache 2. This is of course shows us in a negative manner, but we need to
make our users be aware of the fact that PHP should not be used for
production in Apache 2 (as long as this is the case).

Goba







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

Re: [PHP-DEV] Re: [PATCH] run-tests.php

[Shane Caraveo]

Ok - so unless Shane disagrees and gets physical, 


/me jumps around screaming after hiking up a large mountain carrying 2 
40lb. boulders...physical enough? :)

run-tests.php should
be in 4.3 and will have a totally different code-base than the version
for php 4.4/5.0.



I don't expect we'll be done with the new test stuff in time for 
4.3unless 4.3 takes *way too long* to get out.  My personal goal 
with this is to have at least some kind of automated thread based 
testing for 5, and some way to test through sapi modules.

The problem with that is, that you guys can't keep up with code changes,
but only feature changes.

The features addressed in the patch, are IMO important though.



I'm more concerned about getting the architecture of the test system 
flexible enough to have different test modes (as John has described on 
this thread).  If the layout is right, features should not be hard to 
backport into the new stuff.  But we can also try to keep up with the 
new features as we go along to lessen any issues that may arise.

Shane


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

Re: [PHP-DEV] Re: [PATCH] run-tests.php

[Shane Caraveo]

This would make a simpler test, which would not need to rely on more 
advanced
features like OO, which may change in their functionality once ZE2 comes
around, as Marcus had pointed out. Since at this point we could have 
people
running both ZE1 and ZE2 use the test, I think relying on OO is dangerous.

My reasoning is that considering the simplicity of the testing 
'engine', we do
not need to add the OO layer of obfuscation. Now, I am not a big fan 
of OO,
so my opinion on the matter maybe somewhat skewed in that regard, non

Ilia


The basics of php OO, which is all that will get used, doesn't change 
enough between ze1 and ze2 to warrent any worry about it.  If it does 
become an issue then we'll deal with it, but I find that highly unlikely.

Shane


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

Re: [PHP-DEV] prototypes for getters and setters.

[Shane Caraveo]

Anyway before I get carried away and actually test this :) - anybody got
any thoughts.

Regards
Alan



What's wrong with how overload does this?

SHane


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

Re: [PHP-DEV] prototypes for getters and setters.

[Shane Caraveo]

Alan Knowles wrote:


Shane Caraveo wrote:

>>
>>
>> Anyway before I get carried away and actually test this :) - 
anybody got
>> any thoughts.
>>
>> Regards
>> Alan
>
>
>
>
> What's wrong with how overload does this?


it has a slight downside in clarity of code - eg. where is that method..

But it (overload) also does not introduce new syntax, requires no 
changes to the engine, is genericly overrideable in extensions, etc. 
etc. etc.

Shane


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

[PHP-DEV] Re: Windows Threads

[Shane Caraveo]

John Coggeshall wrote:


Shane (and everyone else):



>Why don't we move PHP into a separate executable. Design a
>"thin" ISAPI DLL which purely passes the data which the ISAPI
>DLL exposes between the IIS process and the PHP process (or
>process-pool for added reliability). The resulting page is
>processed in the application server and returned to the ISAPI
>DLL where it is output.


Shane and I have already been looking into a similar solution for the
UNIX version of PHP. In fact, if you ask'd him I think he's already got
something working in this respect using FastCGI. 

This is exactly what fastcgi does.




Incidently, Shane weren't you involved in the Windows port of PHP? :)


Yes, I am to blame.




>I think this solution will be *way* easier than trying to fix
>every single bug in PHP so that it is utterly thread-safe and
>crash-free.


That's the idea. Part of the issue is that the external libraries PHP
uses can't be promised to be thread-safe.



An thus why I did the isapi fastcgi plugin.  www.fastcgi.com

Shane


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

Re: [PHP-DEV] Re: Windows Threads

[Shane Caraveo]

Nick Loman wrote:


Well, that's cool then! Why not simply include all this stuff with PHP
rather than supporting the flawed ISAPI that it currently is packaged
with?


4.3 the windows cgi binary is compiled with fastcgi support.  I'm going 
to be testing the fastcgi on osx this week once I get things building 
correctly, so that should allow easy building of the cgi/fcgi binary on 
osx and linux.

fastcgi itself is not php specific, and is supported from fastcgi.com.

It's not the isapi plugin itself that is at fault, and likely not too 
much of the core is a problem, it is the state of thread safety in the 
extensions and third party libraries that are used in php.  It's also a 
lack of good mt testing facilities.  And for those who dont care about 
isapi, face it, you'll have the same exact problems with apache 2 mpm.

Shane


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

Re: [PHP-DEV] Error Codes, Langs, etc

[Shane Caraveo]

I am completely +1 to the concept of taking error codes out of the PHP
core and replacing them with an XML document, period. 


I had wanted to avoid this whole thread, but decided to read this one 
message, and ouch.  While I'm all for internationalization in general, 
I'm realy not all for using xml wherever possible just because it can 
be.  There are existing techniques and libraries designed for this, find 
one and use it.

Shane


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

Re: [PHP-DEV] Error Codes, Langs, etc

[Shane Caraveo]

John Coggeshall wrote:


>I am definitely -1 for this idea. XML is a buzzword, it is
>good in some cases
>not so good in others, definitely not a one size fits all
>solution. In PHP's
>case it would add decency on an XML parser, make life of
>developers adding,
>modifying, removing error messages difficult and just like the
>documentation
>will seriously lag behind the primary (English) localization.


As I mentioned via Shane's comments... XML isn't really the crux of the
matter here, I'm more interested in the concept than implementation. I'm
interested in hearing what libraries and techniques Shane has in mind.


cats or gettext comes to mind.

man catgets
google search: internationalization cats

gettext seems to be ported more (it's on osx by default, cats isn't).

Some defines can be created so that php does not have to be compiled 
with support for it:

PHP_I18N("Some English Phrase Here")

It can be configurable via (ugh) php.ini, or LANG from the environment.

Shane


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

Re: [PHP-DEV] Error Codes, Langs, etc

[Shane Caraveo]

Sascha Schumann wrote:


>cats or gettext comes to mind.


Neither are usable, though, because PHP would need to support
multiple concurrent message catalogues on a per-thread base.
gettext/catgets associate exactly one language with each
process through the use of environment variables, so that
they cannot be used in a multi-threaded server.

A mechanism based on the bundled cdb, for example, would be
superior in terms of speed, thread-safeness, and portability.



Why?  The error messages are for the developer, not the masses.  But 
generaly I agree with using something else.  More the point is that 
stuff exists, techniques exist, no need to reinvent the wheel.
Shane


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

[PHP-DEV] apache/cgi problems with path_info and discard-path

[Shane Caraveo]

I ran into a problem with path_info using apache2/mod_fastcgi, so I
configured apache to use php as regular cgi, and have the same exact
problems.  There are basicly two problems, first, --discard-path causes
PHP to parse itself rather than the script, so I think discard-path is
basicly a bad idea.  You cannot use --discard-path with apache and cgi.
  The second is that (after compiling without --discard-path) path_info
does not work:

works:
http://localhost/info.php

fails with 500 error:
http://localhost/info.php/test

My apache config is:

ScriptAlias /php/ /path/to/php/bin/
AddType application/x-httpd-php .php
Action application/x-httpd-php /php/php-cgi

What happens is that php tries to parse the file /info.php/test rather
than /info.php.

Basicly, mod_cgi and mod_fastcgi do not provide the correct information
for several environment variables to php when configured this way.
path_info, path_translated, script_name and script_filename are all wrong.

According to CGI specs (linked to from apache docs), with the url
http://localhost/info.php/test?a=b
I *should* get:

PATH_INFO=/test
PATH_TRANSLATED=/docroot/test
SCRIPT_NAME=/info.php
REQUEST_URI=/info.php/test?a=b
SCRIPT_FILENAME=/docroot/info.php
QUERY_STRING=a=b

REQUEST_URI and SCRIPT_FILENAME are not part of CGI spec, but are apache
specific.

What I *really* get is:

PATH_INFO=/info.php/test
PATH_TRANSLATED=/docroot/info.php/test
SCRIPT_NAME=/php/php-cgi  (from the Action setting I suppose)
REQUEST_URI=/info.php/test?a=b
SCRIPT_FILENAME=/path/to/php/bin/php-cgi  (Action setting translated)
QUERY_STRING=a=b

Further, PATH_INFO should always be empty if no extra path info is
used in the request (ie. http://localhost/info.php).

PHP_SELF is also quite wrong since it is basicly PATH_INFO.

Now, if I set up PHP to use the CGI handler in this way:

Options +ExecCGI
AddHandler cgi-script .php

And add a bang line to my script:

#!/path/to/php-cgi

I get the correct settings (well, I did that with perl and it gets the
correct stuff, so php should as well).  However having to do this is
evil, since PHP apps typically do not have the bang line, we keep
changing the executable names, people install php to different
locations, and so forth.

I also beleive this is the same reason path_info has never worked in cgi
under IIS.

So, unless anyone has a better idea, or my apache config is extremely
wrong, I'm going to rip apart the whole file handling situation in
php-cgi and fix it to work right, and provide the correct CGI spec'd
values.  This will involve parsing the above variables, figuring out
what the right settings are, doing at least one stat() call (more if
extra path_info is used), and modifying the environment prior to calling
php_request_startup.  This will also fix my fastcgi problem as they are
the same.  I already have part of the patch done that fix path_info and
path_translated.

Shane




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

Re: [PHP-DEV] C++ extensions and ext_skel

[Shane Caraveo]

I think that would be quite cool, save me from having to do it manualy.
Shane

J Smith wrote:

A couple of times a month, I get questions about from people looking to use 
C++ with PHP. Apparently, a lot of people end up reading some post I made 
to php.dev or something a year or so ago about C++, and although it worked 
at the time, the procedure I describe has become stale.

I messed around a bit with ext_skel and ext/skeleton today and added an 
option to ext_skel (--cpp) that creates a basic C++ extension rather than 
the standard C extension. The C++ extension is pretty much the same as the 
standard C extension, with the exception of some extern "C" linkage, 
modifications to config.m4 and Makefile.in and a small C++ class thrown in 
for fun.

Would this be worth adding to PHP proper? I have patches available for 
4.2.3, but if it's worthy, I can whip it up for 4.3 or whatever. It'll save 
me some email bandwidth if it could be used.

J




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

Re: [PHP-DEV] [PATCH] Changes to ext_skel for C++

[Shane Caraveo]

J Smith wrote:

Attached is a patch to ext_skel that adds an optional argument (--cpp) that 
will create a PHP extension in C++ rather than C. Also attached is 
skeleton.cpp, which basically mirrors ext/skeleton/skeleton.c with a few 
modifications for using C++. I could've just made some changes to 
skeleton.c and done some sed work in the ext_skel script, but I think it's 
clearer to have them separated into two files. 

The ext_skel patch is based on the current HEAD.

Comments?

J

skeleton.h also needs to be dealt with.  If you do not, visual studio 
will export symbols as c++ symbols and the extension will not work. 
Simple solution is to have

#ifdef __cplusplus
extern "C" {
#endif

at the top of skeleton.h, and close it at the bottom.

Shane




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

Re: [PHP-DEV] [PATCH] Changes to ext_skel for C++

[Shane Caraveo]

Is there any reason the ifdef __cplusplus doesn't work?  There shouldn't 
be any need for extra processing or config options.

J Smith wrote:
How about adding something like this to skeleton.c:

/* __begin_extern_c__ */
/* __end_extern_c__ */

And having the sed script in ext_skel replace them with the proper extern 
"C" stuff? That way there's no need for skeleton.cpp and just a few changes 
need to be made in skeleton.c.

J


Sascha Schumann wrote:


On Fri, 29 Nov 2002, J Smith wrote:



Attached is a patch to ext_skel that adds an optional argument (--cpp)
that will create a PHP extension in C++ rather than C. Also attached is
skeleton.cpp, which basically mirrors ext/skeleton/skeleton.c with a few
modifications for using C++. I could've just made some changes to
skeleton.c and done some sed work in the ext_skel script, but I think
it's clearer to have them separated into two files.


   I'm reluctant to duplicate the contents of the .c file for
   maintenance reason.  Cannot you just put the C++ specific
   code into a

   /* Remove this part, if this is not a C++ extension */
   #ifdef __cplusplus

   #endif

   section?

   - Sascha








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

[PHP-DEV] PHP 4.3 broken CGI behaviour

[Shane Caraveo]

Hello,
I just commited patches to fix CGI running under Apache.  This also 
fixes issues with incorrect CGI environment variables that are received 
under ScriptAlias based CGI or mod_fastcgi.  My previous email 
describing this is at 
http://marc.theaimsgroup.com/?l=php-dev&m=103834043816376&w=2

Essentialy, I think that these patches should be put into 4.3, due to 
the extreme broken behaviour that 4.3 currently has in CGI mode. 
However, since i'm not involved in release management, I'll leave the 
decision to do that to those who are.

Regards,
Shane


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

Re: [PHP-DEV] Error during buildconf..

[Shane Caraveo]

Is this just starting?  How long since your last configured?  I just 
added two new m4 files, but they shouldn't get used unless you 
--enable-fastcgi, did you do that?
Shane

Magnus Määttä wrote:
On Mon, 2 Dec 2002 04:39:34 +0200 (EET)
Jani Taskinen <[EMAIL PROTECTED]> wrote:



   I get this with PHP_4_3_0 branch (with Linux):
   
/usr/bin/autoheader: Symbol `size_t' is not covered by /usr/share/autoconf/acconfig.h ./acconfig.h
   


I get the same result and this too (in both HEAD and 4.3 branch):

/usr/bin/autoheader-2.13: Symbol `uint' is not covered by /usr/share/autoconf/acconfig.h
/usr/bin/autoheader-2.13: Symbol `ulong' is not covered by /usr/share/autoconf/acconfig.h

The same problem is on Tru64.




   And main/php_config.h.in is not created. 
   (this does not happen with HEAD)



And not in HEAD either for me.




   --Jani


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









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

Re: [PHP-DEV] Error during buildconf..

[Shane Caraveo]

Jani Taskinen wrote:

On Mon, 2 Dec 2002, Jani Taskinen wrote:



  I get this with PHP_4_3_0 branch (with Linux):
  
   /usr/bin/autoheader: Symbol `ssize_t' is not covered by /usr/share/autoconf/acconfig.h ./acconfig.h
  
  And main/php_config.h.in is not created. 
  (this does not happen with HEAD)



Forgot to test after noticing this..the build does not work
at all now. (of course, as php_config.h.in is missing, php_config.h
ends up being an empty file..)


Well, I can't recreate the problem in either 43 or HEAD.
Shane



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

[PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_3) /sapi/cgi cgi_main.c

[Shane Caraveo]

It's not a matter of php cgi just having a couple bugs, it was 
completely broken.  If we don't put it in 4.3, pull the cgi module out 
entirely because it's useless.  Yet another point of view also, since no 
one has seriously complained about it's brokeness, it can't realy effect 
many people either if it is in 4.3.
Shane

Andi Gutmans wrote:
Are you sure we should have this stuff in the branch of 4.3? Are these 
bugs which didn't exist in 4.2.3?
If they did exist I'm -1. If they didn't exist then that's life and the 
patch should stay in but people familiar with CGI should review it 
carefully.

Andi

At 02:21 AM 12/2/2002 +, Shane Caraveo wrote:

shane   Sun Dec  1 21:21:01 2002 EDT

  Modified files:  (Branch: PHP_4_3)
/php4/sapi/cgi  cgi_main.c
  Log:
  MFH


Index: php4/sapi/cgi/cgi_main.c
diff -u php4/sapi/cgi/cgi_main.c:1.190.2.6 
php4/sapi/cgi/cgi_main.c:1.190.2.7
--- php4/sapi/cgi/cgi_main.c:1.190.2.6  Sun Dec  1 18:27:14 2002
+++ php4/sapi/cgi/cgi_main.cSun Dec  1 21:21:01 2002
@@ -369,6 +369,7 @@
} else {
snprintf(buf,len-1,"%s=", name);
}
+
 #if PHP_FASTCGI
/* when php is started by mod_fastcgi, no regular environment
   is provided to PHP.  It is always sent to PHP at the start
@@ -597,8 +598,10 @@
struct stat st;
char *env_script_name = 
sapi_cgibin_getenv("SCRIPT_NAME",0 TSRMLS_CC);
char *env_path_info = 
sapi_cgibin_getenv("PATH_INFO",0 TSRMLS_CC);
+   char *env_redirect_url = 
sapi_cgibin_getenv("REDIRECT_URL",0 TSRMLS_CC);
if (env_path_info) env_path_info = 
estrdup(env_path_info);
-   if (sapi_cgibin_getenv("REDIRECT_URL",0 
TSRMLS_CC) ||
+
+   if (env_redirect_url ||
(env_script_name && env_path_info &&

strcmp(env_path_info,env_script_name)==0)) {
/*
@@ -611,6 +614,8 @@
*/

_sapi_cgibin_putenv("SCRIPT_FILENAME",env_path_translated TSRMLS_CC);
_sapi_cgibin_putenv("PATH_INFO",NULL 
TSRMLS_CC);
+   if (env_redirect_url)
+ _sapi_cgibin_putenv("SCRIPT_NAME",env_redirect_url TSRMLS_CC);
}

if (stat( env_path_translated, &st ) == -1 ) {
@@ -620,7 +625,7 @@

while( (ptr = strrchr(pt,'/')) || (ptr 
= strrchr(pt,'\\')) ) {
*ptr = 0;
-   if ( lstat(pt, &st) == 0 && 
S_ISREG(st.st_mode) ) {
+   if ( stat(pt, &st) == 0 && 
S_ISREG(st.st_mode) ) {
/*
* okay, we found the 
base script!
* work out how many 
chars we had to strip off;



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







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

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_3) /sapi/cgi cgi_main.c

[Shane Caraveo]

Zeev Suraski wrote:
> How does this patch possibly fix something in this magnitude?  It
> doesn't appear to do anything crucial at all, or do these variables have
> some far-reaching indirect effect?
>
> Zeev

Well, the one patch refered to in this thread was only a minor fix over 
the previous patches I applied yesterday.

I did send out emails regarding and describing this problem 
(http://marc.theaimsgroup.com/?l=php-dev&m=103834043816376&w=2) with no 
response so aparently no one cares until after I fix the problem ;)

The basics in case you don't want to read my long email...

When was this broken?  A very long time ago, possibly/probably the 
entire 4 series.

Are there bug reports?  Yes, some inapropriately marked bogus.

Does the patch present potential problems?  Sure, it's a significant 
patch that changes the way the cgi module works, but at least, minus any 
bugs, it works, which is much better than not having the patch at all. 
I have tested this on win32 and osx, as cgi and fastcgi, under apache 
1.3/2.0 and IIS, which is probably the most testing CGI has gotten in a 
very long time.

Should it go in 4.3?  I strongly think so.  It would be sad and ironic 
to have yet another release with cgi that doesn't work at all (given 
that PHP is *the* Web language).  I think it's worth an extra release 
cycle and extra QA to have this in.

Could the patch be better written?  Sure, I don't claim to be a supreme 
C developer.  There are memory allocations in there I'd like to get rid 
of at a later time, and I think the 'backwards broken compatibility' 
should be removed.

Now the long part.
So, why did this have to happen?

First, PATH_INFO was being used for PHP_SELF, which prior to the fix, 
apache set to the php binary.  The cgi module used SCRIPT_FILENAME if 
DISCARD_PATH was set, and again, this would be set to the php binary by 
apache, so php would parse itself and not the script desired.  Third, 
none of the CGI variables (as defined in CGI spec) were ever correct. 
This broke using PATH_INFO in applications (one example being the pres2 
system).  These variables are the primary targets of the patch since 
they are required for proper execution of php as CGI.  However, since 
other variables were also wrong (SCRIPT_NAME and PATH_TRANSLATED) rather 
than just fixing what PHP absolutely needed to operate right, I fixed 
them all.  Then, additionaly, using the mod_cgi cgi_script directive 
(using bang lines in php) was broken, thus the small patch to 
fopen_wrappers.c.

This stuff has been broken for a very long time, since before 4.2 if I 
remember right.  In the last month, I've seen at least two non-php 
people attempt to set up php cgi and give up due to these bugs.  I 
didn't realy clue in to how broken it was until I saw that, then tried 
it myself on my shiny new mac.  The self-parsing of the php binary did 
not occure on IIS because IIS sends the script name as an argument when 
executing php, and that would override the environment variables, but 
PATH_INFO was still broken.

There are bugs in the bug database that this fixes also, one example: 
http://bugs.php.net/bug.php?id=19378

There are also bugs marked as bogus that probably were not, one example: 
http://bugs.php.net/bug.php?id=10075.  (CGI and PATH_INFO aparently is 
not understood in this instance)

Shane



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

Re: [PHP-DEV] Re: sapi/fastcgi

[Shane Caraveo]

works fine for me without exiting, under mod_fastcgi on win32 and osx 
and my iis/fastcgi.  There was a problem with exiting after each request 
on windows, but I fixed that a couple weeks ago.
Shane


Harald Radi wrote:
i wasn't able to run it succesfully on windows. i can compile it and the
binary actually works, but it exits after each request instead of keep
running. but this is on my todo list for the christmas holidays, so stay
tuned :)

harald



-Original Message-
From: Stanislav Malyshev [mailto:[EMAIL PROTECTED]] 
Sent: Wednesday, December 04, 2002 5:29 PM
To: Harald Radi
Cc: [EMAIL PROTECTED]
Subject: Re: [PHP-DEV] Re: sapi/fastcgi


HR>> as neither of them works you can remove both :)

What do you mean neither works? I have Zeus/PHP/FastCGI 
install with PHP 
4.2.3 running here, seems working. Am I missing something? 

--
Stanislav Malyshev, Zend Products Engineer   
[EMAIL PROTECTED]  http://www.zend.com/ +972-3-6139665 ext.109










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

Re: [PHP-DEV] sapi/fastcgi

[Shane Caraveo]

sapi/fastcgi should be deprecated.

Sebastian Bergmann wrote:

  What happens to sapi/fastcgi, now that we have FastCGI support in
  sapi/cgi?

  IMHO, it should be removed for PHP 4.3.0 already.





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

Re: [PHP-DEV] php.exe - php-cgi.exe

[Shane Caraveo]

Simply because calling the command line interface should be easy - as easy
as calling awk or perl or whatever. Every server api module like cgi must be
installed, so the name does not matter there. But having long names for
command line utils is a bad idea.

marcus




Well, fortunately I never have time for qa, handling bugs, etc. etc. so
I wont have to deal with the backlash that this name change **WILL**
cause.  I feel sorry for those who have the time to deal with it, as
that will be about all they will deal with, rather than handling more
important bugs and issues.  Basicly, the namechange goes against several
years of history in php, tons of documentation, general community
knowledge, etc., and top it off with the fact that in reality, probably
less than 1 percent of users use php as a command line language.

Shane



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

Re: [PHP-DEV] php.exe - php-cgi.exe

[Shane Caraveo]

Jani Taskinen wrote:

On Mon, 9 Dec 2002, Shane Caraveo wrote:



Simply because calling the command line interface should be easy - as easy
as calling awk or perl or whatever. Every server api module like cgi must be
installed, so the name does not matter there. But having long names for
command line utils is a bad idea.

marcus




Well, fortunately I never have time for qa, handling bugs, etc. etc. so
I wont have to deal with the backlash that this name change **WILL**
cause.  I feel sorry for those who have the time to deal with it, as
that will be about all they will deal with, rather than handling more
important bugs and issues.  Basicly, the namechange goes against several



Don't worry, we'll make some quick-resolve for it too.
We didn't get overwhelmed by that register_globals issue either.
(like some people thought we would :)



years of history in php, tons of documentation, general community
knowledge, etc., and top it off with the fact that in reality, probably
less than 1 percent of users use php as a command line language.



It's evolution. :) And we do hope that the amount of people using 
PHP on command line increases. Besides, having the "php-cgi" binary
makes it very clear what it is about. But naming the CLI binary 
"php-cli" definately does not.

I'm actually a bit uncertain why we actually have separate binaries.
(or I've forgot why they were separated..anyone?)
 
--Jani

"evolution" doesn't cut it.  It would have been simple enough to combine 
cli into the cgi binary and be done with it, and I suggested as much 
that it should be done a very long time ago.  I don't recall any major 
reasons why it wasn't done, other than that cli has been experimental. 
"evolution" would have been to fix the executable we have had, rather 
than creating multiple executables that do essentialy the same thing, 
and this issue would have been avoided altogether.
Shane




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

Re: [PHP-DEV] php.exe - php-cgi.exe

[Shane Caraveo]

  3.) Why this late discussion of the issue? The name of the sapi/cgi
  binary was changed months ago!



I did not choose to raise the issue at this time, but I agree completely 
with the opinion that it's a bad thing;  It is my fault that I haven't 
raised it a few months ago when I noticed this change, but as you might 
have noticed, I wasn't involved at php-dev back then.  But either way, 
the fact that it was changed months ago is meaningless.  It never made 
it to a release, and it shouldn't make it to a release, and that's the 
important thing in my opinion.

Zeev


I on the other hand do recall complaining about this issue, into the 
typical php-dev vacume.  My strong suggestion at the time was to move 
things back to one binary, which i still beleive is the best solution, 
exactly for the ease of use issues that Zeev brings up.

Shane


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

Re: [PHP-DEV] CGI and CLI

[Shane Caraveo]

Robin Thellend wrote:

On Wed, 18 Dec 2002, Derick Rethans wrote:

[...]


I didn't say that it should be changed from php to php-cgi, as I do
think that would be bad.

Derick



Why don't you just add a simple check in the CLI code to exec() the CGI
binary if it is called as a CGI?

if(getenv("GATEWAY_INTERFACE") != NULL)
  execv("/path/to/php-cgi", argv);


Lets not compound one bad idea with another.

Shane


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

Re: [PHP-DEV] CGI and CLI

[Shane Caraveo]

Plain and simple, and it is the ONLY way that 4.3 can be released. 
There is no way in hell I would support the release of PHP with the cli 
binary replacing the cgi binary.  Change it back to the way it was in 
4.2.x since there is no time to properly fix the problem.  Leave it 
marked experimental with a big note that the binary name may change in a 
later release.

Andrei Zmievski wrote:
What was the consensus on CGI vs. CLI naming or merging issue? Or was
there a consensus at all? I full plan to go ahead with 4.3.0 release
before the end of the year, so those interested in doing anything about
this issue better get their butts in gear.

-Andrei   http://www.gravitonic.com/

"This isn't right. This isn't even wrong."
   -- Wolfgang Pauli





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

Re: [PHP-DEV] CGI and CLI

[Shane Caraveo]

I would agree that this is a big problem.
Shane

Andrei Zmievski wrote:

On Wed, 18 Dec 2002, Sascha Schumann wrote:


   The next point release after 4.2.0 was 4.2.1.

   There are too many major changes in 4.3 vs. 4.2 to call it a
   'point release'.



Semantics.



   Especially, there are still significant
   backwards compatibility bugs, such as

   http://bugs.php.net/bug.php?id=20441



Does everyone agree that it's a BC bug? If so, who is going to fix it?

-Andrei   http://www.gravitonic.com/
* if you hold a unix shell to your ear, do you hear the c? *





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

Re: [PHP-DEV] CGI and CLI

[Shane Caraveo]

Andrei Zmievski wrote:

On Wed, 18 Dec 2002, Andi Gutmans wrote:


I doubt this will happen fast enough. We should just release the way we 
released 4.2.x, which as far as I know was php for CGI and php-cli for CLI 
or am I a bit behind things? :)


Derick and I hashed it out on IRC and we have a proposal:

We should keep 4.2.x behavior with some modifications. CLI and CGI
should always be built unless disabled, and the executables should go
into sapi/cli/php and sapi/cgi/php, respectively. In addition, 'install'
target should be modified to detect whether the user is trying to
install either one of these SAPIs, output a warning message regarding
the potential naming problem, and stop. Let the user install CLI and CGI
manually, basically.

I really hope we can come to an agreement on this.


I can agree to, and live with, this to some extent.  The changes I would 
want on this would be...

* On win32, cli remains php-cli.exe.  Windows users can rename the 
executable if they feel it's necessary.

* On other platforms, the cgi *is* installed by 'make install' by 
default.  To install cli something like, 'make install-cli', or 
'configure --install-cli=[DIR] --install-cgi=[DIR]' can be used (the 
second option would be more usefull for installing both, using both 
without [DIR] on one results in a configure error).  A note regarding 
what was installed and where should be added to the output resulting 
from an install.

* Binaries are combined into a single binary in a later release.  I'd be 
happy to do this in January.

* Documentation is added in regards to this issue.

Shane




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

Re: [PHP-DEV] CGI and CLI

[Shane Caraveo]

No.  At the most, if anything, CLI should output an error message:

if(getenv("GATEWAY_INTERFACE") != NULL) {
  printf("This is the PHP CLI binary, please configure your server to 
use the correct PHP CGI binary.");
  exit(1);
}

Xavier Spriet wrote:
Great.
In that case, in order to make things a little smoother for users, could
a little workaround like the one offered by Robin be considered ?



On Wed, 2002-12-18 at 17:21, Andrei Zmievski wrote:


On Wed, 18 Dec 2002, Philip Olson wrote:


So every tutorial and documentation on this would have to
say this right?

 "Ask your sysadmin what the CGI and CLI versions of your
  PHP are called, they could be anything as there is no
  standard.  For the purpose of this (tutorial|documentation), 
  we'll call CLI php-cli and CGI php-cgi."

Same goes for all cgi scripts, they'll work some places but
not others...  And various RPM's would have different naming
schemes depending on the maintainers preference.

The merging of CLI and CGI will still happen, but in 4.3.1.

-Andrei   http://www.gravitonic.com/
* Marriage is not a word. It's a sentence. Life-long sentence. *




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

Re: [PHP-DEV] CGI and CLI

[Shane Caraveo]

Edin Kadribasic wrote:




* On other platforms, the cgi *is* installed by 'make install' by
default.  To install cli something like, 'make install-cli', or
'configure --install-cli=[DIR] --install-cgi=[DIR]' can be used (the
second option would be more usefull for installing both, using both
without [DIR] on one results in a configure error).  A note regarding
what was installed and where should be added to the output resulting
from an install.



I really don't understand why insist on cgi being installed on "make
install" to ${PREFIX}/bin? The solution outlined by Andrei and Derick is
much better IMHO because it will alert users of the issue and because
installing a cgi into a webserver requires manual action anyway.


It's realy very logical.  It leaves the default installation the way 
most people will expect it to behave, which is as it has been for years 
now.  Having the options allow people to modify that behaviour to the 
way they want it to work.  It's very flexable for all interests.



* Binaries are combined into a single binary in a later release.  I'd be
happy to do this in January.



-1 for reasons i stated in my reply to Andrei.


None of the reasons I have seen listed against this are insurmountable. 
The *only* reason I have seen (ie. remember at this moment) that 
comes close to convincing me otherwise is the one that you stated:

"In practice this would mean that one would be unable to run php
command line scripts from within webserver environment, through system()
call from other cgi/php scripts etc."

The problem is that cli was started as a seperate binary and no thought 
was put into having things work as a single binary.  I'm not convinced 
that there isn't a way around the system() issue yet...but you may have 
a point.  It could be done by using a flag in that instance (php -f 
script.php for instance) but that is not optimal.

Shane




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

Re: [PHP-DEV] CGI and CLI (compromise proposal)

[Shane Caraveo]

good for me.
Shane

Edin Kadribasic wrote:

After having consulted with Andrei, Derick and others on irc here is
a proposal for a compromise:

On Unix:

1. Both cgi and cli are built as 'php' in their respective sapi
directories (pretty much as it is today except that cgi gets renamed
back from php-cgi to just php).
2. Make install will *not* install cli if cgi build was selected
(only cgi gets installed).
3. A new install target 'install-cli' is introduced so that make
install-cli will overwrite whatever is in $(PREFIX)/bin/php.

On Windows:

1. php.exe in the root of distribution is php cgi sapi.
2. New cli directory is included with php.exe (cli) in it.

If this is an acceptable compromise I volunteer to do the changes
required.

Edin






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

Re: [PHP-DEV] [PATCH] CLI and CGI defaults

[Shane Caraveo]

But --enable-cli is now a useless switch, because:
* if you don't specify it, cli is built
* if you specify it, cli is built
* if you don't specify it, cli is not installed
* if you specify it, cli is not installed

Only --disable-cgi (--enable-cli still makes no difference) will install cli on make install.


That is the correct behaviour.  --enable-cli is a default, thus you do 
not have to define it to build cli.  'make install-cli' is used to 
install cli rather than cgi.  I don't see the confusion in that.

Shane


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

Re: [PHP-DEV] Bug # 21261 -- PHP_SELF not set correctly with sapi/CGI

[Shane Caraveo]

Sara Golemon wrote:

It looks like the correct behavior was broken with patch 1.199 to
php/sapi/cgi/cgi_main.c

Because there are a number of modifications in this patch and I don't want
to go messing it up any further I'll ask the original patch submitter
(shane) to take a look and reconsider the argv0 hack that was removed with
this patch.  ((Assuming that is indeed the source of the problem))

-Pollita


the argv0 hack is bad since it doesn't fix the bug, just masks it on 
servers that provide that.  There is an off-by-one bug somewhere in 
init_request_info(), if I can get the httpd.conf info I requested in the 
bug, I can figure out what is happening and fix it correctly.

Shane


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

Re: [PHP-DEV] PHP in 2003 (leading to PHP 5)

[Shane Caraveo]

Roadmap:

1.  Switch to ZE2 by default
2.  Establish PECL CA authority and binary package/release process
(particularly important for win32)
3.  Bundle PHP-Soap (and stop the "bleeding of PHP users")
3a. Collect underpants
4.  ?
5.  Profit


#3 doesn't belong in a general roadmap.  What does fit in, that also 
covers #3, is having all extensions moved out to pecl, and a 
build/release system that can build distribution packages based on the 
last stable release of extensions in pecl.

With that (for example only), different distribution packages can be 
built when php releases occure, such as 'php core' which would contain 
the 'most important' stable extensions, 'php stable' which would contain 
all stable extensions, and 'php bleeding' which could be a package with 
the latest development snapshot at time of release.

With this also extensions now can take on a life of their own, releasing 
at different times than php, and visaverse.  I think this would make 
releasing new versions of php much more manageable.

Shane




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

[PHP-DEV] bug database

[Shane Caraveo]

Can someone update/replace/give me my password for the bug database.
Thnx
shane

-- 
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]

Re: [PHP-DEV] Re: [ZEND-ENGINE] cvs: Zend / zend_API.c zend_API.h

[Shane Caraveo]

Why not add a:

#define snprintf _snprintf

to the zend_config.w32.h file?  That should take care of the mentioned
compile problem under windows.

- Original Message -
From: "Andrei Zmievski" <[EMAIL PROTECTED]>
To: "Zeev Suraski" <[EMAIL PROTECTED]>
Cc: "php-dev mailinglist" <[EMAIL PROTECTED]>
Sent: Monday, March 12, 2001 6:09 AM
Subject: Re: [PHP-DEV] Re: [ZEND-ENGINE] cvs: Zend / zend_API.c zend_API.h


> Use zend_snprintf() instead or what?
>
> On Mon, 12 Mar 2001, Zeev Suraski wrote:
> > snprintf() isn't accessible in the Zend engine...
> >
> > Zeev
> >
> > At 08:43 12/3/2001, Sebastian Bergmann wrote:
> > >Andrei Zmievski wrote:
> > > > andrei  Mon Mar 12 05:08:29 2001 EDT
> > > >
> > > >   Modified files:
> > > > /Zend   zend_API.c zend_API.h
> > > >   Log:
> > > >   Improve zend_is_callable() to the point where it's actually
useful.
> > > >   Now it just needs to be invoked everywhere in PHP where a callback
is
> > > >   expected.
> > >
> > >   This breaks the Win32 build:
> > >
> > >zend_API.c
> > >D:\Programme\MS Visual Studio\Projekte\php\php4\Zend\zend_API.c(958) :
> > >warning C4013: 'snprintf' undefiniert; Annahme: extern mit Rueckgabetyp
int
> > >
> > >ZendTS.lib(zend_API.obj) : error LNK2001: Nichtaufgeloestes externes
Symbol
> > >_snprintf
> > >..\Release_TS_inline\php4ts.dll : fatal error LNK1120: 1 unaufgeloeste
> > >externe Verweise
> > >
> > >--
> > >  sebastian bergmann e-mail :
[EMAIL PROTECTED]
> > >   homepage :
http://www.sebastian-bergmann.de
> > >make a gift :
http://wishlist.sebastian-bergmann.de
> > >  measure the usability of your web application ->
http://phpOpenTracker.de
> > >
> > >--
> > >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]
> >
> > --
> > Zeev Suraski <[EMAIL PROTECTED]>
> > CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/
> >
>
>
>
> -Andrei
>
> Any sufficiently advanced bug is
> indistinguishable from a feature.
> -- Rich Kulawiec
>
> --
> 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 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]

Re: [PHP-DEV] PHP 4.0 Bug #9999: php.exe doesnt start

[Shane Caraveo]

Go to www.microsoft.com/data/ and download/install MDAC.

- Original Message - 
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, March 26, 2001 9:12 AM
Subject: [PHP-DEV] PHP 4.0 Bug #: php.exe doesnt start


> From: [EMAIL PROTECTED]
> Operating system: win98
> PHP version:  4.0.4pl1
> PHP Bug Type: *Install and Config
> Bug description:  php.exe doesnt start
> 
> 
> php.exe does not start. ERROR: can not find odbc32.dll
> where do i get that dll? can someone give me a link?
> i have searched the net for that dll, but did not find it.
> 
> i'm using win98, standard installation.
> 
> It does not work to download dcom, like described in another
> bug-report.
> 
> thx,
> wolle
> 
> 
> -- 
> Edit Bug report at: http://bugs.php.net/?id=&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 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] ISAPI/NSAPI FastCGI implementations available

[Shane Caraveo]

Hello everyone,
Over the past few months I've slowly worked on implementing ISAPI and NSAPI
modules for FastCGI.  I've got everything done and working now in probably
what I would call a late alpha or early beta release, though I haven't
versioned it at this time.

I wrote these modules to provide a super stable way to run PHP on Windows,
without having to resort to CGI.  For those who don't know much about
FastCGI...using the FastCGI module for PHP, there are no threading issues
since any one executable will only handle one request at a time, but you
gain the performance increase of having persistent executables in memory.
This allows for persistent database connections, etc.  Since PHP is also run
out-of-process, there is no way PHP can crash a web server (unless there is
a bug in my modules :).   In my own tests using MS Web Stress Application, I
got performance improvements ranging from 4x to 8x the speed of CGI.   The
downside to FastCGI is that it will require more memory than a multithreaded
sapi module.

Ultimately, I don't think FastCGI can achieve the same performance as and
built in web server module (ISAPI, etc.), but it is a good alternative,
especially if you use modules that crash PHP under ISAPI, and is much more
suited to production systems than CGI.

While this should be perfectly usable with something other than PHP, I have
not tested anything but PHP with it.

You will need phpfcgi.exe also, which I am not sure if that is distributed
in the binary distributions on php.net.  If not, I'll make one available
this weekend (if someone doesn't beat me to it).

I'll probably be combining this source code with the fastcgi libraries at
fastcgi.com in the next month or so.  There is still work to be done on this
implementation, some stuff is not yet supported (such as authentication),
and the process manager is a bit kludgy but works.   A port to unix will
hopefully happen eventualy.  I also implemented a small version of the SAPI
layer so that server modules can be added easily.

You can download at:
binaries: www.caraveo.com/fastcgi/fastcgi.zip
source: www.caraveo.com/fastcgi/fastcgi.src.zip

Regards,
Shane Caraveo




-- 
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]

Re: [PHP-DEV] CLI and php.ini

[Shane Caraveo]

Hmm, actually -c takes a path.

- Original Message -
From: "brad lafountain" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, February 19, 2002 4:47 PM
Subject: Re: [PHP-DEV] CLI and php.ini


>
> The magic
> #!/usr/local/bin/php -c local.ini
> already works
>
>
> - brad
> --- J Smith <[EMAIL PROTECTED]> wrote:
> >
> > From what I understand, starting with PHP 4.2.x, PHP is going to
> > automatically build with a CLI executable by default. This means that
even
> > when you install as, say, an Apache SAPI module, you're still going to
get
> > the CLI, correct?
> >
> > That being the case, a few months ago a thread popped up about
seperating
> > the php.ini files that web server modules and the CLI executable run on.
> > Has there been any more thought on this?
> >
> > The differences between the CLI executable and web server modules can be
> > drastic enough to warrant this sort of thing, imho. I regularly build
both
> > the executable and web server modules all the time on the same machine,
and
> > having them both point to the same php.ini can sometimes cause havoc, as
> > usually they're not configured anything alike. (For instance, I usually
use
> > output buffering for the web server configuration, but not for the CLI.)
> >
> > I've also run into problems with a few extensions that don't run with
> > things like the Zend optimizer. (PCNTL comes to mind -- obviously it's
only
> > useful in the CLI executable, but the Zend optimizer refuses to work
with
> > it at all, yet I still want to use it on the web server -- thus
requiring
> > seperate php.ini configurations.)
> >
> > I know that you can set PHPRC to another path before starting PHP up,
> > either as CLI or from a web server, but it's quite a pain. There are
also a
> > few other work arounds, like the magic "#!" token at the beginning of
shell
> > scripts (which isn't at all portable), but I'm still thinking the best
> > solution would be to split the php.ini files in two -- one for the web
> > server SAPI and one for the CLI. Call them php.ini and php-cli.ini or
> > something.
> >
> > Or am I just crazy?
> >
> > J
> >
> >
> >
> > --
> > PHP Development Mailing List 
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
>
>
> __
> Do You Yahoo!?
> Yahoo! Sports - Coverage of the 2002 Olympic Games
> http://sports.yahoo.com
>
> --
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
>


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

[PHP-DEV] output/threads aborting

[Shane Caraveo]

Hello everyone,

With the current CVS debug_ts build I'm getting an abort in the TSRM
library.  I've tracked this down to php_module_startup() in main.c.  The
call to php_output_startup() on line 783 accesses thread specific data,
however the output module is not started (thus no thread data alocated)
until php_startup_internal_extensions() is called on line 873.  Simply
moving the call to php_output_startup, but it looks like this might need to
happen before that point in startup.  I don't want to commit that change
without somebody a bit more knowlegable on the output stuff looks into this.

Shane



-- 
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]

Re: [PHP-DEV] output/threads aborting

[Shane Caraveo]

> >With the current CVS debug_ts build I'm getting an abort in the TSRM
> >library.  I've tracked this down to php_module_startup() in main.c.  The
>
> This is probably due to my patch yesterday of moving the output
> initialization from GINIT to MINIT.
> In php_module_startup() can you try moving php_output_startup() after
> php_startup_internal_extensions() and see if things are working.
> If not then please revert my patch from yesterday and I will take another
> look at what can be done.
>

That is what I did to get things working, and for anything I am doing, it is
working, but I have not done any testing to prove it's the best fix.  Shall
I commit the change?

Shane



-- 
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] Re: [PHP-CVS] cvs: php4 /sapi/cgi cgi_main.c

[Shane Caraveo]

Can this be put into the 4.0.6 tree?

- Original Message - 
From: "Shane Caraveo" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, May 22, 2001 4:05 PM
Subject: [PHP-CVS] cvs: php4 /sapi/cgi cgi_main.c 


> shane Tue May 22 16:05:09 2001 EDT
> 
>   Modified files:  
> /php4/sapi/cgi cgi_main.c 
>   Log:
>   The -c commandline option was not working at all, need to set the path
>   override before calling on the module startup.



-- 
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]

Re: [PHP-DEV] output/threads aborting

[Shane Caraveo]

Oh, sorry for the last email, didn't see this one yet.  Thanks!
Shane

- Original Message -
From: "Andi Gutmans" <[EMAIL PROTECTED]>
To: "Shane Caraveo" <[EMAIL PROTECTED]>; "php-dev mailinglist"
<[EMAIL PROTECTED]>
Sent: Wednesday, May 23, 2001 9:57 AM
Subject: Re: [PHP-DEV] output/threads aborting


> Shane,
>
> Please try the latest CVS. I commited a patch.
>
> Andi
>
> At 03:48 PM 5/22/2001 -0700, Shane Caraveo wrote:
> >Hello everyone,
> >
> >With the current CVS debug_ts build I'm getting an abort in the TSRM
> >library.  I've tracked this down to php_module_startup() in main.c.  The
> >call to php_output_startup() on line 783 accesses thread specific data,
> >however the output module is not started (thus no thread data alocated)
> >until php_startup_internal_extensions() is called on line 873.  Simply
> >moving the call to php_output_startup, but it looks like this might need
to
> >happen before that point in startup.  I don't want to commit that change
> >without somebody a bit more knowlegable on the output stuff looks into
this.
> >
> >Shane
> >
> >
> >
> >--
> >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 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 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] getting libtool to take .a files

[Shane Caraveo]

Anyone know how to setup the config.m4 and Makefile.in of an extension so
that when it is built, libtool will accept staticly linking a .a file into
the .so that is being created?  (ie. I need to create a loadable php module
that has staticly linked in a .a file).

Thanks,
Shane



-- 
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] tsrm patch

[Shane Caraveo]

Hello,
Sending this little fix to the dev group, since I don't beleive I have
write access into TSRM.  Can someone get this submitted?  

In tsrm_win32.c, line 138, change the +4 to +5 to allow for the trailing
null character:

- cmd = (char*)malloc(strlen(command)+strlen(TWG(comspec))+4);
+ cmd = (char*)malloc(strlen(command)+strlen(TWG(comspec))+5);

Without this, debug builds crash when cmd is freed.
Shane

-- 
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]

Re: [PHP-DEV] tsrm patch

[Shane Caraveo]

Hi Andi,

Here is yet another patch to tsrm.  The popen implementation was
broken.  You could not write to a process because pclose did not wait
for a process to end, and the executed process could hang, because both
sides of the pipe were inheritable.

Index: tsrm_win32.c
===
RCS file: /repository/TSRM/tsrm_win32.c,v
retrieving revision 1.4
diff -r1.4 tsrm_win32.c
98a99,106
> static HANDLE dupHandle(HANDLE fh, BOOL inherit) {
>   HANDLE copy, self = GetCurrentProcess();
>   if (!DuplicateHandle(self, fh, self, ©, 0, inherit, 
>DUPLICATE_SAME_ACCESS|DUPLICATE_CLOSE_SOURCE)) {
>   return NULL;
>   }
>   return copy;
> }
> 
129c137,138
< 
---
>   /* you cannot allow the php end of the pipe to be inheritable, as that will
>  cause handles to be leaked, and may cause a spawned process to get stuck! */
130a140
>   in = dupHandle(in, FALSE);
133a144
>   out = dupHandle(out, FALSE);
173a185,189
> 
>   /* pclose is supposed to wait for the process to finish 
>  This should probabaly be configurable to avoid lockups
>   */
>   WaitForSingleObject(process->prochnd, INFINITE);

-- 
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] isapi filter authentication

[Shane Caraveo]

Hello,
Is anyone out there successfuly using php scripts for authentication
under the ISAPI interface?  The reason I ask is that from looking at the
current code, you would be required to have an NT user for anything you
want to authenticate.  Once I patched the filter to map to the anonymous
user, I am able to make authentication work properly.  I'm not ready to
commit the patch until whoever has been working on this part of the code
can explain what is going on there (in case I'm missing something
obvious).  

Anyway, here is my patch.  As an explanation, the purpose in the
authentication filter is to map X number of usernames/passwords to a
single NT user, so that PHP can be used for authentication (against
ldap, mysql, whatever).  You have to tell IIS what NT user it should use
for authentication.  If you blank out the username/password in the
notification, IIS will use the anonymous NT user set up for that web
site.  

Shane Caraveo

Index: php4isapi.c
===
RCS file: /repository/php4/sapi/isapi/php4isapi.c,v
retrieving revision 1.70
diff -r1.70 php4isapi.c
631,632c631
<   char *auth_user = ((HTTP_FILTER_AUTHENT *)
pvNotification)->pszUser;
<   char *auth_password = ((HTTP_FILTER_AUTHENT *)
pvNotification)->pszPassword;
---
>   HTTP_FILTER_AUTHENT *auth = (HTTP_FILTER_AUTHENT *) 
>pvNotification;
634,635c633,635
<   if (auth_user && auth_user[0]) {
<   SG(request_info).auth_user = 
estrdup(auth_user);
---
>   if (auth->pszUser && auth->pszUser[0]) {
>   SG(request_info).auth_user = 
>estrdup(auth->pszUser);
>   memset(auth->pszUser, 0, auth->cbUserBuff);
637,638c637,639
<   if (auth_password && auth_password[0]) {
<   SG(request_info).auth_password = 
estrdup(auth_password);
---
>   if (auth->pszPassword && auth->pszPassword[0]) {
>   SG(request_info).auth_password = 
>estrdup(auth->pszPassword);
>   memset(auth->pszPassword, 0 , 
>auth->cbPasswordBuff);

-- 
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]

Re: [PHP-DEV] mail() and windows

[Shane Caraveo]

I recently submitted a patch to cvs that allows you to use an external
mailer, just as the unix builds use sendmail.  I tested using indigomail,
which has a compatible command line syntax to sendmail.  To use the external
mailer, you specify the sendmail_path option in the ini file (leave blank to
use the internal mailer).
Shane

- Original Message -
From: "colin mcdonald" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, July 18, 2001 1:33 PM
Subject: [PHP-DEV] mail() and windows


> hi there,
>
> I've been reading about (and experiencing) the problems with sending
> mail on windows.
>
> Question:  Are there any plans in the near future to clean/rewrite this
> code?  I keep seeing the comment that "mail() badly needs a rewrite on
> windows".
>
> Question(s):  If there are no plans in the near future, how can I help?
>   What needs to be rewritten (besides the obvious handling Bcc header
> and making the header case-insensitive)?  I've been experiencing
> problems when sending attachments that are slightly longer than 2kb.
> What would need to be rewritten to get this working.  Is it a lower
> level than the code in php (ie win sockets)?
>
> thanks and hope I can help!
>
> colin
>
>
> --
> 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 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 database report/search

[Shane Caraveo]

Is there anyway that we can generate a report, or at least search the bug
database, for all bugs related to an operating system?  I would like to
generate a list of open bugs for any windows platform.

Shane



-- 
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] PHP 4.0 Bug #10062: CGI version displays '#!/usr/local/bin/php' line

[shane . wright]

From: [EMAIL PROTECTED]
Operating system: RedHat 7
PHP version:  4.0.4pl1
PHP Bug Type: Unknown/Other Function
Bug description:  CGI version displays '#!/usr/local/bin/php' line

Standard configure/make on REdHat 7 (options are: 
--without-apache --with-mysql --with-gd)

Then CGI execution as normal - it reads php.ini fine and 
renders PHP fine - the only problem is the display of the 
first line of the file ('#!/usr/local/bin/php')

I've seen posts elsewhere about someone having a similar 
problem on FreeBSD with an older version that went away 
with a newer version (of PHP that is) so I'm assuming its 
a resurfacing issue.  Apologies if it's just me being lame 
;)

Regards

Shane



-- 
Edit Bug report at: http://bugs.php.net/?id=10062&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] PHP 4.0 Bug #10062 Updated: CGI version displays '#!/usr/local/bin/php' line

[shane . wright]

ID: 10062
User Update by: [EMAIL PROTECTED]
Status: Bogus
Bug Type: Unknown/Other Function
Description: CGI version displays '#!/usr/local/bin/php' line

I'm afraid it really is as a CGI - the reason being that 
my ISP won't install PHP modules and I need gd/t1lib 
support.  This problem is with testing the setup on the 
local server (I want the same setup both ends to avoid any 
extra complications).

I wasn't aware that it was the web server's responsibility 
to strip the #1/usr/local/bin/php line out - I am running 
apache 1.3.14 and I have a feeling there could be an issue 
with that - (although I haven't noticed it in the past 
with C++ CGIs)




Previous Comments:
---

[2001-03-29 12:38:03] [EMAIL PROTECTED]
There is no need for #!/usr/local/bin/php if you have your webserver set up to parse 
PHP files already (IE if you have set up apache as shown in install docs.) if your 
webserver is executing the files (actually set up as real cgi then please reopen this 
bug report but this shouldnt happen as the webserver should strip the 
#!/usr/local/bin/php line out.)

James

---

[2001-03-29 12:25:01] [EMAIL PROTECTED]
Standard configure/make on REdHat 7 (options are: 
--without-apache --with-mysql --with-gd)

Then CGI execution as normal - it reads php.ini fine and 
renders PHP fine - the only problem is the display of the 
first line of the file ('#!/usr/local/bin/php')

I've seen posts elsewhere about someone having a similar 
problem on FreeBSD with an older version that went away 
with a newer version (of PHP that is) so I'm assuming its 
a resurfacing issue.  Apologies if it's just me being lame 
;)

Regards

Shane


---


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


-- 
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] PHP 4.0 Bug #10062 Updated: CGI version displays '#!/usr/local/bin/php' line

[shane . wright]

ID: 10062
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: Unknown/Other Function
Description: CGI version displays '#!/usr/local/bin/php' line

They're running 1.3.12 - but that doesn't matter yet as I 
can't even get PHP to compile there (its Debian with 
glibc2.1, PHP 4.0.4pl1, same configure options as I said 
previously, configure runs fine, but make dies half way 
through - can't work out why though - but thats for 
another day...)

Ah.  but if it is an issue with Apache then I'm screwed 
anyway :((




Previous Comments:
---

[2001-03-29 13:05:26] [EMAIL PROTECTED]
Hmm I might be wrong there.. What webserver is your ISP running?

James

---

[2001-03-29 12:51:59] [EMAIL PROTECTED]
I'm afraid it really is as a CGI - the reason being that 
my ISP won't install PHP modules and I need gd/t1lib 
support.  This problem is with testing the setup on the 
local server (I want the same setup both ends to avoid any 
extra complications).

I wasn't aware that it was the web server's responsibility 
to strip the #1/usr/local/bin/php line out - I am running 
apache 1.3.14 and I have a feeling there could be an issue 
with that - (although I haven't noticed it in the past 
with C++ CGIs)




---

[2001-03-29 12:38:03] [EMAIL PROTECTED]
There is no need for #!/usr/local/bin/php if you have your webserver set up to parse 
PHP files already (IE if you have set up apache as shown in install docs.) if your 
webserver is executing the files (actually set up as real cgi then please reopen this 
bug report but this shouldnt happen as the webserver should strip the 
#!/usr/local/bin/php line out.)

James

---

[2001-03-29 12:25:01] [EMAIL PROTECTED]
Standard configure/make on REdHat 7 (options are: 
--without-apache --with-mysql --with-gd)

Then CGI execution as normal - it reads php.ini fine and 
renders PHP fine - the only problem is the display of the 
first line of the file ('#!/usr/local/bin/php')

I've seen posts elsewhere about someone having a similar 
problem on FreeBSD with an older version that went away 
with a newer version (of PHP that is) so I'm assuming its 
a resurfacing issue.  Apologies if it's just me being lame 
;)

Regards

Shane


---


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


-- 
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] PHP 4.0 Bug #10062 Updated: CGI version displays '#!/usr/local/bin/php' line

[shane . wright]

ID: 10062
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: Unknown/Other Function
Description: CGI version displays '#!/usr/local/bin/php' line

I'm glad it's not an Apache issue, makes life easier :))

yup, file is called test.cgi, chmod 755, ExecCGI enabled 
in Apache.

A hack would be fine...   ..so long as it doesn't require 
root access or changes to Apache's config (which I 
wouldn't be able to do on the remote machine)

Are you thinking of a patch to PHP to forcefully stop it 
outputting anything before the first newline?  That would 
be ok - but my CGI's need to use a lot of HTTP headers 
(including HTTP authentication - but that can change if 
necessary)  I was thinking of making them nph-...

Regards
Shane


Previous Comments:
---

[2001-03-29 13:49:02] [EMAIL PROTECTED]
This isnt an Issue with apache. What are you calling your php file?? .cgi yes? there 
are some hacks around this but it seems more likley a config problem rather than a bug 
in PHP.. anu ideas people??

---

[2001-03-29 13:41:54] [EMAIL PROTECTED]
They're running 1.3.12 - but that doesn't matter yet as I 
can't even get PHP to compile there (its Debian with 
glibc2.1, PHP 4.0.4pl1, same configure options as I said 
previously, configure runs fine, but make dies half way 
through - can't work out why though - but thats for 
another day...)

Ah.  but if it is an issue with Apache then I'm screwed 
anyway :((




---

[2001-03-29 13:05:26] [EMAIL PROTECTED]
Hmm I might be wrong there.. What webserver is your ISP running?

James

---

[2001-03-29 12:51:59] [EMAIL PROTECTED]
I'm afraid it really is as a CGI - the reason being that 
my ISP won't install PHP modules and I need gd/t1lib 
support.  This problem is with testing the setup on the 
local server (I want the same setup both ends to avoid any 
extra complications).

I wasn't aware that it was the web server's responsibility 
to strip the #1/usr/local/bin/php line out - I am running 
apache 1.3.14 and I have a feeling there could be an issue 
with that - (although I haven't noticed it in the past 
with C++ CGIs)




---

[2001-03-29 12:38:03] [EMAIL PROTECTED]
There is no need for #!/usr/local/bin/php if you have your webserver set up to parse 
PHP files already (IE if you have set up apache as shown in install docs.) if your 
webserver is executing the files (actually set up as real cgi then please reopen this 
bug report but this shouldnt happen as the webserver should strip the 
#!/usr/local/bin/php line out.)

James

---

The remainder of the comments for this report are too long.  To view the rest of the 
comments, please view the bug report online.

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


-- 
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]

Re: [PHP-DEV] PHP 4.0 Bug #10212: php -l (lint option) still not working in 4.0.6-dev

[Shane Caraveo]

the default php.ini files turn off or on some things that linting needs,
try:

php -d display_errors=1 -d display_startup_errors=1 -d output_buffering=0 -l
blah.html

- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, April 06, 2001 9:38 AM
Subject: [PHP-DEV] PHP 4.0 Bug #10212: php -l (lint option) still not
working in 4.0.6-dev


> From: [EMAIL PROTECTED]
> Operating system: RedHat Linux 6.2
> PHP version:  4.0 Latest CVS (06/04/2001)
> PHP Bug Type: Feature/Change Request
> Bug description:  php -l (lint option) still not working in 4.0.6-dev
>
> I have obtained the latest CVS version of PHP (4.0.6-dev).  I execute the
following:
>
> php -l blah.html
>
> blah.html looks like this:
>
>  echo "adfsdf"asdfds" ;
> ?>
>
> This USED to cause PHP to core dump.  Now it returns but does not output
and error message.  Actually, it does not seem to do anything.  Am wondering
if this option (-l) is supported or in for future use or if this is being
worked on.
>
> Thanks.
>
>
> --
> Edit Bug report at: http://bugs.php.net/?id=10212&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 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 #10264: strange associative array behaviour

[shane . wright]

From: [EMAIL PROTECTED]
Operating system: RedHat 7
PHP version:  4.0.4pl1
PHP Bug Type: Arrays related
Bug description:  strange associative array behaviour

Not sure if this is a bug or not, but I can't find any 
reference to it in the documentation/user comments/FAQs

Basically, if you build an associative(ish) array like 
this:

$period = -24;
for ($i=$period; $i<=0; $i++) {
$data[$i] = $myvalues[$anotherindex];
};

It works ok, the array contains (in order) elements with 
the inidices -24 to 0.

But, if $period is decreased so that over 25 elements are 
introduced, the order goes off...

basically elements with indices -24 to 0 are fine, but all 
the other ones come, in order, _after_ index 0.

Any ideas?

Shane



-- 
Edit Bug report at: http://bugs.php.net/?id=10264&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]

Re: [PHP-DEV] Server-Wide Persistent objects in PHP?

[Shane Wright]

Hi Thread!

On Monday 26 Nov 2001 5:03 pm, James Moore wrote:
> > Yea, that's the problem. In my application, just loading the class files
> > on each page adds quite a bit of overhead. (1000's of lines of code).
> Only load what you need then :) Or rewrite in C.

I'm having similar issues - and coming up with the same two solutions, 
however

- only load what you need.

Yup, conditional includes rock!  But, keeping track of which bits each page 
needs is a pain; and when things are integrated, most things tend to need at 
least something from most other things - so without a fine-grained approach 
there is little gain, and with a fine-grained approach there's lots of 
overhead...

- rewrite in C.

My other solution too - write language extensions in C and compile them into 
PHP.  Not an ideal solution IMO (why are we using PHP anyway).  This 
involves lots of effort and another language on top of the 4 already used in 
most projects this size (PHP, SQL, HTML, Javascript...).

Some sort of persistence is definately required - I like that we can extend 
the language but I dont feel it should be necessary purely for performance...

Just my 2c...

--
Shane



> > I've taken a look through the PHP/Zend source and it looks to me like it
> > would be possible to create a module built around a modified version of
> > php_execute_script() that:
> >
> >1. loads, compiles and executes a script.
> >
> >2. saves the state of the global tables Zend uses to
> >   manage class definitions, objects, functions, variables, etc
> >   (since there are so many globals used in Zend it doesn't look
> >   like you can instantiate a second instance of the PHP interpreter
> >   inside a single process, correct?)
> >
> >3. exports some function calls to PHP that would allow object
> > instances (and their corresponding class definitions) to be imported into
> > the local name space.
> >
> > Ideally I'd set the module up so that all these classes and instantiation
> > happen in the php.ini file at server start time. Now wouldn't that be
> > cool?
> >
> > The question I have is what other hooks are there inside PHP that would
> > prevent this from working? Can I copy a pre-built symbol table (and class
> > definition table, etc) that I saved from a previous run of the PHP
> > interpreter (on a previous page) into a new one without having it crash?
>
> This is a very very complex process as there are a lot of dependencies
> through out the symbol table especially when dealing with classes. APC
> attempts this but doesnt do it brilliantly when classes are inherited etc.
> The Zend Cache is the only fully reliable type of system you are talking
> about I suggest you look at that.
>
> - James

-- 
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]

Re: [PHP-DEV] Server-Wide Persistent objects in PHP?

[Shane Wright]

Hi George,

I'd be interested in this - no budget for the Zend one, but I'd like the APC 
one - do you or anyone have any practical experience of this in production 
environments (>1.5m hits/week)?  (or any [independent] URLs or reviews)

Thanks,

--
Shane

On Monday 26 Nov 2001 5:22 pm, George Schlossnagle wrote:
> If you use a caching extension like APC (http://apc.communityconnect.com)
> or Zend Cache/Accelerator you get 1 and 2 below.  APC at least implements
> basically what your looking for, I thnk.
>
>
> - Original Message -
> From: "Yermo M. Lamers" <[EMAIL PROTECTED]>
> To: "Markus Fischer" <[EMAIL PROTECTED]>
> Cc: "Andrey Hristov" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> Sent: Monday, November 26, 2001 12:30 PM
> Subject: Re: [PHP-DEV] Server-Wide Persistent objects in PHP?
>
> > Markus,
> >
> > Yea, that's the problem. In my application, just loading the class files
> > on each page adds quite a bit of overhead. (1000's of lines of code).
> >
> > I've taken a look through the PHP/Zend source and it looks to me like it
> > would be possible to create a module built around a modified version of
> > php_execute_script() that:
> >
> >1. loads, compiles and executes a script.
> >
> >2. saves the state of the global tables Zend uses to
> >   manage class definitions, objects, functions, variables, etc
> >   (since there are so many globals used in Zend it doesn't look
> >   like you can instantiate a second instance of the PHP interpreter
> >   inside a single process, correct?)
> >
> >3. exports some function calls to PHP that would allow object
> > instances (and their corresponding class definitions) to be imported into
> > the local name space.
> >
> > Ideally I'd set the module up so that all these classes and instantiation
> > happen in the php.ini file at server start time. Now wouldn't that be
> > cool?
> >
> > The question I have is what other hooks are there inside PHP that would
> > prevent this from working? Can I copy a pre-built symbol table (and class
> > definition table, etc) that I saved from a previous run of the PHP
> > interpreter (on a previous page) into a new one without having it crash?
> >
> > thanks,
> >
> > -- Yermo
> >
> > On Mon, 26 Nov 2001, Markus Fischer wrote:
> > > On Mon, Nov 26, 2001 at 12:18:23PM -0500, Yermo M. Lamers wrote :
> > > > Question for you, when you serialize to a file do the class
>
> definitions
>
> > > > get serialized along with it or do you have to pre-load your classes
> > > > before you can unserialize? (that seems to be the way it works but I
>
> may
>
> > > > be mistaken).
> > >
> > > Class definition is not safed.
> > >
> > > - Markus
> >
> > -
> > DTLink Software   [EMAIL PROTECTED]
> > Software Development and Consulting
> > -
> >
> >
> > --
> > 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 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] writing PHP extensions

[Shane Wright]

Hi

I've looked all over the place (php.net, zend.com, phpbuilder.com, archive 
for the lists, everywhere..) and I cant find anywhere a nice intro to 
building PHP extensions.

I just need something to cover the basics of writing an extension, and things 
like exposing functions to PHP scripts, populating the environment with 
variables/constants and output (not buffered).

Is there such a thing?

Any help appreciated,

Thanks

--
Shane

-- 
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]