Re: [PHP-DEV] Update: Quoting behaviour exposed
At 19:47 29/12/2002, Sascha Schumann wrote: If that language had interested me, I would have made my Hebraicum in addition to the Latinum. [snip off-topic] ^^^ You're kidding, right? Thankfully, your interest in young languages does not concern me, nor does your show-off behavior, so I couldn't care less about your choice of words. The rest of your stuff has been answered off list, to bring this stupid thread to a halt. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Win32 Build Quirks
At 20:12 29/12/2002, Michael Sisolak wrote: Zeev Suraski wrote: It's zlib. I'm not sure why people relied on users having zlib installed as a part of their standard libraries under Windows, but it's not a reasonable assumption... checkout zlib, build it (under both Release and Debug), delete *.lib and *.dll from your PHP output directory, and relink. I configured the zlib project to work properly with PHP. Zeev, The current win32build tools has a zlibstat.lib in the lib directory. So it's broken. But generally, I don't want any code that's required to build PHP under Windows not to be available in source, and from php.net. If I copy that to also be called zlib.lib then the release 4.3.0 build correctly. Should we be linking to zlibstat.lib instead of zlib.lib or updating win32build to include whatever zlib.lib it should link to? I would imagine that most Win32 builds will now fail (unless they happen to have a zlib.lib in their library path). I don't have a preference. We can change zlib.dsp to build zlibstat.lib instead of zlib.lib and link with zlibstat.lib, if that would solve the problem... Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Win32 Build Quirks
At 19:29 29/12/2002, Sebastian Bergmann wrote: Zeev Suraski wrote: Probably due to different .dsp's (I assume you have two different checkouts of the PHP source tree? Any chance one of them is modified) No, one checkout. For a Zend Engine 2 build I rename Zend to Zend1 and ZendEngine2 to Zend. (I know, this is dirty :-) No idea then, I didn't change anything in these projects... Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CVS Account Request: tularis
I would like to help with translating the php manual to Dutch. I can see it's far from being finished, and I think I could help a lot... -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CVS Account Request: tularis
On 30 Dec 2002, Maciek Sokolewicz wrote: I would like to help with translating the php manual to Dutch. I can see it's far from being finished, and I think I could help a lot... Great! Hoe meer zielen hoe meer vreugd :) Tijdens het wachten op je account kun je alvast de howto lezen: php.net/dochowto Greetings, Derick -- - Derick Rethans http://derickrethans.nl/ PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] option to start in PHP mode
On Sat, 28 Dec 2002, Andi Gutmans wrote: Why don't we have the ? problem? You can also use ? in eval()'s. Anyway, Rasmus mentioned that a switch already exists although I don't think it's such a great idea due to the previously mentioned reasons. I think all PHP code should be consistent. Well, -r switch requires the PHP code as an argument. It doesn't read a file. -Andrei http://www.gravitonic.com/ The human brain is a wonderful thing. It starts working the moment you are born, and never stops until you stand up to speak in public. -- Sir George Jessel -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CVS Account Request: thx1140
translating the documentation from English to Polish -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH]apache_register_shutdown_function final version
As a reminder, this replaces the register_shutdown_function functionality
removed in 4.1.x as described at http://bugs.php.net/15209. I've made my
final adjustments to the patch. Please review and commit both to HEAD and
PHP_4_3. I received no response from the SAPI guru's, so I went ahead and
added the sapi_close function to all SAPI modules, initializing it to NULL.
It's not implemented for anything but apache 1.3. Implementing for Apache2
is not a big deal, just call ap_lingering_close from within sapi_close.
With the addition of sapi_close, it should be possible to add the
functionality of apache_register_shutdown_function to every platform
implementing the sapi_close method.
Also, those on non-Apache systems, please test to make sure that this does
not break your builds.
Thanks,
Joseph
[EMAIL PROTECTED]
?php
function shutdown()
{
sleep(3);
print(Shutdown function.\n);
}
function offline()
{
$i = 0;
$out = fopen('/tmp/shutdown_test.out',a+);
for($i = 0; $i 6; $i++)
{
sleep(3);
fputs($out, sleeping\n);
}
fclose($out);
}
apache_register_shutdown_function(offline);
register_shutdown_function(shutdown);
echo This is the end.br\n;
?
? ext/mysql/.libs
Index: ext/standard/basic_functions.c
===
RCS file: /repository/php4/ext/standard/basic_functions.c,v
retrieving revision 1.543.2.4
diff -u -r1.543.2.4 basic_functions.c
--- ext/standard/basic_functions.c 20 Dec 2002 16:37:44 - 1.543.2.4
+++ ext/standard/basic_functions.c 30 Dec 2002 16:56:02 -
@@ -107,11 +107,6 @@
{3, BYREF_FORCE, BYREF_FORCE, BYREF_FORCE};
-typedef struct _php_shutdown_function_entry {
- zval **arguments;
- int arg_count;
-} php_shutdown_function_entry;
-
typedef struct _user_tick_function_entry {
zval **arguments;
int arg_count;
@@ -119,7 +114,6 @@
} user_tick_function_entry;
/* some prototypes for local functions */
-static void user_shutdown_function_dtor(php_shutdown_function_entry
*shutdown_function_entry);
static void user_tick_function_dtor(user_tick_function_entry *tick_function_entry);
/* Demo code. Enable only if you need this. */
@@ -1121,6 +1115,7 @@
}
#endif
BG(user_shutdown_function_names) = NULL;
+ BG(user_apache_shutdown_function_names) = NULL;
#if HAVE_CRYPT
PHP_RINIT(crypt) (INIT_FUNC_ARGS_PASSTHRU);
@@ -1986,7 +1981,7 @@
/* }}} */
-void user_shutdown_function_dtor(php_shutdown_function_entry *shutdown_function_entry)
+PHPAPI void user_shutdown_function_dtor(php_shutdown_function_entry
+*shutdown_function_entry)
{
int i;
@@ -2006,7 +2001,7 @@
efree(tick_function_entry-arguments);
}
-static int user_shutdown_function_call(php_shutdown_function_entry
*shutdown_function_entry TSRMLS_DC)
+PHPAPI int user_shutdown_function_call(php_shutdown_function_entry
+*shutdown_function_entry TSRMLS_DC)
{
zval retval;
@@ -2128,7 +2123,6 @@
zend_hash_next_index_insert(BG(user_shutdown_function_names),
shutdown_function_entry, sizeof(php_shutdown_function_entry), NULL);
}
/* }}} */
-
ZEND_API void php_get_highlight_struct(zend_syntax_highlighter_ini
*syntax_highlighter_ini)
{
Index: ext/standard/basic_functions.h
===
RCS file: /repository/php4/ext/standard/basic_functions.h,v
retrieving revision 1.109
diff -u -r1.109 basic_functions.h
--- ext/standard/basic_functions.h 5 Nov 2002 06:05:48 - 1.109
+++ ext/standard/basic_functions.h 30 Dec 2002 16:56:02 -
@@ -74,6 +74,14 @@
PHP_FUNCTION(highlight_string);
ZEND_API void php_get_highlight_struct(zend_syntax_highlighter_ini
*syntax_highlighter_ini);
+typedef struct _php_shutdown_function_entry {
+ zval **arguments;
+ int arg_count;
+} php_shutdown_function_entry;
+
+PHPAPI void user_shutdown_function_dtor(php_shutdown_function_entry
+*shutdown_function_entry);
+PHPAPI int user_shutdown_function_call(php_shutdown_function_entry
+*shutdown_function_entry TSRMLS_DC);
+
PHP_FUNCTION(ini_get);
PHP_FUNCTION(ini_get_all);
PHP_FUNCTION(ini_set);
@@ -130,6 +138,7 @@
typedef struct {
HashTable *user_shutdown_function_names;
+ HashTable *user_apache_shutdown_function_names;
HashTable putenv_ht;
zval *strtok_zval;
char *strtok_string;
Index: main/SAPI.c
===
RCS file: /repository/php4/main/SAPI.c,v
retrieving revision 1.155.2.2
diff -u -r1.155.2.2 SAPI.c
--- main/SAPI.c 5 Dec 2002 22:15:00 - 1.155.2.2
+++ main/SAPI.c 30 Dec 2002 16:56:04 -
@@ -348,6 +348,15 @@
SG(sapi_headers).http_status_line = NULL;
}
}
+
+/* Close the client connection, but do not terminate execution */
+SAPI_API void sapi_close(TSRMLS_D)
+{
+
Re: [PHP-DEV] [PATCH]apache_register_shutdown_function final version
So, is this going to get added? I have seen very little response to Joseph from the list. I would very much like to see this as register_shutdown_function is/was crucial to us in it previous form. Brian Moon dealnews.com - Original Message - From: Joseph Tate [EMAIL PROTECTED] To: Php-Dev List [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: Jason Priebe [EMAIL PROTECTED] Sent: Monday, December 30, 2002 11:22 AM Subject: [PHP-DEV] [PATCH]apache_register_shutdown_function final version | As a reminder, this replaces the register_shutdown_function functionality | removed in 4.1.x as described at http://bugs.php.net/15209. I've made my | final adjustments to the patch. Please review and commit both to HEAD and | PHP_4_3. I received no response from the SAPI guru's, so I went ahead and | added the sapi_close function to all SAPI modules, initializing it to NULL. | It's not implemented for anything but apache 1.3. Implementing for Apache2 | is not a big deal, just call ap_lingering_close from within sapi_close. | | With the addition of sapi_close, it should be possible to add the | functionality of apache_register_shutdown_function to every platform | implementing the sapi_close method. | | Also, those on non-Apache systems, please test to make sure that this does | not break your builds. | | Thanks, | Joseph | [EMAIL PROTECTED] | | | -- | 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] Re: [PATCH]apache_register_shutdown_function final version
That's a bit of an odd way to implement it - are you sure closing the link explicitly at that point won't interfere with anything? In 4.1 (or whatever the last version it worked like that was), it was taking advantage of the fact PHP's resource pool was being destroyed after the link was already closed. It sounds a bit risky to me to close the link explicitly at this point, even though I'm not currently aware of any immediate problem this may cause (maybe it would ruin keep-alive?) Zeev At 19:22 30/12/2002, Joseph Tate wrote: As a reminder, this replaces the register_shutdown_function functionality removed in 4.1.x as described at http://bugs.php.net/15209. I've made my final adjustments to the patch. Please review and commit both to HEAD and PHP_4_3. I received no response from the SAPI guru's, so I went ahead and added the sapi_close function to all SAPI modules, initializing it to NULL. It's not implemented for anything but apache 1.3. Implementing for Apache2 is not a big deal, just call ap_lingering_close from within sapi_close. With the addition of sapi_close, it should be possible to add the functionality of apache_register_shutdown_function to every platform implementing the sapi_close method. Also, those on non-Apache systems, please test to make sure that this does not break your builds. Thanks, Joseph [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Update: Quoting behaviour exposed
Zeev, you start to bore me. If you didn't notice it yet, yesterday's email already constituted my EOT contribution. So, now, explicitly for you, EOT. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RE: [PATCH]apache_register_shutdown_function final version
There probably is a better way to do it. I just haven't been able to figure it out. Most Apache modules wait until the logging stage to execute offline code, but it doesn't seem that at that stage PHP code is still in memory. Thus there doesn't seem to be a satisfactory way to do this. As for explicitly closing the connection, I call flush before I do that, and everything that PHP cares about has been done, except for garbage_collecting and unloading itself. Apache goes ahead and cleans up everything else after the logging stage. I haven't tried explicitly with a Connection-Type: Keep-Alive, but I don't think it will cause browsers to crash. I've tested with IE 6x and Mozilla 1.2.1. My implementation was based on code existing in the apache sources (just not externally available in Apache 1.3.x) lingering_close and much discussion on the Apache-Modules mailing list. If you can point me to a place in PHP land where the Apache process has closed the connection, and the script is still in memory, I'll be happy to make it neater, but in my search (I spent a day or so looking for such a place) I couldn't find anything. Another interesting thing to note is that the Patch that worked with 4.1.x to restore the functionality doesn't work with 4.2 or 4.3, so something has changed so that all resource pool cleanup is happening before the connection is closed rather than after, causing PHP to appear slower than it needs to. Joseph -Original Message- From: Zeev Suraski [mailto:[EMAIL PROTECTED]] Sent: Monday, December 30, 2002 12:55 PM That's a bit of an odd way to implement it - are you sure closing the link explicitly at that point won't interfere with anything? In 4.1 (or whatever the last version it worked like that was), it was taking advantage of the fact PHP's resource pool was being destroyed after the link was already closed. It sounds a bit risky to me to close the link explicitly at this point, even though I'm not currently aware of any immediate problem this may cause (maybe it would ruin keep-alive?) Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Update: Quoting behaviour exposed
At 20:52 30/12/2002, Sascha Schumann wrote: Zeev, you start to bore me. Thank God, I was hoping you were already being bored as much as I am for the past 4 years of pointless discussions with you, but better late than never! Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RE: [PATCH]apache_register_shutdown_function final version
Try looking at php_apache_request_shutdown() in mod_php4.c. It's our pool destructor. Zeev At 20:55 30/12/2002, Joseph Tate wrote: There probably is a better way to do it. I just haven't been able to figure it out. Most Apache modules wait until the logging stage to execute offline code, but it doesn't seem that at that stage PHP code is still in memory. Thus there doesn't seem to be a satisfactory way to do this. As for explicitly closing the connection, I call flush before I do that, and everything that PHP cares about has been done, except for garbage_collecting and unloading itself. Apache goes ahead and cleans up everything else after the logging stage. I haven't tried explicitly with a Connection-Type: Keep-Alive, but I don't think it will cause browsers to crash. I've tested with IE 6x and Mozilla 1.2.1. My implementation was based on code existing in the apache sources (just not externally available in Apache 1.3.x) lingering_close and much discussion on the Apache-Modules mailing list. If you can point me to a place in PHP land where the Apache process has closed the connection, and the script is still in memory, I'll be happy to make it neater, but in my search (I spent a day or so looking for such a place) I couldn't find anything. Another interesting thing to note is that the Patch that worked with 4.1.x to restore the functionality doesn't work with 4.2 or 4.3, so something has changed so that all resource pool cleanup is happening before the connection is closed rather than after, causing PHP to appear slower than it needs to. Joseph -Original Message- From: Zeev Suraski [mailto:[EMAIL PROTECTED]] Sent: Monday, December 30, 2002 12:55 PM That's a bit of an odd way to implement it - are you sure closing the link explicitly at that point won't interfere with anything? In 4.1 (or whatever the last version it worked like that was), it was taking advantage of the fact PHP's resource pool was being destroyed after the link was already closed. It sounds a bit risky to me to close the link explicitly at this point, even though I'm not currently aware of any immediate problem this may cause (maybe it would ruin keep-alive?) Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] Merging into PHP_4_3
On December 30, 2002 02:04 pm, Andrei Zmievski wrote: I concur. Please remember to update NEWS on the branch. Could you please add a section for the branch (4.3.1?) in the news file. Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] Merging into PHP_4_3
Could you please add a section for the branch (4.3.1?) in the news file. Isn't it already there? Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] Merging into PHP_4_3
On December 30, 2002 02:17 pm, Edin Kadribasic wrote: Could you please add a section for the branch (4.3.1?) in the news file. Isn't it already there? There is one for 4.4 (possibly to be renamed 5), but I don't see a 4.3.X section. Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] Merging into PHP_4_3
There is one for 4.4 (possibly to be renamed 5), but I don't see a 4.3.X section. Oh, that is in HEAD. We usually add all the branch changes into the brach version of the NEWS and merge them into HEAD once a new release has been made from the branch. Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] A cli/cgi-related question
Hi! I went through the discussion about naming cgi and cli binary some weeks ago. But there is still a question in my mind that has not been answered yet (at least, as far as i remember). As an End-User, which installation instruction should i use? As far as i understand the cli binary will get the default binary placed in /usr/bin/php. But is there a way to install both, cgi and cli, at once? Or do i have to compile it twice everytime, with two different prefix directories? In my opinion it would be nice to have parameters like --enable-cli=php --enable-cgi=phpcgi in the configure script. In this way both versions can be build at once with two different names. bye, Roland -- Please reply to: [EMAIL PROTECTED] I spent a minute looking at my own code by accident. I was thinking What the hell is this guy doing? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RE: [PATCH]apache_register_shutdown_function final version
That's no good. If I remove the sapi_close stuff, and try to execute the shutdown functions in php_apache_request_shutdown() all I get is stuff in the error log listing the leaked memory. The requested function does not get executed. Joseph -Original Message- From: Zeev Suraski [mailto:[EMAIL PROTECTED]] Sent: Monday, December 30, 2002 1:57 PM Subject: RE: [PATCH]apache_register_shutdown_function final version Try looking at php_apache_request_shutdown() in mod_php4.c. It's our pool destructor. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] A cli/cgi-related question
Hi! Sorry for that mail... i missed the paragraph in the manual about the make install-cli stuff... In my opinion it would be nice to have parameters like --enable-cli=php --enable-cgi=phpcgi in the configure script. In this way both versions can be build at once with two different names. But nevertheless i would like something like that :-) bye, Roland -- WIEDER DA - Roland im ICQ! UIN 18715473 - NEU NEU NEU Please reply to: [EMAIL PROTECTED] I spent a minute looking at my own code by accident. I was thinking What the hell is this guy doing? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] Merging into PHP_4_3
On Mon, 30 Dec 2002, Edin Kadribasic wrote: It would be nice that bug fixes that are being merged into PHP_4_3 branch are documented in its NEWS file. In that way we can realease a new version rather quickly. I concur. Please remember to update NEWS on the branch. -Andrei http://www.gravitonic.com/ Perl - the only language that looks the same before and after RSA encryption. -Keith Bostic -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] RE: [PATCH]apache_register_shutdown_function final version
Upon further inspection, it is clear that shutdown_memory_manager is called before php_apache_request_shutdown. This, it seems, hails back from the change that caused cleanup to happen before the connection closed, which may or may not be related to the memory management changes. This causes the Zend engine to deallocate all my nice pointers. php_apache_request_shutdown is run as an apache cleanup routine. This is good design, but in main.c in php_request_shutdown, the PHP code as it exists when the process is running is destroyed. This long before the connection is shut down, and in turn long before php_apache_request_shutdown is run. Thus any attempt to move php_call_shutdown_functions any lower in the execution order of php_request_shutdown results in a segmentation fault. This was what I did originally to test for an execution location where the connection was closed but PHP was still intact. It seems, as I suspected, that there is no place where the connection is closed and PHP code still exists. Back to the solution proposed, I've put a test around the sapi_close call which means that it will only be called if there are registered apache shutdown functions. Will this placate you? It will thus only break keep-alive if there are offline functions to be run. If this is still unacceptable, the php_request_shutdown may need to be redesigned, and thus, I fear, all of SAPI. Joseph -Original Message- From: Joseph Tate [mailto:[EMAIL PROTECTED]] Sent: Monday, December 30, 2002 2:55 PM Subject: [PHP-DEV] RE: [PATCH]apache_register_shutdown_function final version That's no good. If I remove the sapi_close stuff, and try to execute the shutdown functions in php_apache_request_shutdown() all I get is stuff in the error log listing the leaked memory. The requested function does not get executed. Joseph -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP Look Back 2002
Hello! We are almost at the end of 2002, and it seemed appropriate to look back on the development issues of the past year. So starts the first PHP Look Back! You can find it @ http://www.derickrethans.nl/20021230.php, and if you have any comments,feel free to post them with the link at the bottom of the page. Have fun reading! Derick -- - Derick Rethans http://derickrethans.nl/ JDI Media Solutions http://www.jdimedia.nl/ PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP Look Back 2002
This is impressive work! I have to say what I've seen of the PHP development team during 2002 is very encouraging for the future and I wish you all you guys a great year for 2003. Thanks, On Mon, 2002-12-30 at 16:23, Derick Rethans wrote: Hello! We are almost at the end of 2002, and it seemed appropriate to look back on the development issues of the past year. So starts the first PHP Look Back! You can find it @ http://www.derickrethans.nl/20021230.php, and if you have any comments,feel free to post them with the link at the bottom of the page. Have fun reading! Derick -- - Derick Rethans http://derickrethans.nl/ JDI Media Solutions http://www.jdimedia.nl/ PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ - -- Xavier Spriet [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP Look Back 2002
A friend of mine had an uncle who taught dancing to middle-aged couples. One day he visited some lessons and noticed that all the couples were fussing, stepping on each other's feet and arguing. When he asked, what gives? his uncle told him, if you're not fighting, you're not dancing. (It may help to imagine this said with a yiddish accent). Damn me if this doesn't describe the PHP community. Thanks for reminding us to keep our sense of humor, Derick. ;) Leon -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] manage PHP's session
Hi gurus, Does anyone has a sample script to manage PHP's session , please give me I am new to PHP so it seems that everything is difficult. I am using PHP4.0 on window2000 (IIS5.0) If you have , please give me one Thanks in advance Ha Duy Thien -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP Look Back 2002
On Mon, Dec 30, 2002 at 10:23:54PM +0100, Derick Rethans wrote : We are almost at the end of 2002, and it seemed appropriate to look back on the development issues of the past year. So starts the first PHP Look Back! You can find it @ http://www.derickrethans.nl/20021230.php, and if you have any comments,feel free to post them with the link at the bottom of the page. Hach Derick .. your readings .. so sharmful and enlightening at once :) very impressive (and elite humorous) abstract, - Markus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Bug # 21261 -- PHP_SELF not set correctly with sapi/CGI
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 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] PHP Look Back 2002
Derick Rethans wrote: We are almost at the end of 2002, and it seemed appropriate to look back on the development issues of the past year. So starts the first PHP Look Back! You can find it @ http://www.derickrethans.nl/20021230.php, and if you have any comments,feel free to post them with the link at the bottom of the page. Awesome and classy. Much like your contribution to PHP. Thanks, and all the best to you in '03. Regards Mike Robinson -- 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
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
