On Sat, 28 Sep 2002, Zeev Suraski wrote:
At 19:27 26/09/2002, David Viner wrote:
If the term include is not a good keyword, I'm also happy to rework the
patch to use any keyword the group prefers. additional_ini sounds good to
me, and probably doesn't carry the other control-structure
: Thursday, September 26, 2002 5:17 AM
To: Zeev Suraski
Cc: David Viner; Php-Dev@lists. php. net
Subject: RE: [PHP-DEV] [PATCH] include statement in php.ini file
I suppose using a PHP keyword like include may lead to a desire for other
PHP keywords, perhaps something like:
additional_ini = /some
I'm not very concerned either way on the .ini extension
restriction.
Let's go ahead and commit this with the include to
additional_ini name
change. Perhaps the commit will stir up more feedback since there
has
been so little.
Some feedback:
+1 for additional_ini=/path/to/new/additional.ini
I'm not very concerned either way on the .ini extension
restriction.
Let's go ahead and commit this with the include to
additional_ini name
change. Perhaps the commit will stir up more feedback since there
has
been so little.
Some feedback:
+1 for
: Friday, September 27, 2002 9:14 AM
To: Edin Kadribasic
Cc: David Viner; Php-Dev@lists. php. net
Subject: Re: [PHP-DEV] [PATCH] include statement in php.ini file
I'm not very concerned either way on the .ini extension
restriction.
Let's go ahead and commit this with the include to
additional_ini
In general I agree with this proposal but I have some concerns, as I am
not familiar with the ini code these may be unfounded, introducing it
may well
1) Introduce Security Concerns depending on the time the ini file is
loaded (IF I have safe_mode = on then you include an ini file with
] [PATCH] include statement in php.ini file
In general I agree with this proposal but I have some concerns, as I am
not familiar with the ini code these may be unfounded, introducing it
may well
1) Introduce Security Concerns depending on the time the ini file is
loaded (IF I have safe_mode
Subject: Re: [PHP-DEV] [PATCH] include statement in php.ini file
I'm not very concerned either way on the .ini extension
restriction.
Let's go ahead and commit this with the include to
additional_ini name
change. Perhaps the commit will stir up more feedback since there
has
been
-
From: Rasmus Lerdorf [mailto:[EMAIL PROTECTED]]
Sent: Friday, September 27, 2002 9:14 AM
To: Edin Kadribasic
Cc: David Viner; Php-Dev@lists. php. net
Subject: Re: [PHP-DEV] [PATCH] include statement in php.ini file
I'm not very concerned either way on the .ini extension
I'd vote with Rasmus here. Adding an include statement (whatever it's
called) looks to be very low risk for inclusion in the 4.3 release.
I am a little uncomfortable with the auto-magic function to include all
files in directory. I've been bitten more than a few times by magic that
didn't do
At 19:27 26/09/2002, David Viner wrote:
If the term include is not a good keyword, I'm also happy to rework the
patch to use any keyword the group prefers. additional_ini sounds good to
me, and probably doesn't carry the other control-structure baggage.
I don't think that additional_ini carries
I'm concerned that adding this directive will make lead to control
structures requirements. However, it is quite useful for modular
deployment; So, my suggestion is:
- Don't introduce 'include'
- Introduce a special 'additional_ini_directory' (name subject to change)
which will be read
I suppose using a PHP keyword like include may lead to a desire for other
PHP keywords, perhaps something like:
additional_ini = /some/dir
additional_ini = /some/file.ini
Not sure why you want to limit it to one. Also, they can be nested, so in
/some/dir/foo.ini you might have:
additional_ini
: Thursday, September 26, 2002 5:17 AM
To: Zeev Suraski
Cc: David Viner; Php-Dev@lists. php. net
Subject: RE: [PHP-DEV] [PATCH] include statement in php.ini file
I suppose using a PHP keyword like include may lead to a desire for other
PHP keywords, perhaps something like:
additional_ini = /some
I don't see any obvious problems with this patch except for a couple of
extrananeos changes. I was a bit indisposed last week and didn't really
follow the discussion leading up to this, but I have read the archive. I
agree that going full out with PHP-parsed .ini files is going too far, but
sorry, the attachment didn't make it. here's the patch inlined.
== BEGIN PATCH ==
Index: configure.in
===
RCS file: /repository/php4/configure.in,v
retrieving revision 1.372
diff -u -b -B -r1.372 configure.in
---
16 matches
Mail list logo
