On 12 Jul 2011 15h23 WEST, appa@perusio.net wrote:

> On 12 Jul 2011 14h54 WEST, nginx-forum@nginx.us wrote:
>
>> hobson42 Wrote:
>>
>>>> Igor, how about using the current values of
>>> PHP_INI* variables inside
>>>> the definition e.g.:
>>>>
>>>>
>>> This is impossible. Think about what nginx does -
>>> It matches filenames
>>> to a mask and passes the request using CGI to the
>>> port defined on a match.
>>>
>>> There is no reason why Nginx should know the CGI
>>> server is php (It is
>>> only convention that php files end in .php) and no
>>> reason why it should
>>> be php
>>> either - it might be Ruby, Python, Erlang, or
>>> anything else you might
>>> use. Further there is no way it can determine
>>> which php.ini file it
>>> would have to read even if it could know it was a
>>> php configuration it
>>> had to find.
>>
>> Ian, I think you misunderstood me. I did not mean that nginx
>> should figure out the current value of PHP variable, but it should
>> allow to pass constructs like \${varname} into the environment, so
>> that the upstream FCGI manager, for example PHP-FPM, would then be
>> able to substitute variables accordingly. Eg:
>>
>> fastcgi_pass PHP_VALUE
>> "include_path=\${include_path}:/my/other/include/path";
>
> In your fastcgi_params file (or whatever you named it) do:
>
> fastcgi_param PHP_VALUE
> "include_path=\${include_path}:/my/other/include/path";

Make that:

fastcgi_param PHP_VALUE "include_path=${include_path}:/my/other/include/path";

Hmm, never tried that, using a variable. Don't know if the $ needs to
be escaped.

You'll have to try it.

--- appa


_______________________________________________
nginx mailing list
nginx@nginx.org
http://nginx.org/mailman/listinfo/nginx