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.
-Rasmus On Thu, 26 Sep 2002, David Viner wrote: > I thought about reading only *.ini files when directories were specified, > and the main reason I didn't implement that is simply because I thought the > PHP include functionality should behave like Apache's Include directive. > Apache's include doesn't worry about ~ files and .ORIG or .OLD or .bak > files, so why should PHP's? That said, I am happy to rework the patch to > only include files that end in ".ini" if the group feels this is the > appropriate action of an include statement. (Personally, I think if a user > puts garbage in a directory, then says include that directory, then c'est la > vie.) > > 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. > > > dave > > -----Original Message----- > From: Rasmus Lerdorf [mailto:[EMAIL PROTECTED]] > Sent: 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/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 = /some/dir/my_ext > > My only concern about the full directory scanning and reading every file > is that there could be foo.ini~ created by editors or other such junk in > there. So perhaps only read in .ini files, or maybe use the new glob code > to allow /some/dir/*.ini to specify. Probably going a bit too far as > well. > > -Rasmus > > > On Thu, 26 Sep 2002, Zeev Suraski wrote: > > > 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 after php.ini loads up. Only one (at most) such > > directory, full path required. > > > > This gives you (as far as I can tell) the modular deployment features, but > > won't make people beg for 'if'. > > > > Thoughts? > > > > Zeev > > > > At 00:50 26/09/2002, Rasmus Lerdorf wrote: > > >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 > > >being able to do a simple include of individual files or directories of > > >files seems like a useful thing to me when building a modular PHP > > >deployment system. > > > > > >-Rasmus > > > > > > > > >-- > > >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 Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
