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
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
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
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
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
** 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
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
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
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
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
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
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
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
[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
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
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.
** 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
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
[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,
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.
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
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
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
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
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
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
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
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/
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
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
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
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
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
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
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.
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
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
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
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
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
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.
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
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
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
44 matches
Mail list logo
