Re: [PHP-DEV] config.w32.h...registry configuration

[Zeev Suraski]

At 17:24 03/05/2002, Jim Winstead wrote:
>Zeev Suraski <[EMAIL PROTECTED]> wrote:
> > We could add it. I just hope people wouldn't start demanding control
> > structures in there to start selectively loading other files...
>
>let's just hope that by then, someone realizes we already have a
>scanner and parser that handles such a language close at hand.

Yes and no - I actually wrote up a paragraph suggesting a switch to PHP, 
but thinking about it for a bit, it appears to be just too messy, with too 
many chicken and egg problems.

Zeev


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] config.w32.h...registry configuration

[Pierre-Alain Joye]

> Pierre-Alain Joye wrote:
> >>Seriously, being able to include other ini files is a great feature,
> >>especially for hosters who will then be able to set up site-wide config
> >>files that are included from per-vhost config files, etc.  You can have
> >>your cake and eat it too.
> >
> > Sure :).
> > A way to make this functionnality on others server than apache
> is a must.
> >
> > The php_xxx directive let admin makes a custom config per host. On IIS,
> > iplanet, there is actually no way to do it.
>
> Not realy true, you can do it via registry.
Do you a link where I can find info about how to use the registry ?

I believe this feature is not available on Iplanet, especially on Solaris
system. For the same reasons wrote in the last rasmus post, the virtual
server server on iplanet is really not a good solution, performances are
really bads.



pa


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] config.w32.h...registry configuration

[Shane Caraveo]

There's no reason to not put in the bin-dir solution now.  I just would 
like to see an eventual full solution to the issue.

Zeev Suraski wrote:
> IMHO, the enemy of the good is the better.
> We can implement the binary-dir solution in no time, and it covers >95% 
> of the problems easily, but instead we'll be discussing perfect 
> solutions and end up doing nothing :)
> 
> My 2 agorot.
> 
> Zeev
> 
> At 08:03 03/05/2002, Markus Fischer wrote:
> 
>> Hi,
>>
>> but including other INI files at this stage is only of real
>> advantage if we can also conditionally include it, no? Like,
>> depending on the version too.
>>
>> How about looking for the version number in the filename too
>> first, e.g.:
>>
>> php-apache-4.2.1.ini
>> php-apache.ini
>> php.ini
>>
>> ?
>>
>> This way it's even more less pain to have different versions
>> installed.
>>
>> - Markus
>>
>> On Fri, May 03, 2002 at 06:54:41AM +0200, Stig S. Bakken wrote :
>> > On Thu, 2002-05-02 at 21:18, Shane Caraveo wrote:
>> > > Zeev Suraski wrote:
>> > > > Does anybody have an opinion about this?
>> > >
>> > > Of course! ;)
>> > >
>> > > ini search order
>> > > 1. PHP_BIN_DIR (\php\)
>> > > 2. OS_DIR (\winnt\)
>> > >
>> > > To fix the ini issue we need more than just this.  The best I can 
>> come
>> > > up with right now is:
>> > >
>> > > 1. implement bang line parsing.  This way, a specific script can 
>> define
>> > > what ini file it wants to use.  It should only be available in 
>> CGI/CLI
>> > > systems.
>> > >
>> > > 2. add support for -c to use filenames in addition to paths.  This 
>> way
>> > > a single directory can contain multiple different config files.
>> > >
>> > > 3. have sapi modules (dll's) detect their directory so that server
>> > > modules can correctly define where the ini file is for a particular
>> > > installation.
>> > >
>> > > 4. For web servers, allow ini filenames to be php-domain.com.ini (or
>> > > something like that) and have sapi modules look for that first if
>> > > SERVER_NAME is available.
>> > >
>> > > 5. Implement 'override' ini files, which basicly behave the same as
>> > > .htaccess.  Use of these is settable in the 'global' ini file.  They
>> > > exist in the same directory as the script itself, and are read
>> > > recursivly through the parent directory structure to some root (web
>> > > root).  This of course would be cached in persistent systems, CGI/CLI
>> > > users would probably not want to use this feature.
>> > >
>> > > Some of the above will rely on the OS security being configured
>> > > correctly so that people cannot access each other's ini files, but 
>> that
>> > > is not the responsibility of PHP to handle (though it could be
>> > > documented to some extent).
>> >
>> > I think we should add:
>> >
>> > 6. Implement "include_ini" directive
>> >
>> > 7. Look for php-.ini first, and php.ini if not found (this may
>> > double the disk activity, if that's acceptable).
>> >
>> >  - Stig
>> >
>> >
>> > --
>> > PHP Development Mailing List 
>> > To unsubscribe, visit: http://www.php.net/unsub.php
>>
>> -- 
>> Please always Cc to me when replying to me on the lists.
>> GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc
>> "Mind if I MFH ?" "What QA did you do on it?" "the usual?" "ah... none 
>> :)"
> 
> 
> 




-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] config.w32.h...registry configuration

[Shane Caraveo]

Joseph Tate wrote:
>>Well, you are correct that the size of the executable is irrelevant, but
>>having different instances of PHP means less shared pages when multiple
>>copies are loaded.  There is a definite advantage to having a single httpd
>>binary that is the same for everyone when it comes to runtime memory
>>usage.
> 
> 
> There is a way around this; well the majority chunk of this problem can be
> solved by simply making the largest chunk of php into a library, then you
> have tiny launching executables that live in the various directories, and
> each similar versioned "copy" of php uses the same php4.so.4.2.1 library (or
> similar on Winbloze (10 blue screens too many last night on 2000 and XP)).
> There will be even more pressure to provide BC, but it will reduce the
> overall memory footprint.  Each executable will have its own heap and stack,
> but the library will be shared, and its memory will be shared.  Someone was
> talking about making php into a shared library, this is just more incentive
> to do so.
> 
> Joseph

Last I looked, php was a shared library, but I could just be getting old ;)




-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] config.w32.h...registry configuration

[Shane Caraveo]

Pierre-Alain Joye wrote:
>>Seriously, being able to include other ini files is a great feature,
>>especially for hosters who will then be able to set up site-wide config
>>files that are included from per-vhost config files, etc.  You can have
>>your cake and eat it too.
> 
> Sure :).
> A way to make this functionnality on others server than apache is a must.
> 
> The php_xxx directive let admin makes a custom config per host. On IIS,
> iplanet, there is actually no way to do it.

Not realy true, you can do it via registry.

Shane




-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] config.w32.h...registry configuration

[Jim Winstead]

Zeev Suraski <[EMAIL PROTECTED]> wrote:
> We could add it. I just hope people wouldn't start demanding control 
> structures in there to start selectively loading other files...

let's just hope that by then, someone realizes we already have a
scanner and parser that handles such a language close at hand.

:)

jim

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] config.w32.h...registry configuration

[Joseph Tate]

> Well, you are correct that the size of the executable is irrelevant, but
> having different instances of PHP means less shared pages when multiple
> copies are loaded.  There is a definite advantage to having a single httpd
> binary that is the same for everyone when it comes to runtime memory
> usage.

There is a way around this; well the majority chunk of this problem can be
solved by simply making the largest chunk of php into a library, then you
have tiny launching executables that live in the various directories, and
each similar versioned "copy" of php uses the same php4.so.4.2.1 library (or
similar on Winbloze (10 blue screens too many last night on 2000 and XP)).
There will be even more pressure to provide BC, but it will reduce the
overall memory footprint.  Each executable will have its own heap and stack,
but the library will be shared, and its memory will be shared.  Someone was
talking about making php into a shared library, this is just more incentive
to do so.

Joseph


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] config.w32.h...registry configuration

[Rasmus Lerdorf]

> This is true, there will be less shared pages.  I *want* this!
> (Though I was talking about PHP and not httpd).

Well, they are commonly one and the same.  But I guess you are on a
Windows/CGI platform?  This doesn't really apply there.

-Rasmus


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] config.w32.h...registry configuration

[Preston L. Bannister]

From: Rasmus Lerdorf [mailto:[EMAIL PROTECTED]]
> Well, you are correct that the size of the executable is irrelevant, but
> having different instances of PHP means less shared pages when multiple
> copies are loaded.  There is a definite advantage to having a single httpd
> binary that is the same for everyone when it comes to runtime memory
> usage.

This is true, there will be less shared pages.  I *want* this!
(Though I was talking about PHP and not httpd).

When we ship a new version of our application to our customers, 
it will have been tested with a specific version of PHP.

If the customer installs another application that uses PHP, and
that application installs it's own version of PHP, there is some
risk (if PHP were shared) then this could break our application.

We really don't want our application to break!  Oddly enough the
customer feels pretty much the same.  Given the choice of burning
a bit of memory and disk space versus risking failure (and this 
could effect hundreds or thousands of users), the customer will
gladly buy just a bit more memory :).


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] config.w32.h...registry configuration

[Rasmus Lerdorf]

Well, you are correct that the size of the executable is irrelevant, but
having different instances of PHP means less shared pages when multiple
copies are loaded.  There is a definite advantage to having a single httpd
binary that is the same for everyone when it comes to runtime memory
usage.

-Rasmus

On Fri, 3 May 2002, Preston L. Bannister wrote:

> From: Zeev Suraski [mailto:[EMAIL PROTECTED]]
> > IMHO, the enemy of the good is the better.
> > We can implement the binary-dir solution in no time, and it covers >95% of
> > the problems easily, but instead we'll be discussing perfect solutions and
> > end up doing nothing :)
>
> Yes, please! :)
>
> Remember KISS ... (and I'm not getting over-friendly here).
>
> In fact you can get pretty near 100% with the simple solution just by having
> multiple copies of the PHP executable in different directories - one for each
> differing configuration.  On modern disks the size of PHP is insignificant,
> so having multiple copies is a non-issue.
>
> In fact this is an advantage.  If (say) you are running multiple PHP-based
> web applications, each requiring different configurations, you may in fact
> be dependent on different versions of PHP.  A good, careful sysadmin will
> want to upgrade one application at a time (and test!) rather than all at
> once, and will want each application using it's own PHP executable.
>
> IMHO the more complicated solutions aren't really needed.
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
>


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] config.w32.h...registry configuration

[Preston L. Bannister]

From: Zeev Suraski [mailto:[EMAIL PROTECTED]]
> IMHO, the enemy of the good is the better.
> We can implement the binary-dir solution in no time, and it covers >95% of 
> the problems easily, but instead we'll be discussing perfect solutions and 
> end up doing nothing :)

Yes, please! :)

Remember KISS ... (and I'm not getting over-friendly here).

In fact you can get pretty near 100% with the simple solution just by having
multiple copies of the PHP executable in different directories - one for each
differing configuration.  On modern disks the size of PHP is insignificant, 
so having multiple copies is a non-issue.  

In fact this is an advantage.  If (say) you are running multiple PHP-based 
web applications, each requiring different configurations, you may in fact
be dependent on different versions of PHP.  A good, careful sysadmin will
want to upgrade one application at a time (and test!) rather than all at
once, and will want each application using it's own PHP executable.

IMHO the more complicated solutions aren't really needed.


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] config.w32.h...registry configuration

[Zeev Suraski]

At 07:51 03/05/2002, Stig S. Bakken wrote:
>Edin and I were discussing ini files on IRC last night and the same idea
>came up.  With the exact same syntax too, actually.  This is divine
>proof that the include_ini is good and must be implemented. :-)
>
>Seriously, being able to include other ini files is a great feature,
>especially for hosters who will then be able to set up site-wide config
>files that are included from per-vhost config files, etc.  You can have
>your cake and eat it too.

We could add it. I just hope people wouldn't start demanding control 
structures in there to start selectively loading other files...

Zeev


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] config.w32.h...registry configuration

[Zeev Suraski]

IMHO, the enemy of the good is the better.
We can implement the binary-dir solution in no time, and it covers >95% of 
the problems easily, but instead we'll be discussing perfect solutions and 
end up doing nothing :)

My 2 agorot.

Zeev

At 08:03 03/05/2002, Markus Fischer wrote:
> Hi,
>
> but including other INI files at this stage is only of real
> advantage if we can also conditionally include it, no? Like,
> depending on the version too.
>
> How about looking for the version number in the filename too
> first, e.g.:
>
> php-apache-4.2.1.ini
> php-apache.ini
> php.ini
>
> ?
>
> This way it's even more less pain to have different versions
> installed.
>
> - Markus
>
>On Fri, May 03, 2002 at 06:54:41AM +0200, Stig S. Bakken wrote :
> > On Thu, 2002-05-02 at 21:18, Shane Caraveo wrote:
> > > Zeev Suraski wrote:
> > > > Does anybody have an opinion about this?
> > >
> > > Of course! ;)
> > >
> > > ini search order
> > > 1. PHP_BIN_DIR (\php\)
> > > 2. OS_DIR (\winnt\)
> > >
> > > To fix the ini issue we need more than just this.  The best I can come
> > > up with right now is:
> > >
> > > 1. implement bang line parsing.  This way, a specific script can define
> > > what ini file it wants to use.  It should only be available in CGI/CLI
> > > systems.
> > >
> > > 2. add support for -c to use filenames in addition to paths.  This way
> > > a single directory can contain multiple different config files.
> > >
> > > 3. have sapi modules (dll's) detect their directory so that server
> > > modules can correctly define where the ini file is for a particular
> > > installation.
> > >
> > > 4. For web servers, allow ini filenames to be php-domain.com.ini (or
> > > something like that) and have sapi modules look for that first if
> > > SERVER_NAME is available.
> > >
> > > 5. Implement 'override' ini files, which basicly behave the same as
> > > .htaccess.  Use of these is settable in the 'global' ini file.  They
> > > exist in the same directory as the script itself, and are read
> > > recursivly through the parent directory structure to some root (web
> > > root).  This of course would be cached in persistent systems, CGI/CLI
> > > users would probably not want to use this feature.
> > >
> > > Some of the above will rely on the OS security being configured
> > > correctly so that people cannot access each other's ini files, but that
> > > is not the responsibility of PHP to handle (though it could be
> > > documented to some extent).
> >
> > I think we should add:
> >
> > 6. Implement "include_ini" directive
> >
> > 7. Look for php-.ini first, and php.ini if not found (this may
> > double the disk activity, if that's acceptable).
> >
> >  - Stig
> >
> >
> > --
> > PHP Development Mailing List 
> > To unsubscribe, visit: http://www.php.net/unsub.php
>
>--
>Please always Cc to me when replying to me on the lists.
>GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc
>"Mind if I MFH ?" "What QA did you do on it?" "the usual?" "ah... none :)"


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] config.w32.h...registry configuration

[Pierre-Alain Joye]

> Seriously, being able to include other ini files is a great feature,
> especially for hosters who will then be able to set up site-wide config
> files that are included from per-vhost config files, etc.  You can have
> your cake and eat it too.
Sure :).
A way to make this functionnality on others server than apache is a must.

The php_xxx directive let admin makes a custom config per host. On IIS,
iplanet, there is actually no way to do it.

Just do not forget these servers :).

pa


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] config.w32.h...registry configuration

[Markus Fischer]

Hi,

but including other INI files at this stage is only of real
advantage if we can also conditionally include it, no? Like,
depending on the version too.

How about looking for the version number in the filename too
first, e.g.:

php-apache-4.2.1.ini
php-apache.ini
php.ini

?

This way it's even more less pain to have different versions
installed.

- Markus

On Fri, May 03, 2002 at 06:54:41AM +0200, Stig S. Bakken wrote : 
> On Thu, 2002-05-02 at 21:18, Shane Caraveo wrote:
> > Zeev Suraski wrote:
> > > Does anybody have an opinion about this?
> > 
> > Of course! ;)
> > 
> > ini search order
> > 1. PHP_BIN_DIR (\php\)
> > 2. OS_DIR (\winnt\)
> > 
> > To fix the ini issue we need more than just this.  The best I can come 
> > up with right now is:
> > 
> > 1. implement bang line parsing.  This way, a specific script can define 
> > what ini file it wants to use.  It should only be available in CGI/CLI 
> > systems.
> > 
> > 2. add support for -c to use filenames in addition to paths.  This way
> > a single directory can contain multiple different config files.
> > 
> > 3. have sapi modules (dll's) detect their directory so that server 
> > modules can correctly define where the ini file is for a particular 
> > installation.
> > 
> > 4. For web servers, allow ini filenames to be php-domain.com.ini (or 
> > something like that) and have sapi modules look for that first if 
> > SERVER_NAME is available.
> > 
> > 5. Implement 'override' ini files, which basicly behave the same as 
> > .htaccess.  Use of these is settable in the 'global' ini file.  They 
> > exist in the same directory as the script itself, and are read 
> > recursivly through the parent directory structure to some root (web 
> > root).  This of course would be cached in persistent systems, CGI/CLI 
> > users would probably not want to use this feature.
> > 
> > Some of the above will rely on the OS security being configured 
> > correctly so that people cannot access each other's ini files, but that 
> > is not the responsibility of PHP to handle (though it could be 
> > documented to some extent).
> 
> I think we should add:
> 
> 6. Implement "include_ini" directive
> 
> 7. Look for php-.ini first, and php.ini if not found (this may
> double the disk activity, if that's acceptable).
> 
>  - Stig
> 
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php

-- 
Please always Cc to me when replying to me on the lists.
GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc
"Mind if I MFH ?" "What QA did you do on it?" "the usual?" "ah... none :)"

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] config.w32.h...registry configuration

[Stig S. Bakken]

On Thu, 2002-05-02 at 21:18, Shane Caraveo wrote:
> Zeev Suraski wrote:
> > Does anybody have an opinion about this?
> 
> Of course! ;)
> 
> ini search order
> 1. PHP_BIN_DIR (\php\)
> 2. OS_DIR (\winnt\)
> 
> To fix the ini issue we need more than just this.  The best I can come 
> up with right now is:
> 
> 1. implement bang line parsing.  This way, a specific script can define 
> what ini file it wants to use.  It should only be available in CGI/CLI 
> systems.
> 
> 2. add support for -c to use filenames in addition to paths.  This way
> a single directory can contain multiple different config files.
> 
> 3. have sapi modules (dll's) detect their directory so that server 
> modules can correctly define where the ini file is for a particular 
> installation.
> 
> 4. For web servers, allow ini filenames to be php-domain.com.ini (or 
> something like that) and have sapi modules look for that first if 
> SERVER_NAME is available.
> 
> 5. Implement 'override' ini files, which basicly behave the same as 
> .htaccess.  Use of these is settable in the 'global' ini file.  They 
> exist in the same directory as the script itself, and are read 
> recursivly through the parent directory structure to some root (web 
> root).  This of course would be cached in persistent systems, CGI/CLI 
> users would probably not want to use this feature.
> 
> Some of the above will rely on the OS security being configured 
> correctly so that people cannot access each other's ini files, but that 
> is not the responsibility of PHP to handle (though it could be 
> documented to some extent).

I think we should add:

6. Implement "include_ini" directive

7. Look for php-.ini first, and php.ini if not found (this may
double the disk activity, if that's acceptable).

 - Stig


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] config.w32.h...registry configuration

[Stig S. Bakken]

On Thu, 2002-05-02 at 19:07, Preston L. Bannister wrote:
> From: Andi Gutmans [mailto:[EMAIL PROTECTED]]
> > 
> > At 14:44 02/05/2002 +0300, Zeev Suraski wrote:
> > >At 14:00 02/05/2002, [EMAIL PROTECTED] wrote:
> > >>On Thu, 2 May 2002, Zeev Suraski wrote:
> > >>
> > >> > At 13:36 02/05/2002, [EMAIL PROTECTED] wrote:
> > >> > >Some hosters use this feature to have different settigns for different
> > >> > >customers...
> > >> >
> > >> > Do you know this for a fact, or is this an estimate?
> > >>
> > >>This is a fact, some hoster here in .nl uses it.
> > >
> > >Ok then, perhaps we should have an .ini setting for it? :)
> > >
> > >The only two options I see, in that case are:
> > >
> > >- Add the binary path to the 3 existing lookup places
> > >- Add a configuration option that would determine whether CWD would be 
> > >used, or the binary path would be used.
> > >
> > >I lean towards option #2 myself...
> > >
> > 
> > How about if we don't have a php.in in CWD we fall back to where php.exe is 
> > located?
> 
> On second thought we *can* have both backwards compatibility AND 
> a default PHP installation that is more secure.
> 
> The approach is simple:
> 
> Load php.ini from PHP_CONFIG_FILE_PATH (unix) or the same directory
> as php.exe (Win32).  Do *not* search CWD.  
> 
> Add an "include" directive to the INI file.  Looking at the PHP
> implementation it looks like this could be a psuedo-setting with an
> on_modify function that loads as an INI file using the value as a
> file name.  So sites that *want* to load from CWD would add:
> 
> [PHP]
> include_ini = ./php.ini
> 
> So sites that want to be less secure have make the above entry once
> in the site's global php.ini.  It is a good thing to require action
> and thought on the part of the site to become less secure :).

Edin and I were discussing ini files on IRC last night and the same idea
came up.  With the exact same syntax too, actually.  This is divine
proof that the include_ini is good and must be implemented. :-)

Seriously, being able to include other ini files is a great feature,
especially for hosters who will then be able to set up site-wide config
files that are included from per-vhost config files, etc.  You can have
your cake and eat it too.

 - Stig


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] config.w32.h...registry configuration

[Shane Caraveo]

Zeev Suraski wrote:
> On Thu, 2 May 2002, Shane Caraveo wrote:
> 
> 
>>#4 is realy needed for systems running virtual servers under IIS.  While 
>>you can configure ini in the registry, it's a pain, especially if you 
>>want to give users access to edit their own ini file, or you want 
>>different extensions loaded for different servers that run under 
>>seperate dllhosts.
> 
> 
> IMHO the registry is quite enough for that kind of configuration.
> 
> Zeev
> 
> 

 >
 > Why not write a nice configuration GUI which edits your registry
 > automatically? Sounds like a nice Windows project for someone on the 
list.
 >
 > Andi
 >

Sure, if you want to give all users access to registry (or you're 
willing to handle everyone's config change requests), and for those 
settings that cannot be overwritten per directory, all sites can be 
configured the same.

Shane



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] config.w32.h...registry configuration

[Zeev Suraski]

On Thu, 2 May 2002, Shane Caraveo wrote:

> #4 is realy needed for systems running virtual servers under IIS.  While 
> you can configure ini in the registry, it's a pain, especially if you 
> want to give users access to edit their own ini file, or you want 
> different extensions loaded for different servers that run under 
> seperate dllhosts.

IMHO the registry is quite enough for that kind of configuration.

Zeev


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] config.w32.h...registry configuration

[Andi Gutmans]

At 13:14 02/05/2002 -0700, Shane Caraveo wrote:
>Andi Gutmans wrote:
> > Isn't this all a bit of an overkill?
> >
> > Andi
>
>#5 probably is, it's a nicety, but I think the other items are relatively 
>necessary unless you are dependent entirely on Apache, which provides 
>extensive configurability.
>
>#1 would allow scripts that only are used on 'command line' to be better 
>configured with seperate ini files.

I really don't like #1.

>#2 gets rid of needing a bunch of directories for multiple ini files, and 
>is very handy for #4.

#2 makes sense.

>#3 should be done irregardless (if it isn't already done), otherwise 
>server plugins will only be able to use ini files located in the os 
>directory.  If you run both Apache and IIS on the same system, you may 
>well want different ini files for the two.  That could be accomplised by 
>different installations as long as the sapi module detects it's own directory.

Not sure how you see this exactly. Can you expand?


>#4 is realy needed for systems running virtual servers under IIS.  While 
>you can configure ini in the registry, it's a pain, especially if you want 
>to give users access to edit their own ini file, or you want different 
>extensions loaded for different servers that run under seperate dllhosts.

Why not write a nice configuration GUI which edits your registry 
automatically? Sounds like a nice Windows project for someone on the list.

Andi


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] config.w32.h...registry configuration

[Shane Caraveo]

Andi Gutmans wrote:
 > Isn't this all a bit of an overkill?
 >
 > Andi

#5 probably is, it's a nicety, but I think the other items are 
relatively necessary unless you are dependent entirely on Apache, which 
provides extensive configurability.

#1 would allow scripts that only are used on 'command line' to be better 
configured with seperate ini files.

#2 gets rid of needing a bunch of directories for multiple ini files, 
and is very handy for #4.

#3 should be done irregardless (if it isn't already done), otherwise 
server plugins will only be able to use ini files located in the os 
directory.  If you run both Apache and IIS on the same system, you may 
well want different ini files for the two.  That could be accomplised by 
different installations as long as the sapi module detects it's own 
directory.

#4 is realy needed for systems running virtual servers under IIS.  While 
you can configure ini in the registry, it's a pain, especially if you 
want to give users access to edit their own ini file, or you want 
different extensions loaded for different servers that run under 
seperate dllhosts.

Of course, preferably none of this should be necessary, thus another 
reason for my dislike of the ini file ;)

Shane


> 
> At 12:18 02/05/2002 -0700, Shane Caraveo wrote:
> 
>> Zeev Suraski wrote:
>>
>>> Does anybody have an opinion about this?
>>
>>
>> Of course! ;)
>>
>> ini search order
>> 1. PHP_BIN_DIR (\php\)
>> 2. OS_DIR (\winnt\)
>>
>> To fix the ini issue we need more than just this.  The best I can come 
>> up with right now is:
>>
>> 1. implement bang line parsing.  This way, a specific script can 
>> define what ini file it wants to use.  It should only be available in 
>> CGI/CLI systems.
>>
>> 2. add support for -c to use filenames in addition to paths.  This way
>> a single directory can contain multiple different config files.
>>
>> 3. have sapi modules (dll's) detect their directory so that server 
>> modules can correctly define where the ini file is for a particular 
>> installation.
>>
>> 4. For web servers, allow ini filenames to be php-domain.com.ini (or 
>> something like that) and have sapi modules look for that first if 
>> SERVER_NAME is available.
>>
>> 5. Implement 'override' ini files, which basicly behave the same as 
>> .htaccess.  Use of these is settable in the 'global' ini file.  They 
>> exist in the same directory as the script itself, and are read 
>> recursivly through the parent directory structure to some root (web 
>> root).  This of course would be cached in persistent systems, CGI/CLI 
>> users would probably not want to use this feature.
>>
>> Some of the above will rely on the OS security being configured 
>> correctly so that people cannot access each other's ini files, but 
>> that is not the responsibility of PHP to handle (though it could be 
>> documented to some extent).
>>
>> Shane
>>
>>
>>
>> -- 
>> PHP Development Mailing List 
>> To unsubscribe, visit: http://www.php.net/unsub.php
> 
> 
> 




-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] config.w32.h...registry configuration

[Andi Gutmans]

Isn't this all a bit of an overkill?

Andi

At 12:18 02/05/2002 -0700, Shane Caraveo wrote:
>Zeev Suraski wrote:
>>Does anybody have an opinion about this?
>
>Of course! ;)
>
>ini search order
>1. PHP_BIN_DIR (\php\)
>2. OS_DIR (\winnt\)
>
>To fix the ini issue we need more than just this.  The best I can come up 
>with right now is:
>
>1. implement bang line parsing.  This way, a specific script can define 
>what ini file it wants to use.  It should only be available in CGI/CLI systems.
>
>2. add support for -c to use filenames in addition to paths.  This way
>a single directory can contain multiple different config files.
>
>3. have sapi modules (dll's) detect their directory so that server modules 
>can correctly define where the ini file is for a particular installation.
>
>4. For web servers, allow ini filenames to be php-domain.com.ini (or 
>something like that) and have sapi modules look for that first if 
>SERVER_NAME is available.
>
>5. Implement 'override' ini files, which basicly behave the same as 
>.htaccess.  Use of these is settable in the 'global' ini file.  They exist 
>in the same directory as the script itself, and are read recursivly 
>through the parent directory structure to some root (web root).  This of 
>course would be cached in persistent systems, CGI/CLI users would probably 
>not want to use this feature.
>
>Some of the above will rely on the OS security being configured correctly 
>so that people cannot access each other's ini files, but that is not the 
>responsibility of PHP to handle (though it could be documented to some extent).
>
>Shane
>
>
>
>--
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] config.w32.h...registry configuration

[Shane Caraveo]

Zeev Suraski wrote:
> Does anybody have an opinion about this?

Of course! ;)

ini search order
1. PHP_BIN_DIR (\php\)
2. OS_DIR (\winnt\)

To fix the ini issue we need more than just this.  The best I can come 
up with right now is:

1. implement bang line parsing.  This way, a specific script can define 
what ini file it wants to use.  It should only be available in CGI/CLI 
systems.

2. add support for -c to use filenames in addition to paths.  This way
a single directory can contain multiple different config files.

3. have sapi modules (dll's) detect their directory so that server 
modules can correctly define where the ini file is for a particular 
installation.

4. For web servers, allow ini filenames to be php-domain.com.ini (or 
something like that) and have sapi modules look for that first if 
SERVER_NAME is available.

5. Implement 'override' ini files, which basicly behave the same as 
.htaccess.  Use of these is settable in the 'global' ini file.  They 
exist in the same directory as the script itself, and are read 
recursivly through the parent directory structure to some root (web 
root).  This of course would be cached in persistent systems, CGI/CLI 
users would probably not want to use this feature.

Some of the above will rely on the OS security being configured 
correctly so that people cannot access each other's ini files, but that 
is not the responsibility of PHP to handle (though it could be 
documented to some extent).

Shane



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] config.w32.h...registry configuration

[Shane Caraveo]

Preston L. Bannister wrote:
> From: Andi Gutmans [mailto:[EMAIL PROTECTED]]
> 
>>At 14:44 02/05/2002 +0300, Zeev Suraski wrote:
>>
>>>At 14:00 02/05/2002, [EMAIL PROTECTED] wrote:
>>>
On Thu, 2 May 2002, Zeev Suraski wrote:


>At 13:36 02/05/2002, [EMAIL PROTECTED] wrote:
>
>>Some hosters use this feature to have different settigns for different
>>customers...
>
>Do you know this for a fact, or is this an estimate?

This is a fact, some hoster here in .nl uses it.
>>>
>>>Ok then, perhaps we should have an .ini setting for it? :)
>>>
>>>The only two options I see, in that case are:
>>>
>>>- Add the binary path to the 3 existing lookup places
>>>- Add a configuration option that would determine whether CWD would be 
>>>used, or the binary path would be used.
>>>
>>>I lean towards option #2 myself...
>>>
>>
>>How about if we don't have a php.in in CWD we fall back to where php.exe is 
>>located?
> 
> 
> On second thought we *can* have both backwards compatibility AND 
> a default PHP installation that is more secure.
> 
> The approach is simple:
> 
> Load php.ini from PHP_CONFIG_FILE_PATH (unix) or the same directory
> as php.exe (Win32).  Do *not* search CWD.  
> 
> Add an "include" directive to the INI file.  Looking at the PHP
> implementation it looks like this could be a psuedo-setting with an
> on_modify function that loads as an INI file using the value as a
> file name.  So sites that *want* to load from CWD would add:
> 
> [PHP]
> include_ini = ./php.ini
> 
> So sites that want to be less secure have make the above entry once
> in the site's global php.ini.  It is a good thing to require action
> and thought on the part of the site to become less secure :).
>

Interesting idea.
It doesn't have to be less secure at all.  treat it just like .htaccess 
config parameters.  Only certain ini settings can be override the global 
ini settings.

Shane




-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] config.w32.h...registry configuration

[Preston L. Bannister]

From: Andi Gutmans [mailto:[EMAIL PROTECTED]]
> 
> At 14:44 02/05/2002 +0300, Zeev Suraski wrote:
> >At 14:00 02/05/2002, [EMAIL PROTECTED] wrote:
> >>On Thu, 2 May 2002, Zeev Suraski wrote:
> >>
> >> > At 13:36 02/05/2002, [EMAIL PROTECTED] wrote:
> >> > >Some hosters use this feature to have different settigns for different
> >> > >customers...
> >> >
> >> > Do you know this for a fact, or is this an estimate?
> >>
> >>This is a fact, some hoster here in .nl uses it.
> >
> >Ok then, perhaps we should have an .ini setting for it? :)
> >
> >The only two options I see, in that case are:
> >
> >- Add the binary path to the 3 existing lookup places
> >- Add a configuration option that would determine whether CWD would be 
> >used, or the binary path would be used.
> >
> >I lean towards option #2 myself...
> >
> 
> How about if we don't have a php.in in CWD we fall back to where php.exe is 
> located?

On second thought we *can* have both backwards compatibility AND 
a default PHP installation that is more secure.

The approach is simple:

Load php.ini from PHP_CONFIG_FILE_PATH (unix) or the same directory
as php.exe (Win32).  Do *not* search CWD.  

Add an "include" directive to the INI file.  Looking at the PHP
implementation it looks like this could be a psuedo-setting with an
on_modify function that loads as an INI file using the value as a
file name.  So sites that *want* to load from CWD would add:

[PHP]
include_ini = ./php.ini

So sites that want to be less secure have make the above entry once
in the site's global php.ini.  It is a good thing to require action
and thought on the part of the site to become less secure :).




-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] config.w32.h...registry configuration

[Andi Gutmans]

At 14:44 02/05/2002 +0300, Zeev Suraski wrote:
>At 14:00 02/05/2002, [EMAIL PROTECTED] wrote:
>>On Thu, 2 May 2002, Zeev Suraski wrote:
>>
>> > At 13:36 02/05/2002, [EMAIL PROTECTED] wrote:
>> > >Some hosters use this feature to have different settigns for different
>> > >customers...
>> >
>> > Do you know this for a fact, or is this an estimate?
>>
>>This is a fact, some hoster here in .nl uses it.
>
>Ok then, perhaps we should have an .ini setting for it? :)
>
>The only two options I see, in that case are:
>
>- Add the binary path to the 3 existing lookup places
>- Add a configuration option that would determine whether CWD would be 
>used, or the binary path would be used.
>
>I lean towards option #2 myself...
>

How about if we don't have a php.in in CWD we fall back to where php.exe is 
located?



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] config.w32.h...registry configuration

[Preston L. Bannister]

From: Zeev Suraski [mailto:[EMAIL PROTECTED]]
> 
> At 15:09 02/05/2002, [EMAIL PROTECTED] wrote:
> > > Ok then, perhaps we should have an .ini setting for it? :)
> >
> >So you want to add an .ini setting where the .ini file could be found?
> >That just doesn't make sense to me :)
> 
> That was a joke..
> 
> > > The only two options I see, in that case are:
> > >
> > > - Add the binary path to the 3 existing lookup places
> > > - Add a configuration option that would determine whether CWD would be
> > > used, or the binary path would be used.
> > >
> > > I lean towards option #2 myself...
> >
> >yeah, but it still doesn't make sense :)
> 
> It does (configuration option == configure option, not php.ini option)

Tricky :).

I'd suggest the default be to omit CWD from the php.ini search path.
This does break the compatibility for sites that use this feature.

If a site chooses to look for php.ini this is a security risk.
Better for the default to be secure.

If the site is on Unix and uses chroot() before PHP runs, then the
security risk may be eliminated.

If the site is on Windows and wants to allow customer-hosted PHP scripts
on a shared server ... this seems inherently risky in every case.

Eh.  Neither argument is especially compelling.

BTW, if you are going to look for php.ini in the current directory then
a feature like ASP's global.asa is interesting.  Instead of just checking
CWD you also check in each parent directory up to the application/web root.
Slightly less efficient, but this makes having common settings for an
application (in a directory sub-tree on the web) somewhat simpler.

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] config.w32.h...registry configuration

[Zeev Suraski]

At 15:09 02/05/2002, [EMAIL PROTECTED] wrote:
> > Ok then, perhaps we should have an .ini setting for it? :)
>
>So you want to add an .ini setting where the .ini file could be found?
>That just doesn't make sense to me :)

That was a joke..

> > The only two options I see, in that case are:
> >
> > - Add the binary path to the 3 existing lookup places
> > - Add a configuration option that would determine whether CWD would be
> > used, or the binary path would be used.
> >
> > I lean towards option #2 myself...
>
>yeah, but it still doesn't make sense :)

It does (configuration option == configure option, not php.ini option)

Zeev


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] config.w32.h...registry configuration

[Wez Furlong]

I'm in favour of looking for php.ini in the same dir as the executeable
module - as in the path part of GetModuleFileName(), so it will work for
DLL as well as EXE versions.

I'm a bit dubious of using the registry for configuring PHP, particularly
when multiple installations/versions are present; I'm not actively against
it, as it will no doubt prove useful to quite a few people, but personally,
I would not use it.

--Wez.

On 02/05/02, "Zeev Suraski" <[EMAIL PROTECTED]> wrote:
> Does anybody have an opinion about this?
> If we go for that solution, should we remove the CWD lookup?  My personal 
> belief is that we should, but it may have to do with my perception of what 
> this feature is useful for.  Other people may be using the CWD lookup for 
> different things.
> (Note:  it's been pointed out that the CWD lookup can be a potential 
> security risk, because it allows people to override php.ini in some shared 
> hosting environment setups, so it's another reason to replace it with the 
> path lookup)
> 
> Zeev
> 
> At 23:17 01/05/2002, Zeev Suraski wrote:
> >At 23:11 01/05/2002, Shane Caraveo wrote:
> >>That would only solve that particular situation, what about multiple 
> >>installations of the same version, or seperate configurations for the 
> >>same installation?
> >
> >We can have PHP look for php.ini in the directory where php.exe is 
> >located.  This would allow you to easily configure different INI settings 
> >for different versions.
> >That's kind of what I wanted to do years ago, but ended up making it look 
> >for php.ini in the CWD, which is not all that helpful.
> >
> >Zeev
> >
> >
> >--
> >PHP Development Mailing List 
> >To unsubscribe, visit: http://www.php.net/unsub.php
> 
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php




-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] config.w32.h...registry configuration

[derick]

On Thu, 2 May 2002, Zeev Suraski wrote:

> At 14:00 02/05/2002, [EMAIL PROTECTED] wrote:
> >On Thu, 2 May 2002, Zeev Suraski wrote:
> >
> > > At 13:36 02/05/2002, [EMAIL PROTECTED] wrote:
> > > >Some hosters use this feature to have different settigns for different
> > > >customers...
> > >
> > > Do you know this for a fact, or is this an estimate?
> >
> >This is a fact, some hoster here in .nl uses it.
> 
> Ok then, perhaps we should have an .ini setting for it? :)

So you want to add an .ini setting where the .ini file could be found? 
That just doesn't make sense to me :)

> The only two options I see, in that case are:
> 
> - Add the binary path to the 3 existing lookup places
> - Add a configuration option that would determine whether CWD would be 
> used, or the binary path would be used.
> 
> I lean towards option #2 myself...

yeah, but it still doesn't make sense :)

Derick

---
 Did I help you? Consider a gift:
  http://www.amazon.co.uk/exec/obidos/registry/SLCB276UZU8B
---
  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 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] config.w32.h...registry configuration

[Pierre-Alain Joye]

> At the risk of getting toasted out of the water... do any serious hosters
> use a Win32 enviroment to host on? (who would utilise this way of setting
> different settings for different clients)
Intranet applications using (d)com, mssql run on win NT/2K.

> Are there any poll's we could reference against of PHP users (on Win32
> enviroments) and what they use it for / any special features they utilise.
-Generates/import office document
-Managing others tools/application running on win32

pa


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] config.w32.h...registry configuration

[Zeev Suraski]

We're not necessarily talking about Win32...

Zeev

At 14:02 02/05/2002, Dan Hardiker wrote:
>At the risk of getting toasted out of the water... do any serious hosters
>use a Win32 enviroment to host on? (who would utilise this way of setting
>different settings for different clients)
>
>Are there any poll's we could reference against of PHP users (on Win32
>enviroments) and what they use it for / any special features they utilise.
>
>--
>Dan Hardiker [[EMAIL PROTECTED]]
>ADAM Software & Systems Engineer
>First Creative Ltd
>
> > At 13:36 02/05/2002, [EMAIL PROTECTED] wrote:
> >>Some hosters use this feature to have different settigns for different
> >>customers...
> >
> > Do you know this for a fact, or is this an estimate?
> >
> > Zeev
>
>
>
>--
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] config.w32.h...registry configuration

[Zeev Suraski]

At 14:00 02/05/2002, [EMAIL PROTECTED] wrote:
>On Thu, 2 May 2002, Zeev Suraski wrote:
>
> > At 13:36 02/05/2002, [EMAIL PROTECTED] wrote:
> > >Some hosters use this feature to have different settigns for different
> > >customers...
> >
> > Do you know this for a fact, or is this an estimate?
>
>This is a fact, some hoster here in .nl uses it.

Ok then, perhaps we should have an .ini setting for it? :)

The only two options I see, in that case are:

- Add the binary path to the 3 existing lookup places
- Add a configuration option that would determine whether CWD would be 
used, or the binary path would be used.

I lean towards option #2 myself...

Zeev


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] config.w32.h...registry configuration

[Dan Hardiker]

At the risk of getting toasted out of the water... do any serious hosters
use a Win32 enviroment to host on? (who would utilise this way of setting
different settings for different clients)

Are there any poll's we could reference against of PHP users (on Win32
enviroments) and what they use it for / any special features they utilise.

-- 
Dan Hardiker [[EMAIL PROTECTED]]
ADAM Software & Systems Engineer
First Creative Ltd

> At 13:36 02/05/2002, [EMAIL PROTECTED] wrote:
>>Some hosters use this feature to have different settigns for different
>>customers...
>
> Do you know this for a fact, or is this an estimate?
>
> Zeev



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] config.w32.h...registry configuration

[derick]

On Thu, 2 May 2002, Zeev Suraski wrote:

> At 13:36 02/05/2002, [EMAIL PROTECTED] wrote:
> >Some hosters use this feature to have different settigns for different
> >customers...
> 
> Do you know this for a fact, or is this an estimate?

This is a fact, some hoster here in .nl uses it.

Derick

---
 Did I help you? Consider a gift:
  http://www.amazon.co.uk/exec/obidos/registry/SLCB276UZU8B
---
  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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] config.w32.h...registry configuration

[Zeev Suraski]

At 13:36 02/05/2002, [EMAIL PROTECTED] wrote:
>Some hosters use this feature to have different settigns for different
>customers...

Do you know this for a fact, or is this an estimate?

Zeev


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] config.w32.h...registry configuration

[derick]

On Thu, 2 May 2002, Zeev Suraski wrote:

> Does anybody have an opinion about this?
> If we go for that solution, should we remove the CWD lookup?  My personal 
> belief is that we should, but it may have to do with my perception of what 
> this feature is useful for.  Other people may be using the CWD lookup for 
> different things.
> (Note:  it's been pointed out that the CWD lookup can be a potential 
> security risk, because it allows people to override php.ini in some shared 
> hosting environment setups, so it's another reason to replace it with the 
> path lookup)

Some hosters use this feature to have different settigns for different 
customers... you might be removing this for them in this case, which 
breaks BC...

Derick

> At 23:17 01/05/2002, Zeev Suraski wrote:
> >At 23:11 01/05/2002, Shane Caraveo wrote:
> >>That would only solve that particular situation, what about multiple 
> >>installations of the same version, or seperate configurations for the 
> >>same installation?
> >
> >We can have PHP look for php.ini in the directory where php.exe is 
> >located.  This would allow you to easily configure different INI settings 
> >for different versions.
> >That's kind of what I wanted to do years ago, but ended up making it look 
> >for php.ini in the CWD, which is not all that helpful.
> >
> >Zeev
> >
> >
> >--
> >PHP Development Mailing List 
> >To unsubscribe, visit: http://www.php.net/unsub.php
> 
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
> 

---
 Did I help you? Consider a gift:
  http://www.amazon.co.uk/exec/obidos/registry/SLCB276UZU8B
---
  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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] config.w32.h...registry configuration

[Zeev Suraski]

Does anybody have an opinion about this?
If we go for that solution, should we remove the CWD lookup?  My personal 
belief is that we should, but it may have to do with my perception of what 
this feature is useful for.  Other people may be using the CWD lookup for 
different things.
(Note:  it's been pointed out that the CWD lookup can be a potential 
security risk, because it allows people to override php.ini in some shared 
hosting environment setups, so it's another reason to replace it with the 
path lookup)

Zeev

At 23:17 01/05/2002, Zeev Suraski wrote:
>At 23:11 01/05/2002, Shane Caraveo wrote:
>>That would only solve that particular situation, what about multiple 
>>installations of the same version, or seperate configurations for the 
>>same installation?
>
>We can have PHP look for php.ini in the directory where php.exe is 
>located.  This would allow you to easily configure different INI settings 
>for different versions.
>That's kind of what I wanted to do years ago, but ended up making it look 
>for php.ini in the CWD, which is not all that helpful.
>
>Zeev
>
>
>--
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] [PATCH] RE: [PHP-DEV] config.w32.h...registry configuration

[Preston L. Bannister]

From: Zeev Suraski [mailto:[EMAIL PROTECTED]]
> 
> At 23:11 01/05/2002, Shane Caraveo wrote:
> >That would only solve that particular situation, what about multiple 
> >installations of the same version, or seperate configurations for the same 
> >installation?
> 
> We can have PHP look for php.ini in the directory where php.exe is 
> located.  This would allow you to easily configure different INI settings 
> for different versions.
> That's kind of what I wanted to do years ago, but ended up making it look 
> for php.ini in the CWD, which is not all that helpful.

Posted this earlier, but in case it got lost this is the patch to
load php.ini from the current module's directory.  

If we're running php.exe then php.ini will first be looked for in the 
same directory.

If php4ts.dll was loaded by another executable then the php.ini file 
is looked for first in the same directory as that executable.

The net result is very similar to Unix, in that php.ini is loaded from
the same directory as the PHP executable.  This is a good thing :).


Index: main/php_ini.c
===
RCS file: /repository/php4/main/php_ini.c,v
retrieving revision 1.85
diff -u -b -r1.85 php_ini.c
--- main/php_ini.c  19 Apr 2002 05:48:22 -  1.85
+++ main/php_ini.c  1 May 2002 20:35:06 -
@@ -226,19 +226,19 @@
php_ini_search_path = php_ini_path_override;
free_ini_search_path = 0;
} else {
-   char *default_location;
-   int free_default_location;
-
 #ifdef PHP_WIN32
-   default_location = (char *) emalloc(512);
+char sSearchPath[1024];
+char *default_location = sSearchPath;

-   if (!GetWindowsDirectory(default_location, 255)) {
-   default_location[0]=0;
-   }
-   free_default_location=1;
+/* Look in the same directory as the executable. */
+GetModuleFileName(0,sSearchPath,sizeof(sSearchPath)) || (sSearchPath[0] = 0);
+{ char* p = strrchr(sSearchPath,'\\'); if (p) *++p = 0; }
+
+/* Add the Windows base directory as well. */
+strncat(sSearchPath,";",sizeof(sSearchPath));
+{ int n = strlen(sSearchPath); 
+GetWindowsDirectory(sSearchPath+n,sizeof(sSearchPath)-n); }
 #else
-   default_location = PHP_CONFIG_FILE_PATH;
-   free_default_location=0;
+char *default_location = PHP_CONFIG_FILE_PATH;
 #endif
php_ini_search_path = (char *) 
emalloc(sizeof(".")+strlen(env_location)+strlen(default_location)+2+1);
free_ini_search_path = 1;
@@ -255,9 +255,6 @@
sprintf(php_ini_search_path, ".%c%s", 
ZEND_PATHS_SEPARATOR, default_location);
}
}
-   if (free_default_location) {
-   efree(default_location);
-   }
}
 
PG(safe_mode) = 0;

--
Preston L. Bannister
http://members.cox.net/preston.bannister/
pbannister on Yahoo Messenger



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] config.w32.h...registry configuration

[Zeev Suraski]

At 23:11 01/05/2002, Shane Caraveo wrote:
>That would only solve that particular situation, what about multiple 
>installations of the same version, or seperate configurations for the same 
>installation?

We can have PHP look for php.ini in the directory where php.exe is 
located.  This would allow you to easily configure different INI settings 
for different versions.
That's kind of what I wanted to do years ago, but ended up making it look 
for php.ini in the CWD, which is not all that helpful.

Zeev


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] config.w32.h...registry configuration

[Shane Caraveo]

Daniel Beulshausen wrote:
> At 11:41 01.05.2002 -0700, Shane Caraveo wrote:
> 
>> Daniel Beulshausen wrote:
>>
>>> At 11:19 01.05.2002 -0700, Shane Caraveo wrote:
>>>
>> > they should be changed to use the windows registry anyway...
>>
>>   Feel free to do it :)
>
>
>
> this isn't going to be a big task, i'll put it onto my todo.



 It's already done, been there for a long time.  php.ini values are 
 configurable via registry, and can be done on a per-domain basis.  
 It is kind of a pain to deal with configuration that way though.
>>>
>>>
>>> i'm not talking about the per directory stuff, these are mostly non 
>>> php.ini settings.
>>> things like PEAR_INSTALLDIR, PHP_BINDIR etc should be stored in the 
>>> registry IMO.
>>> daniel
>>
>>
>> Well, the specific example I saw was the extension dir, which is an 
>> ini setting.  I would argue that pear_installdir could also be an ini 
>> setting.  bindir does need some solution outside the ini file, maybe, 
>> but I think there could be some way to work around that.  The reason I 
>> am *kind of* arguing against using the registry for these is due to 
>> having multiple installations of PHP.  I currently have 6, 5 installs 
>> and my compiled version, so that I can test things.  Dealing with 
>> php.ini in that situation is bad enough, adding registry configuration 
>> on top of that will make it even a bigger pain.
> 
> 
> one could use the version string as a subkey, this would enable you to 
> use different php.inis for different versions.
> 
> daniel

That would only solve that particular situation, what about multiple 
installations of the same version, or seperate configurations for the 
same installation?  This is the reason I start to dislike the ini file 
all together.

Shane







-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] config.w32.h

[Andi Gutmans]

I also prefer configuration files over registry.

Andi

At 11:04 01/05/2002 -0700, Preston L. Bannister wrote:
>From: Daniel Beulshausen [mailto:[EMAIL PROTECTED]]
> >
> > At 18:35 01.05.2002 +0200, Sebastian Bergmann wrote:
> > >Daniel Beulshausen wrote:
> > > > do you mean constants like PHP_EXTENSION_DIR?
> > >
> > >   For instance, yes.
> > >
> > > > they should be changed to use the windows registry anyway...
> > >
> > >   Feel free to do it :)
> >
> > this isn't going to be a big task, i'll put it onto my todo.
>
>
>I'd rather strongly suggest this value not be in the registry.
>
>What happens in the case were two different applications are installed
>on the same machine, and both use PHP - but different versions and with
>different libraries?  You really don't want machine-global settings.
>
>This isn't a theoretical question! :)
>
>We will be using PHP in our application and need to be certain that
>any changes the customer makes to there global use of PHP does not
>crater out application.  We can get this assurance by using a local
>copy of PHP in our application, with a local "php.ini" file.
>
>Instead I'd suggest that the settings stay in php.ini, but that PHP
>look for php.ini first local to the installation of php.exe.
>
>I posted a (tested!) patch a few days back to do exactly this.
>
>--
>Preston L. Bannister
>http://members.cox.net/preston.bannister/
>pbannister on Yahoo Messenger
>
>--
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] config.w32.h...registry configuration

[Daniel Beulshausen]

At 11:41 01.05.2002 -0700, Shane Caraveo wrote:
>Daniel Beulshausen wrote:
>>At 11:19 01.05.2002 -0700, Shane Caraveo wrote:
>>
> > they should be changed to use the windows registry anyway...
>
>   Feel free to do it :)


this isn't going to be a big task, i'll put it onto my todo.
>>>
>>>
>>>It's already done, been there for a long time.  php.ini values are 
>>>configurable via registry, and can be done on a per-domain basis.  It is 
>>>kind of a pain to deal with configuration that way though.
>>
>>i'm not talking about the per directory stuff, these are mostly non 
>>php.ini settings.
>>things like PEAR_INSTALLDIR, PHP_BINDIR etc should be stored in the 
>>registry IMO.
>>daniel
>
>Well, the specific example I saw was the extension dir, which is an ini 
>setting.  I would argue that pear_installdir could also be an ini 
>setting.  bindir does need some solution outside the ini file, maybe, but 
>I think there could be some way to work around that.  The reason I am 
>*kind of* arguing against using the registry for these is due to having 
>multiple installations of PHP.  I currently have 6, 5 installs and my 
>compiled version, so that I can test things.  Dealing with php.ini in that 
>situation is bad enough, adding registry configuration on top of that will 
>make it even a bigger pain.

one could use the version string as a subkey, this would enable you to use 
different php.inis for different versions.

daniel

/*--
Daniel Beulshausen - [EMAIL PROTECTED]
Using PHP on Windows? http://www.php4win.com


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] config.w32.h

[Preston L. Bannister]

From: Daniel Beulshausen [mailto:[EMAIL PROTECTED]]
>
> At 18:35 01.05.2002 +0200, Sebastian Bergmann wrote:
> >Daniel Beulshausen wrote:
> > > do you mean constants like PHP_EXTENSION_DIR?
> >
> >   For instance, yes.
> >
> > > they should be changed to use the windows registry anyway...
> >
> >   Feel free to do it :)
>
> this isn't going to be a big task, i'll put it onto my todo.

From: Sebastian Bergmann [mailto:[EMAIL PROTECTED]]
>
> "Preston L. Bannister" wrote:
> > Instead I'd suggest that the settings stay in php.ini, but that PHP
> > look for php.ini first local to the installation of php.exe.
>
>   The settings we're talking about are not in php.ini.


Perhaps I misunderstood.

Are we talking about (for example) changing this value?

main\main.c(270):
STD_PHP_INI_ENTRY("extension_dir", PHP_EXTENSION_DIR, PHP_INI_SYSTEM, 
OnUpdateStringUnempty, extension_dir, php_core_globals,
core_globals)


Or these?

main\main.c(1000):
REGISTER_MAIN_STRINGL_CONSTANT("PEAR_EXTENSION_DIR", PHP_EXTENSION_DIR, 
sizeof(PHP_EXTENSION_DIR)-1, CONST_PERSISTENT | CONST_CS);
REGISTER_MAIN_STRINGL_CONSTANT("PHP_EXTENSION_DIR", PHP_EXTENSION_DIR, 
sizeof(PHP_EXTENSION_DIR)-1, CONST_PERSISTENT | CONST_CS);




-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] config.w32.h...registry configuration

[Shane Caraveo]

Daniel Beulshausen wrote:
> At 11:19 01.05.2002 -0700, Shane Caraveo wrote:
> 
> 
 > they should be changed to use the windows registry anyway...

   Feel free to do it :)
>>>
>>>
>>> this isn't going to be a big task, i'll put it onto my todo.
>>
>>
>> It's already done, been there for a long time.  php.ini values are 
>> configurable via registry, and can be done on a per-domain basis.  It 
>> is kind of a pain to deal with configuration that way though.
> 
> 
> i'm not talking about the per directory stuff, these are mostly non 
> php.ini settings.
> things like PEAR_INSTALLDIR, PHP_BINDIR etc should be stored in the 
> registry IMO.
> 
> daniel

Well, the specific example I saw was the extension dir, which is an ini 
setting.  I would argue that pear_installdir could also be an ini 
setting.  bindir does need some solution outside the ini file, maybe, 
but I think there could be some way to work around that.  The reason I 
am *kind of* arguing against using the registry for these is due to 
having multiple installations of PHP.  I currently have 6, 5 installs 
and my compiled version, so that I can test things.  Dealing with 
php.ini in that situation is bad enough, adding registry configuration 
on top of that will make it even a bigger pain.
Shane


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] config.w32.h

[Daniel Beulshausen]

At 11:19 01.05.2002 -0700, Shane Caraveo wrote:


>>> > they should be changed to use the windows registry anyway...
>>>
>>>   Feel free to do it :)
>>
>>this isn't going to be a big task, i'll put it onto my todo.
>
>It's already done, been there for a long time.  php.ini values are 
>configurable via registry, and can be done on a per-domain basis.  It is 
>kind of a pain to deal with configuration that way though.

i'm not talking about the per directory stuff, these are mostly non php.ini 
settings.
things like PEAR_INSTALLDIR, PHP_BINDIR etc should be stored in the 
registry IMO.

daniel

/*--
Daniel Beulshausen - [EMAIL PROTECTED]
Using PHP on Windows? http://www.php4win.com


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] config.w32.h

[Shane Caraveo]

>>
>> > they should be changed to use the windows registry anyway...
>>
>>   Feel free to do it :)
> 
> 
> this isn't going to be a big task, i'll put it onto my todo.
> 

It's already done, been there for a long time.  php.ini values are 
configurable via registry, and can be done on a per-domain basis.  It is 
kind of a pain to deal with configuration that way though.

Shane



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] config.w32.h

[Sebastian Bergmann]

"Preston L. Bannister" wrote:
> Instead I'd suggest that the settings stay in php.ini, but that PHP
> look for php.ini first local to the installation of php.exe.

  The settings we're talking about are not in php.ini.

-- 
  Sebastian Bergmann
  http://sebastian-bergmann.de/ http://phpOpenTracker.de/

  Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] config.w32.h

[Preston L. Bannister]

From: Daniel Beulshausen [mailto:[EMAIL PROTECTED]]
> 
> At 18:35 01.05.2002 +0200, Sebastian Bergmann wrote:
> >Daniel Beulshausen wrote:
> > > do you mean constants like PHP_EXTENSION_DIR?
> >
> >   For instance, yes.
> >
> > > they should be changed to use the windows registry anyway...
> >
> >   Feel free to do it :)
> 
> this isn't going to be a big task, i'll put it onto my todo.


I'd rather strongly suggest this value not be in the registry.

What happens in the case were two different applications are installed
on the same machine, and both use PHP - but different versions and with
different libraries?  You really don't want machine-global settings.

This isn't a theoretical question! :)  

We will be using PHP in our application and need to be certain that 
any changes the customer makes to there global use of PHP does not
crater out application.  We can get this assurance by using a local
copy of PHP in our application, with a local "php.ini" file.

Instead I'd suggest that the settings stay in php.ini, but that PHP
look for php.ini first local to the installation of php.exe.

I posted a (tested!) patch a few days back to do exactly this.

--
Preston L. Bannister
http://members.cox.net/preston.bannister/
pbannister on Yahoo Messenger

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] config.w32.h

[Daniel Beulshausen]

At 18:35 01.05.2002 +0200, Sebastian Bergmann wrote:
>Daniel Beulshausen wrote:
> > do you mean constants like PHP_EXTENSION_DIR?
>
>   For instance, yes.
>
> > they should be changed to use the windows registry anyway...
>
>   Feel free to do it :)

this isn't going to be a big task, i'll put it onto my todo.

> > for any other compile time configuration option i don't think that's
> > wise to do.
>
>   Well, not everyone needs all of the extensions we're currently building
>   per default.

as the built-in extensions don't require you to fetch external libraries, 
it doesn't hurt to build them.
i find it much more annoying if you can't be sure wether the 
distributed/used build supports extension x or y per default.

daniel

/*--
Daniel Beulshausen - [EMAIL PROTECTED]
Using PHP on Windows? http://www.php4win.com


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] config.w32.h

[Sebastian Bergmann]

Daniel Beulshausen wrote:
> do you mean constants like PHP_EXTENSION_DIR?

  For instance, yes.

> they should be changed to use the windows registry anyway...

  Feel free to do it :)

> for any other compile time configuration option i don't think that's 
> wise to do.

  Well, not everyone needs all of the extensions we're currently building
  per default.

-- 
  Sebastian Bergmann
  http://sebastian-bergmann.de/ http://phpOpenTracker.de/

  Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] config.w32.h

[Andi Gutmans]

Ignore my previous Email. I think it's fine..

Andi

At 17:44 01/05/2002 +0200, Sebastian Bergmann wrote:
>Daniel Beulshausen wrote:
> > what's the reason to rename the file?
>
>   As I pointed out in a previous posting, this way we could put
>   config.w32.h into .cvsignore and let it be "created" from a
>   config.w32.h.in file if it doesn't exist.
>
>   This way, people can configure their Win32 build.
>
>--
>   Sebastian Bergmann
>   http://sebastian-bergmann.de/ http://phpOpenTracker.de/
>
>   Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/
>
>--
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] config.w32.h

[Andi Gutmans]

At 19:20 29/04/2002 +0200, Sebastian Bergmann wrote:
>   As you may know, I worked a bit on config.w32.h recently.
>
>   I'd like to rename the file to config.w32.h.in and let MSVC rename
>   config.w32.h.in to config.w32.h, if config.w32.h does not yet exist.
>
>   Two questions:
>
> 1.) Is this okay?
>
> 2.) How do I do this? :-)


Is it really necessary?

Andi


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] config.w32.h

[Daniel Beulshausen]

At 17:44 01.05.2002 +0200, Sebastian Bergmann wrote:
>Daniel Beulshausen wrote:
> > what's the reason to rename the file?
>
>   As I pointed out in a previous posting, this way we could put
>   config.w32.h into .cvsignore and let it be "created" from a
>   config.w32.h.in file if it doesn't exist.
>
>   This way, people can configure their Win32 build.

do you mean constants like PHP_EXTENSION_DIR?
they should be changed to use the windows registry anyway...
for any other compile time configuration option i don't think that's wise 
to do.

daniel

/*--
Daniel Beulshausen - [EMAIL PROTECTED]
Using PHP on Windows? http://www.php4win.com


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] config.w32.h

[Sebastian Bergmann]

Daniel Beulshausen wrote:
> what's the reason to rename the file?

  As I pointed out in a previous posting, this way we could put
  config.w32.h into .cvsignore and let it be "created" from a
  config.w32.h.in file if it doesn't exist.

  This way, people can configure their Win32 build.

-- 
  Sebastian Bergmann
  http://sebastian-bergmann.de/ http://phpOpenTracker.de/

  Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] config.w32.h

[Sebastian Bergmann]

Joseph Tate wrote:
> 2.  I'd create a batch file that does the renaming, and then set it up 
> to run in a custom build step.  You can set those up through the 
> Custom Build tab in the Project settings dialog.

# Begin Source File

SOURCE=..\main\config.w32.h.in

# Begin Custom Build
InputPath=..\main\config.w32.h.in

"..\main\config.w32.h.in" : $(SOURCE) "$(INTDIR)" "$(OUTDIR)"
copy ..\main\config.w32.h.in ..\main\config.w32.h > nul 

# End Custom Build
# End Source File

  should do the trick, but doesn't.

-- 
  Sebastian Bergmann
  http://sebastian-bergmann.de/ http://phpOpenTracker.de/

  Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] config.w32.h

[Daniel Beulshausen]

At 09:32 01.05.2002 -0400, Joseph Tate wrote:
>1.  I think it's ok.
>
>2.  I'd create a batch file that does the renaming, and then set it up to
>run in a custom build step.  You can set those up through the Custom Build
>tab in the Project settings dialog.

what's the reason to rename the file?

daniel

>Joseph
>
> > -Original Message-
> > From: Sebastian Bergmann [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, April 29, 2002 1:20 PM
> > To: [EMAIL PROTECTED]
> > Subject: [PHP-DEV] config.w32.h
> >
> >
> >   As you may know, I worked a bit on config.w32.h recently.
> >
> >   I'd like to rename the file to config.w32.h.in and let MSVC rename
> >   config.w32.h.in to config.w32.h, if config.w32.h does not yet exist.
> >
> >   Two questions:
> >
> > 1.) Is this okay?
> >
> > 2.) How do I do this? :-)
> >
> > --
> >   Sebastian Bergmann
> >   http://sebastian-bergmann.de/ http://phpOpenTracker.de/
> >
> >   Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/
> >
> > --
> > PHP Development Mailing List 
> > To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>--
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php


/*--
Daniel Beulshausen - [EMAIL PROTECTED]
Using PHP on Windows? http://www.php4win.com


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] config.w32.h

[Joseph Tate]

1.  I think it's ok.

2.  I'd create a batch file that does the renaming, and then set it up to
run in a custom build step.  You can set those up through the Custom Build
tab in the Project settings dialog.

Joseph

> -Original Message-
> From: Sebastian Bergmann [mailto:[EMAIL PROTECTED]]
> Sent: Monday, April 29, 2002 1:20 PM
> To: [EMAIL PROTECTED]
> Subject: [PHP-DEV] config.w32.h
>
>
>   As you may know, I worked a bit on config.w32.h recently.
>
>   I'd like to rename the file to config.w32.h.in and let MSVC rename
>   config.w32.h.in to config.w32.h, if config.w32.h does not yet exist.
>
>   Two questions:
>
> 1.) Is this okay?
>
> 2.) How do I do this? :-)
>
> --
>   Sebastian Bergmann
>   http://sebastian-bergmann.de/ http://phpOpenTracker.de/
>
>   Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/
>
> --
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php