php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #74986 Environment variables set via putenv are not accessible via parse_ini_*
Submitted: 2017-07-25 11:04 UTC Modified: 2017-07-26 05:24 UTC
Votes:1
Avg. Score:3.0 ± 0.0
Reproduced:0 of 0 (0.0%)
From: alan at aondra dot com Assigned:
Status: Open Package: *General Issues
PHP Version: 7.1.7 OS: Windows 7 Professional SP1 x64
Private report: No CVE-ID: None
View Developer Edit
 [2017-07-25 11:04 UTC] alan at aondra dot com 
Description:
------------
---
From manual page: http://www.php.net/function.parse-ini-file
---

In Windows environment, putenv does not make environment variables accessible to either of the functions parse_ini_string or parse_ini_file.

Sample on test site 3v4l.org works as expected, but fails in local Windows development environment.

Apache HTTPD 2.4.27
PHP 7.1.7 x64 TS

Test script:
---------------
<?php

putenv('FOO=bar');

var_dump(getenv('FOO'));

$str = <<<'EOF'
BAZ=${FOO}
EOF;

$ini = parse_ini_string($str);

var_dump($ini);


Expected result:
----------------
string(3) "bar"
array(1) {
  ["BAZ"]=>
  string(3) "bar"
}


Actual result:
--------------
string(3) "bar"
array(1) {
  ["BAZ"]=>
  string(0) ""
}

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2017-07-25 16:29 UTC] alan at aondra dot com 
Actual results appear on a second Windows-based server running PHP 7.1.6 on Windows 7 Professional SP1 x64.

Expected results appear on Amazon EC2 instance running Amazon Linux AMI release 2017.03 with PHP 7.0.16 and Apache HTTPD 2.4.25.
 [2017-07-25 21:02 UTC] ab@php.net 
Thanks for the report. This feature is not documented, why is it expected behavior? Furthermore, it is not thread safe and therefore not portable. I'd tend to say it's a won't fix.

Thanks.
 [2017-07-25 22:02 UTC] requinix@php.net 
Not documented with parse_ini_file/string, but it's the same parser used for php.ini and support for environment variables is documented there.
http://php.net/manual/en/configuration.file.php#example-36
It is a handy feature to have in userland. I know I've used it myself.

I think the problem is because of how Apache deals with environment variables - by taking a copy at startup - combined with how PHP's environment variable getting and setting works in Windows. putenv() probably works fine by setting the variable at the process level (SetEnvironmentVariable), but reading it back from the SAPI won't work because Apache is still using the old list it had.

I suspect apache_setenv() instead of putenv() will work, and using $walk_to_top=true sounds like it might address the potential multithreading problem too.
 [2017-07-25 22:11 UTC] alan at aondra dot com 
"We didn't write it in the description, so it doesn't happen" could not be any more disingenuous of a response.

Fix and document it, or remove it entirely. Don't think me while saying it's likely to be a wontfix; it's just as disingenuous as the documentation comment.
 [2017-07-25 22:12 UTC] alan at aondra dot com 
Thanks to requinix, I'll give that a shot.
 [2017-07-26 05:24 UTC] ab@php.net 
@alan at aondra dot com, usage of undocumented features is not a reliable way of development, as for me ;) And you link to the page that doesn't document the feature. Now after @requinix's comment it looks like documented anyway. In further, you also can check bug #71607. If you want to shoot yourself in the foot - yes, use environment variables.

@requinix, it might be useful, but from the security and portability perspective it is quite poor. While we know some PHP software uses it officially, which is even more of disservice, as for me.

Thanks.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Thu Nov 21 19:01:29 2024 UTC