Re: [PHP-DEV] CLI max_execution_time
On Sun, 2002-03-24 at 15:40, Marcus Börger wrote: At 15:32 24.03.2002, Markus Fischer wrote: Would you EVER expect a bash/perl/awk/sed/python/nameit script by default only run a certain amount of time, namely it's maximum execution time ? Certainly not. No i don't but is a feature we have so why not disable it by default ini entry instead of implementing a work around? I often run without php.ini. Sapi/cl's _hardcoded_ default behaviour should be sane. - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CLI max_execution_time
On Mon, Mar 25, 2002 at 09:44:00PM +0100, Edin Kadribasic wrote: Are you sure you were testing it with CLI? Header hiding (-q) has been in there since the first check-in back in Jan 6. This is good. I have tried to compile a list of things I would like to see in php-cli, and haven't checked yet which of these are already there. I came up with - automatic -q mode enabled - php honoring -- as end of options as required by getopt so that #! /usr/bin/php ... -- can be written and works as expected, even if somebody names his script -i or something. - no html in error messages or warnings - php reading /etc/php-cli.ini, $HOME/.php.ini unless $PHPRC suggests something different. ./.php.ini and ./php.ini not read, unless . is put in $PHPRC path. - safe_mode'ish features off or even disabled, since they make no sense in cli. - gpc variables not registered, argc/argv honored - error logging to stderr, not to syslog or other target. - sensible php.ini default installed with no execution time limit and memory limit. This list is not complete, it is just what comes to mind immediately when thinking of cli-ifying php. Also, I wonder how starting PHP in HTML-mode relates to CLI usage, but I believe this would break to many things. - #! /usr/bin/php -- Hello world - Hello world program in php-cli, starting in HTML mode. - #! /usr/bin/php -- ?php echo Hello world; - The same, as of now, using actual PHP facilities - #! /usr/bin/php -- echo Hello world; - What someone would expect from a scripting language. Kristian -- Kristian Köhntopp, NetUSE AG, Dr.-Hell-Straße, D-24107 Kiel Tel: +49 431 386 435 00, Fax: +49 431 386 435 99 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CLI max_execution_time
This list is not complete, it is just what comes to mind immediately when thinking of cli-ifying php. Also, I wonder how starting PHP in HTML-mode relates to CLI usage, but I believe this would break to many things. This comes up every now and then and I believe it would be a mistake to change the startup mode. I should be able to take any .php file and run it through php-cli normally and vice-versa. Having, in essence, two different file formats is not a step forward in any way. -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CLI max_execution_time
On Tue, Mar 26, 2002 at 01:31:56AM -0800, Rasmus Lerdorf wrote: This comes up every now and then and I believe it would be a mistake to change the startup mode. I should be able to take any .php file and run it through php-cli normally and vice-versa. Having, in essence, two different file formats is not a step forward in any way. Complete agree here. This is the sensible thing to do, albeit somehow aethetically disturbing. :-) Kristian -- Kristian Köhntopp, NetUSE AG, Dr.-Hell-Straße, D-24107 Kiel Tel: +49 431 386 435 00, Fax: +49 431 386 435 99 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CLI max_execution_time
On Tue, Mar 26, 2002 at 01:31:56AM -0800, Rasmus Lerdorf wrote: This comes up every now and then and I believe it would be a mistake to change the startup mode. I should be able to take any .php file and run it through php-cli normally and vice-versa. Having, in essence, two different file formats is not a step forward in any way. Complete agree here. This is the sensible thing to do, albeit somehow aethetically disturbing. :-) Depends how you look at it. To me, this is a PHP script: Hello World Unlike any other scripting language, PHP gets out of the way of the most common operation, that of outputting stuff. It also means that PHP has the absolute shortest and simplest Hello World you can have. If you think of the entire file as the script, there is nothing inconsistent or even aethetically disturbing about it as far as I am concerned. -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CLI max_execution_time
** Reply to note from Rasmus Lerdorf [EMAIL PROTECTED] Tue, 26 Mar 2002 01:41:59 -0800 (PST) Complete agree here. This is the sensible thing to do, albeit somehow aethetically disturbing. :-) Depends how you look at it. To me, this is a PHP script: Hello World Unlike any other scripting language, PHP gets out of the way of the most common operation, that of outputting stuff. It also means that PHP has the absolute shortest and simplest Hello World you can have. Please don't change this. I have a number of scripts that use this feature to great advantage. Rick Rick Widmer Internet Marketing Specialists http://www.developersdesk.com -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] CLI max_execution_time
I try to make Linux programmers to change where they keep users configuration from $HOME to $HOME/.settings. In this way the users home will be clean. Please do not make a war from this suggestion, a simple yes or no is enough. Best regards, Emanuel -Original Message- From: Martín Marqués [mailto:[EMAIL PROTECTED]] Sent: 26 martie 2002 16:20 To: [EMAIL PROTECTED] Subject: Re: [PHP-DEV] CLI max_execution_time On Mar 26 Mar 2002 00:46, you wrote: ** Reply to note from Rasmus Lerdorf [EMAIL PROTECTED] Tue, 26 Mar 2002 01:41:59 -0800 (PST) Complete agree here. This is the sensible thing to do, albeit somehow aethetically disturbing. :-) Depends how you look at it. To me, this is a PHP script: Hello World Unlike any other scripting language, PHP gets out of the way of the most common operation, that of outputting stuff. It also means that PHP has the absolute shortest and simplest Hello World you can have. Please don't change this. I have a number of scripts that use this feature to great advantage. Didn't someone mention it been configurable? .php or .phprc or what ever. Saludos... :-) -- Porqué usar una base de datos relacional cualquiera, si podés usar PostgreSQL? - Martín Marqués |[EMAIL PROTECTED] Programador, Administrador, DBA | Centro de Telematica Universidad Nacional del Litoral - -- 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] CLI max_execution_time
Hi, I try to make Linux programmers to change where they keep users configuration from $HOME to $HOME/.settings. In this way the users home will be clean. Please do not make a war from this suggestion, a simple yes or no is enough. no (why dont you just setup your shell as most people do (so .xyz will be hidden?)) regards, Peter Petermann -- Homepage: www.cyberfly.net PHP Usergroups: www.phpug.de - [EMAIL PROTECTED] PHP Infos: www.php-center.de - [EMAIL PROTECTED] VL-SRM Homepage: www.vl-srm.net - [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CLI max_execution_time
On Mar 26 Mar 2002 00:46, you wrote: ** Reply to note from Rasmus Lerdorf [EMAIL PROTECTED] Tue, 26 Mar 2002 01:41:59 -0800 (PST) Complete agree here. This is the sensible thing to do, albeit somehow aethetically disturbing. :-) Depends how you look at it. To me, this is a PHP script: Hello World Unlike any other scripting language, PHP gets out of the way of the most common operation, that of outputting stuff. It also means that PHP has the absolute shortest and simplest Hello World you can have. Please don't change this. I have a number of scripts that use this feature to great advantage. Didn't someone mention it been configurable? .php or .phprc or what ever. Saludos... :-) -- Porqué usar una base de datos relacional cualquiera, si podés usar PostgreSQL? - Martín Marqués |[EMAIL PROTECTED] Programador, Administrador, DBA | Centro de Telematica Universidad Nacional del Litoral - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CLI max_execution_time
Edin Kadribasic wrote: That's ok. Calling function to set it should still work though. We should really get started on the IfModule .. thing for php.ini. Actually, no. A SAPI version of PHP should get configuration values the way a webserver does. It is running in the context of a webserver and should be handling things as webbish as they come. A CLI version of PHP is a kind of scripting shell at the same level as awk, perl and other scripting languages are. It should not behave webbish at all, but shelly instead. It should not output a content type by default (automatic -q option), it should read /etc/php.ini and $HOME/.php.ini. Please get this right the first time you do it. Kristian -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CLI max_execution_time
On Mon, Mar 25, 2002 at 10:45:04AM +0100, Kristian Köhntopp wrote : Edin Kadribasic wrote: That's ok. Calling function to set it should still work though. We should really get started on the IfModule .. thing for php.ini. Actually, no. A SAPI version of PHP should get configuration values the way a webserver does. It is running in the context of a webserver and should be handling things as webbish as they come. A CLI version of PHP is a kind of scripting shell at the same level as awk, perl and other scripting languages are. It should not behave webbish at all, but shelly instead. It should not output a content type by default (automatic -q option), it should read /etc/php.ini and $HOME/.php.ini. Please get this right the first time you do it. Mindreader, you ;) Actually, we're a bit late (and I complained that already in other places). 4.2.0 is already half-way out of the door with the CLI version and we don't have a proper setup for it yet. And I fear people in charge don't think it's critical enough to re-think the 4.2.0 release plan to get things done right the first time. - Markus -- Please always Cc to me when replying to me on the lists. GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CLI max_execution_time
On Mon, 25 Mar 2002, Markus Fischer wrote: Mindreader, you ;) Actually, we're a bit late (and I complained that already in other places). 4.2.0 is already half-way out of the door with the CLI version and we don't have a proper setup for it yet. And I fear people in charge don't think it's critical enough to re-think the 4.2.0 release plan to get things done right the first time. I agree it should be done right the first time, but for me the release plan is fixed. ANother possibility is to take the CLI out of 4.2.0, but I think that will only cause more problems. Derick --- PHP: Scripting the Web - [EMAIL PROTECTED] All your branches are belong to me! SRM: Script Running Machine - www.vl-srm.net --- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CLI max_execution_time
On Mon, Mar 25, 2002 at 12:56:21PM +0100, [EMAIL PROTECTED] wrote : On Mon, 25 Mar 2002, Markus Fischer wrote: Mindreader, you ;) Actually, we're a bit late (and I complained that already in other places). 4.2.0 is already half-way out of the door with the CLI version and we don't have a proper setup for it yet. And I fear people in charge don't think it's critical enough to re-think the 4.2.0 release plan to get things done right the first time. I agree it should be done right the first time, but for me the release plan is fixed. ANother possibility is to take the CLI out of 4.2.0, but I think that will only cause more problems. Actually, I think that would be a good idea to remove it. Do not release something which is not completely well thought and finished. People have lived without CLI for a while; they can wait. But don't create another/new headache with some broken system to which we have to be backwards compatible :/ - Markus -- Please always Cc to me when replying to me on the lists. GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CLI max_execution_time
[EMAIL PROTECTED] wrote: ANother possibility is to take the CLI out of 4.2.0, +1 from me. We have lived without the CLI for some time now. If we introduce it, it should be done right (correct defaults, reading preferences the right way). Kristian -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CLI max_execution_time
At 12:56 25.03.2002, [EMAIL PROTECTED] wrote: On Mon, 25 Mar 2002, Markus Fischer wrote: Mindreader, you ;) Actually, we're a bit late (and I complained that already in other places). 4.2.0 is already half-way out of the door with the CLI version and we don't have a proper setup for it yet. And I fear people in charge don't think it's critical enough to re-think the 4.2.0 release plan to get things done right the first time. I agree it should be done right the first time, but for me the release plan is fixed. ANother possibility is to take the CLI out of 4.2.0, but I think that will only cause more problems. Derick It seems that CLI does work but a lot of discussion about it's behaviour has started right now (seems just now people start playing around with it). So we should take the time until 4.3. For me especially both considered ideas $HOME/.php.ini and ifModule are a must have. marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CLI max_execution_time
Hi, On Mon, 25 Mar 2002 12:56:21 +0100 (CET) [EMAIL PROTECTED] wrote: I agree it should be done right the first time, but for me the release plan is fixed. ANother possibility is to take the CLI out of 4.2.0, but I think that will only cause more problems. +1 for removing cli from 4.2. It is quite impossible to provide QA for something that does not have a defined expected behaviour. Jan -- Q: Thank Jan? A: http://geschenke.an.dasmoped.net/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CLI max_execution_time
** Reply to note from Kristian =?iso-8859-1?Q?K=F6hntopp?= [EMAIL PROTECTED] Mon, 25 Mar 2002 10:45:04 +0100 A CLI version of PHP is a kind of scripting shell at the same level as awk, perl and other scripting languages are. It should not behave webbish at all, but shelly instead. It should not output a content type by default (automatic -q option), +1 it should read /etc/php.ini and $HOME/.php.ini. +maxint Of course if you specify a php.ini file location when you ./configure that should override /etc/php.ini. Rick Rick Widmer Internet Marketing Specialists http://www.developersdesk.com -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CLI max_execution_time
On 25/03/02, Kristian Köhntopp [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: ANother possibility is to take the CLI out of 4.2.0, +1 from me. +1 here too. We have lived without the CLI for some time now. If we introduce it, it should be done right (correct defaults, reading preferences the right way). +1 also. We can (and should) wait for it to be right before releasing/supporting it. --Wez. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CLI max_execution_time
[EMAIL PROTECTED] wrote: ANother possibility is to take the CLI out of 4.2.0, +1 from me. We have lived without the CLI for some time now. If we introduce it, it should be done right (correct defaults, reading preferences the right way). I have to disagree with you guys here. We are, after all, past RC1 at this point and doing a major surgery on php and its build and test systems is irresponsible. I hate to say it, but there were plenty of opportunities to bring up the issues with CLI in the past several months. I could go the long way and repeat the motivatiom behind the creation of CLI at this point, but instead I would like to recommend that we take evolutionary approach. First make CLI a CGI without all the CGI garbage. Always build it with PHP. (this is where we are now). The next step is moving PHP in the direction of general purpose scripting language. Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CLI max_execution_time
On Mon, 25 Mar 2002, Edin Kadribasic wrote: I have to disagree with you guys here. We are, after all, past RC1 at this point and doing a major surgery on php and its build and test systems is irresponsible. A very big point, I totally agree with you on this. This is not an option after all. I hate to say it, but there were plenty of opportunities to bring up the issues with CLI in the past several months. I could go the long way and repeat the motivatiom behind the creation of CLI at this point, but instead I would like to recommend that we take evolutionary approach. First make CLI a CGI without all the CGI garbage. Always build it with PHP. (this is where we are now). The next step is moving PHP in the direction of general purpose scripting language. And what if we disable the CLI by default for 4.2.0 and make a switch --enable-cli to enable building of the CLI. This makes it more clear that it's still experimental. In 4.3.0 we simply change the default to always build the CLI. Derick --- PHP: Scripting the Web - [EMAIL PROTECTED] All your branches are belong to me! SRM: Script Running Machine - www.vl-srm.net --- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CLI max_execution_time
At 15:30 25.03.2002, Edin Kadribasic wrote: [EMAIL PROTECTED] wrote: ANother possibility is to take the CLI out of 4.2.0, +1 from me. We have lived without the CLI for some time now. If we introduce it, it should be done right (correct defaults, reading preferences the right way). I have to disagree with you guys here. We are, after all, past RC1 at this point and doing a major surgery on php and its build and test systems is irresponsible. I hate to say it, but there were plenty of opportunities to bring up the issues with CLI in the past several months. I could go the long way and repeat the motivatiom behind the creation of CLI at this point, but instead I would like to recommend that we take evolutionary approach. First make CLI a CGI without all the CGI garbage. Always build it with PHP. (this is where we are now). The next step is moving PHP in the direction of general purpose scripting language. Edin Ithink we all know this - but what you wrote *is* the reason to remove CLI from 4.2 - we all seem unhappy with its current behaviour so why not wait until we have made CLI that general purpose scripting language. To derick as RM: I think removing a feature is less a problem that adding but we are on RC1. So it's up to you! marcus -- 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] CLI max_execution_time
On Mon, 25 Mar 2002, Marcus Börger wrote: Ithink we all know this - but what you wrote *is* the reason to remove CLI from 4.2 - we all seem unhappy with its current behaviour so why not wait until we have made CLI that general purpose scripting language. To derick as RM: I think removing a feature is less a problem that adding but we are on RC1. So it's up to you! The CLI has too many roots into the build system. Removing it would be problematic. It's not an option to me. Derick --- PHP: Scripting the Web - [EMAIL PROTECTED] All your branches are belong to me! SRM: Script Running Machine - www.vl-srm.net --- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CLI max_execution_time
Hi, On Mon, 25 Mar 2002 15:36:38 +0100 (CET) [EMAIL PROTECTED] wrote: And what if we disable the CLI by default for 4.2.0 and make a switch --enable-cli to enable building of the CLI. This makes it more clear that it's still experimental. In 4.3.0 we simply change the default to always build the CLI. ok, then +1 on that. It seems to be a fair compromise. Jan -- Q: Thank Jan? A: http://geschenke.an.dasmoped.net/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CLI max_execution_time
I could go the long way and repeat the motivatiom behind the creation of CLI at this point, but instead I would like to recommend that we take evolutionary approach. First make CLI a CGI without all the CGI garbage. Always build it with PHP. (this is where we are now). The next step is moving PHP in the direction of general purpose scripting language. Edin Ithink we all know this - but what you wrote *is* the reason to remove CLI from 4.2 - we all seem unhappy with its current behaviour so why not wait until we have made CLI that general purpose scripting language. You cannot make that happen overnight. Thus the evolutionary appoach. Do you know that the changes to the build system so that stand alone php binary was always built was added to PHP4 TODO list on April 28, 2000 (that's before 4.0.0 was released)? Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CLI max_execution_time
On Mon, Mar 25, 2002 at 04:20:13PM +0100, Jan Lehnardt wrote : Hi, On Mon, 25 Mar 2002 15:36:38 +0100 (CET) [EMAIL PROTECTED] wrote: And what if we disable the CLI by default for 4.2.0 and make a switch --enable-cli to enable building of the CLI. This makes it more clear that it's still experimental. In 4.3.0 we simply change the default to always build the CLI. ok, then +1 on that. It seems to be a fair compromise. Then please (derick) put a big fat bold red flashing note next to the configure line and say it's experifuckingmental . . . :) - Markus -- Please always Cc to me when replying to me on the lists. GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CLI max_execution_time
Hi, On Mon, 25 Mar 2002 16:21:58 +0100 Edin Kadribasic [EMAIL PROTECTED] wrote: You cannot make that happen overnight. Thus the evolutionary appoach. Do you know that the changes to the build system so that stand alone php binary was always built was added to PHP4 TODO list on April 28, 2000 (that's before 4.0.0 was released)? that does not allow us release unthought things as stable. I hope we can agree on the --disable-cli approach for 4.2 and fully integrate CLI into 4.3. Jan -- Q: Thank Jan? A: http://geschenke.an.dasmoped.net/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CLI max_execution_time
I have to disagree with you guys here. We are, after all, past RC1 at
this
point and doing a major surgery on php and its build and test systems is
irresponsible.
A very big point, I totally agree with you on this. This is not an option
after all.
I hate to say it, but there were plenty of opportunities to
bring up the issues with CLI in the past several months.
I could go the long way and repeat the motivatiom behind the creation of
CLI
at this point, but instead I would like to recommend that we take
evolutionary approach. First make CLI a CGI without all the CGI garbage.
Always build it with PHP. (this is where we are now). The next step is
moving PHP in the direction of general purpose scripting language.
And what if we disable the CLI by default for 4.2.0 and make a switch
--enable-cli to enable building of the CLI. This makes it more clear that
it's still experimental. In 4.3.0 we simply change the default to always
build the CLI.
I still think that people need to adjust to some major changes CLI brings
(not chdiring into the scripts directory, etc.)...
But... if you insist.
Disabling it is not good due to the test suite, etc. Instead:
1. Mark it experimental.
2. Change make install not to install it.
3. Change make install on cgi to install it in {BINDIR}/php as it used to.
In that way people will not notice its presence, and even if they do its
marked experimental. The changes we need to make to the build system are
minimal.
Edin
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CLI max_execution_time
that does not allow us release unthought things as stable. I hope we can agree on the --disable-cli approach for 4.2 and fully integrate CLI into 4.3. Is it unstable? I was under the impression that we're talking about feature set. Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CLI max_execution_time
that does not allow us release unthought things as stable. I hope we can agree on the --disable-cli approach for 4.2 and fully integrate CLI into 4.3. Is it unstable? I was under the impression that we're talking about feature set. here: stable as in we have some kind of agenda what CLI does in certain cases. We don't have this right now, so I call it unstable. That regards to the changes that need to be made to make a real-shell-application out of CLI, not to CLI in general. Well I had an agenda for the first release of CLI and the current implementation fullfills that agenda. Nobody objected to it until today. Therefore I assumed that it was accepted. Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CLI max_execution_time
On Mon, Mar 25, 2002 at 04:54:08PM +0100, Edin Kadribasic wrote : that does not allow us release unthought things as stable. I hope we can agree on the --disable-cli approach for 4.2 and fully integrate CLI into 4.3. Is it unstable? I was under the impression that we're talking about feature set. here: stable as in we have some kind of agenda what CLI does in certain cases. We don't have this right now, so I call it unstable. That regards to the changes that need to be made to make a real-shell-application out of CLI, not to CLI in general. Well I had an agenda for the first release of CLI and the current implementation fullfills that agenda. Nobody objected to it until today. Therefore I assumed that it was accepted. The inconsistency was just yet discovered. Free working volunteers do not have time when you finish somethin for testing. No response/objections doesn't mean everything is fine ;-) Anyway, I hope you can fix the issue witht he maximum execution time properly. - Markus -- Please always Cc to me when replying to me on the lists. GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CLI max_execution_time
I'd kind of agree with this. I use both the apache SAPI module and the CLI side by side in a single system (the web server does it's thing, and the CLI powers the search engine, which the web server can use on a per-request basis and ties the two together with XML/XSLT). One of the problems I had when playing around with PHP-4.2.0dev (I believe, it might have been 4.3dev) was that the CLI was built by default, yet I use very different set ups for the apache module and the CLI module. There are a lot of extensions that aren't shared between the two, and it basically meant compiling the CLI twice -- once when I built the apache module and again to get the CLI executable I needed. I'd also like to see that automatic -q header hiding and, as has been discussed before, a separation of the web server's php.ini file and the CLI's, as I always have trouble with the two. (For instance, in the apache module, I always have output buffering set to something liek 4K, but on the CLI, I don't want output buffering at all. Little things like that.) My opinion, for all it's worth. J Markus Fischer wrote: Actually, I think that would be a good idea to remove it. Do not release something which is not completely well thought and finished. People have lived without CLI for a while; they can wait. But don't create another/new headache with some broken system to which we have to be backwards compatible :/ - Markus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CLI max_execution_time
I'd kind of agree with this. I use both the apache SAPI module and the CLI side by side in a single system (the web server does it's thing, and the CLI powers the search engine, which the web server can use on a per-request basis and ties the two together with XML/XSLT). One of the problems I had when playing around with PHP-4.2.0dev (I believe, it might have been 4.3dev) was that the CLI was built by default, yet I use very different set ups for the apache module and the CLI module. There are a lot of extensions that aren't shared between the two, and it basically meant compiling the CLI twice -- once when I built the apache module and again to get the CLI executable I needed. I'd also like to see that automatic -q header hiding and, as has been discussed before, a separation of the web server's php.ini file and the CLI's, as I always have trouble with the two. (For instance, in the apache module, I always have output buffering set to something liek 4K, but on the CLI, I don't want output buffering at all. Little things like that.) Are you sure you were testing it with CLI? Header hiding (-q) has been in there since the first check-in back in Jan 6. If you have sufficiently different setups, there is no way but to configure and compile PHP twice. Building of CLI creates no big overhead (just two c files and one extra link step). Yes, there was a discussion about separating php.ini file for cli (php-cli.ini). At the end most people said that their configurations were sufficiently similar and that the content of those two files would be mostly the same. Derick promised to implement some sort of IfModule ... mechanism, but I guess he was busy with other things. Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CLI max_execution_time
On Mon, 25 Mar 2002, Edin Kadribasic wrote: Are you sure you were testing it with CLI? Header hiding (-q) has been in there since the first check-in back in Jan 6. If you have sufficiently different setups, there is no way but to configure and compile PHP twice. Building of CLI creates no big overhead (just two c files and one extra link step). Yes, there was a discussion about separating php.ini file for cli (php-cli.ini). At the end most people said that their configurations were sufficiently similar and that the content of those two files would be mostly the same. Derick promised to implement some sort of IfModule ... mechanism, but I guess he was busy with other things. I can't rememberr I promised it :) but I looked into it. It's not at all that simple I'm afraid :( Derick -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CLI max_execution_time
I can't rememberr I promised it :) but I looked into it. It's not at all that simple I'm afraid :( Let me refresh you memory then: http://groups.google.com/groups?hl=enth=1a4afc1bc6afa8a4seekm=Pine.LNX.4.3 3.0202281357200.522-10%40kossu.office.jdimedia.nlframe=off Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CLI max_execution_time
You're right about the -q thing, I didn't notice it the first time. (I kind of just run -q now without thinking about it.) It's not a big thing to do the separate compiles, so it's no worry. Just a little annoyance, but I'll live. This isn't a big issue or anything, sort of a nice-to-have. But if I'm in the minority for wanting this, that's fine, I'll live. J Edin Kadribasic wrote: Are you sure you were testing it with CLI? Header hiding (-q) has been in there since the first check-in back in Jan 6. If you have sufficiently different setups, there is no way but to configure and compile PHP twice. Building of CLI creates no big overhead (just two c files and one extra link step). Yes, there was a discussion about separating php.ini file for cli (php-cli.ini). At the end most people said that their configurations were sufficiently similar and that the content of those two files would be mostly the same. Derick promised to implement some sort of IfModule ... mechanism, but I guess he was busy with other things. Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CLI max_execution_time
On Sun, 24 Mar 2002, Markus Fischer wrote: Hi, currently the CLI version also has by default a max_execution_time of 30 seconds. I don't think this is very appealing for people to use the CLI version. I really think the execution time for the CLI version should be unlimited by default. Any objections ? Agreed, and (almost) fixed in CVS :) Derick --- PHP: Scripting the Web - [EMAIL PROTECTED] All your branches are belong to me! SRM: Script Running Machine - www.vl-srm.net --- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CLI max_execution_time
On Sun, Mar 24, 2002 at 03:04:18PM +0100, Marcus Börger wrote : I do not think it is a good idea to have many 'special ways' in cLI. Such as always registering argc/argv we have already. For me i would more likly have a special section in php.ini to set all this. You don't seem to undertand. CLI _is_ special. It lives in another environment then the apache/cgi SAPI does. How come you think treating the CLI version the same is a good idea when they in fact have to work under very different environments/conditions ? Would you EVER expect a bash/perl/awk/sed/python/nameit script by default only run a certain amount of time, namely it's maximum execution time ? Certainly not. marcus example *default* section: [CLI] register_argc_argv = On max_execution_time = Off memory_limit = Off engine = Off zlib.output_compression = Off safe_mode = Off display_errors = On display_startup_errors = On html_errors = Off default_mimetype = default_charset = The problem is, as long as you do not have such a configuration file, you're really lost. when you install PHP, the ini file is NOT installed. And, it can and I make you a pledge it will confuse people. I think you just have to live with that the CLI version is different and therefore needs to be handled different in some aspects (which in fact are required to truly make use of it). - Markus -- Please always Cc to me when replying to me on the lists. GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CLI max_execution_time
I do not think it is a good idea to have many 'special ways' in cLI. Such as always registering argc/argv we have already. For me i would more likly have a special section in php.ini to set all this. marcus example *default* section: [CLI] register_argc_argv = On max_execution_time = Off memory_limit = Off engine = Off zlib.output_compression = Off safe_mode = Off display_errors = On display_startup_errors = On html_errors = Off default_mimetype = default_charset = At 09:40 24.03.2002, you wrote: Hi, currently the CLI version also has by default a max_execution_time of 30 seconds. I don't think this is very appealing for people to use the CLI version. I really think the execution time for the CLI version should be unlimited by default. Any objections ? - Markus -- Please always Cc to me when replying to me on the lists. GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc -- 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] CLI max_execution_time
At 15:32 24.03.2002, Markus Fischer wrote: On Sun, Mar 24, 2002 at 03:04:18PM +0100, Marcus Börger wrote : I do not think it is a good idea to have many 'special ways' in cLI. Such as always registering argc/argv we have already. For me i would more likly have a special section in php.ini to set all this. You don't seem to undertand. CLI _is_ special. It lives in another environment then the apache/cgi SAPI does. Of cause i do - but i would like it to use most of the environment we have. In special it uses the php.ini so why not give it a special section to make it clear where the differences are. How come you think treating the CLI version the same is a good idea when they in fact have to work under very different environments/conditions ? Using a special section for CLI would allow providing such different conditions. Would you EVER expect a bash/perl/awk/sed/python/nameit script by default only run a certain amount of time, namely it's maximum execution time ? Certainly not. No i don't but is a feature we have so why not disable it by default ini entry instead of implementing a work around? marcus example *default* section: [CLI] register_argc_argv = On max_execution_time = Off memory_limit = Off engine = Off zlib.output_compression = Off safe_mode = Off display_errors = On display_startup_errors = On html_errors = Off default_mimetype = default_charset = The problem is, as long as you do not have such a configuration file, you're really lost. when you install PHP, the ini file is NOT installed. And, it can and I make you a pledge it will confuse people. I think you just have to live with that the CLI version is different and therefore needs to be handled different in some aspects (which in fact are required to truly make use of it). - Markus -- Please always Cc to me when replying to me on the lists. GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CLI max_execution_time
On Sun, Mar 24, 2002 at 03:40:10PM +0100, Marcus Börger wrote : At 15:32 24.03.2002, Markus Fischer wrote: On Sun, Mar 24, 2002 at 03:04:18PM +0100, Marcus Börger wrote : I do not think it is a good idea to have many 'special ways' in cLI. Such as always registering argc/argv we have already. For me i would more likly have a special section in php.ini to set all this. You don't seem to undertand. CLI _is_ special. It lives in another environment then the apache/cgi SAPI does. Of cause i do - [...] I don't think so, I'm sorry. ;-) How come you think treating the CLI version the same is a good idea when they in fact have to work under very different environments/conditions ? Using a special section for CLI would allow providing such different conditions. In fact this is something which has to be entirely discussed too. No propose, no (real) plan has yet been made how/if to manage those different SAPIs configurations in the future. Would you EVER expect a bash/perl/awk/sed/python/nameit script by default only run a certain amount of time, namely it's maximum execution time ? Certainly not. No i don't but is a feature we have so why not disable it by default ini entry instead of implementing a work around? Because specifically *I* and certainly other would not expect a shell scripting language to only run for about 30 seconds because the proper ini file is not present! Such a dependency is idiocy. - Markus -- Please always Cc to me when replying to me on the lists. GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CLI max_execution_time
Because specifically *I* and certainly other would not expect a shell scripting language to only run for about 30 seconds because the proper ini file is not present! Such a dependency is idiocy. I agree 100%. Will be commiting change later today if nobody beats me to it. Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CLI max_execution_time
On Sun, Mar 24, 2002 at 05:20:12PM +0100, Edin Kadribasic wrote : Because specifically *I* and certainly other would not expect a shell scripting language to only run for about 30 seconds because the proper ini file is not present! Such a dependency is idiocy. I agree 100%. Finally :-) Will be commiting change later today if nobody beats me to it. Maybe I should mention something. Derick and I were discussing this already and 'playing' around. We found out that in php4/sapi/cli/php_cli.c around line 397 there are a few default settings set with zend_alter_ini_entry(). Mind that, when we tried to insert a new one which sets the max_execution_time it worked BUT ... you could not readjust that value via the php.ini anymore. The very same applies to the other two settings which are already in-place. - Markus -- Please always Cc to me when replying to me on the lists. GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CLI max_execution_time
On Sun, 24 Mar 2002, Edin Kadribasic wrote: Because specifically *I* and certainly other would not expect a shell scripting language to only run for about 30 seconds because the proper ini file is not present! Such a dependency is idiocy. I agree 100%. Will be commiting change later today if nobody beats me to it. A note: if you only add this line: zend_alter_ini_entry(max_execution_time, 19, 0, 1, PHP_INI_SYSTEM, PHP_INI_STAGE_ACTIVATE); then you can't change it in php.ini anymore. Markus and I already tried that :) Derick --- PHP: Scripting the Web - [EMAIL PROTECTED] All your branches are belong to me! SRM: Script Running Machine - www.vl-srm.net --- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CLI max_execution_time
Because specifically *I* and certainly other would not expect a shell scripting language to only run for about 30 seconds because the proper ini file is not present! Such a dependency is idiocy. I agree 100%. Will be commiting change later today if nobody beats me to it. A note: if you only add this line: zend_alter_ini_entry(max_execution_time, 19, 0, 1, PHP_INI_SYSTEM, PHP_INI_STAGE_ACTIVATE); then you can't change it in php.ini anymore. Markus and I already tried that :) That's ok. Calling function to set it should still work though. We should really get started on the IfModule .. thing for php.ini. Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
