php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #60981 Shell environment inaccessible in tests
Submitted: 2012-02-05 18:50 UTC Modified: 2017-10-24 07:12 UTC
Votes:5
Avg. Score:4.6 ± 0.8
Reproduced:4 of 4 (100.0%)
Same Version:4 (100.0%)
Same OS:3 (75.0%)
From: david at davidfavor dot com Assigned:
Status: Open Package: Testing related
PHP Version: 5.3.10 OS: Ubuntu 11.10
Private report: No CVE-ID: None
Have you experienced this issue?
Rate the importance of this bug to you:

 [2012-02-05 18:50 UTC] david at davidfavor dot com
Description:
------------
Shell environment variables are not accessible via getenv() during tests.

Test script:
---------------
export MYSQL_TEST_PASSWD=...

make test TESTS=ext/mysql*/tests/001.phpt

Runs the mysql + mysqli connect tests and both are skipped.

Tests are skipped showing... (using password: NO)

Manually setting $passwd in connect.inc for both test sets runs all tests as expected.

So MYSQL_TEST_PASSWD is ignored.


Patches

run-tests.php.diff (last revision 2012-02-07 20:36 UTC by tyrael@php.net)

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2012-02-05 19:00 UTC] danielc@php.net
The environment variables need to be established in a scope available all shell scripts.  For example, them in the ~/.bashrc script of the user executing "make test".

Set the variables in ~/.bashrc
source ~/.bashrc
make test ....

The "source" step is only necessary in the first shell since the variables were not available when the shell was opened.  All future shells will have them.
 [2012-02-05 19:00 UTC] danielc@php.net
-Status: Open +Status: Feedback -Assigned To: +Assigned To: danielc
 [2012-02-06 20:12 UTC] david at davidfavor dot com
export var=foo is the same as sourcing a file that includes...
export var=foo

Problem is no shell environment is reaching the test scripts.

Please suggest a way to turn off clearing of the environment.
 [2012-02-06 20:12 UTC] david at davidfavor dot com
-Status: Feedback +Status: Assigned
 [2012-02-06 21:30 UTC] sixd@php.net
Try adding E to php.ini's variables_order.
 [2012-02-07 14:11 UTC] david at davidfavor dot com
That works...

So there are two doc errors...

#1) http://php.net/manual/en/reserved.variables.environment.php contains 
comments
that getenv() returns environment variables, independent of variable_orders 
setting. I've submitted a note to clarify this.

#2 http://php.net/manual/en/ini.core.php states variables_order default setting 
is "EGPCS", which is incorrect.

Both php.ini-production and php.ini-development contain "GPCS".

Best to fix both php.ini files so they match the docs.

Let me know if I should open another bug request for the doc change.

Thanks for helping me get this to work!
 [2012-02-07 14:18 UTC] tyrael@php.net
AFAIK getenv does work independently from variable_orders:
foo=bar php -d variables_order=GPC -r 'echo $_ENV["foo"];echo getenv("foo");'
outputs "bar" for me, so it works.

Tyrael
 [2012-02-07 14:30 UTC] tyrael@php.net
the problem is that the run-tests.php fetches the environment variables from $_ENV
http://svn.php.net/viewvc/php/php-src/trunk/run-tests.php?view=markup#l134
then passes the environment variables to the system_with_timeout call (which will 
proc_open using those environment variables).
so there is no documentation issue, only run-tests.php needs a change to either 
force the variable_orders to contain E(we could pass the --d variable_orders=EGPCS 
in the run-tests.php call in http://svn.php.net/viewvc/php/php-
src/trunk/Makefile.global) or changing run-tests.php to not use the $_ENV array 
for fetching all the environment vars.
 [2012-02-07 14:59 UTC] jpauli@php.net
I confirm that getenv() works regardless any .ini config.
It proxies to SAPI/system getenv()
 [2012-02-07 15:03 UTC] tyrael@php.net
'Both php.ini-production and php.ini-development contain "GPCS".'
the default value means that what is the value if you don't set it any way (having 
no php.ini or using php -n for example)
unfortunately the default values and our developer/production inis aren't in sync, 
I brought that issue up on the mailing list in the past:
http://www.mail-archive.com/internals@lists.php.net/msg52262.html
 [2012-02-07 15:20 UTC] david at davidfavor dot com
Seems like adding --d variable_orders=EGPCS to run-tests is the most elegant.

What the next step to arrange for this bug to be fixed?

Also I notice there are 4 failures in the mysqli tests. Let me know how to 
register as a developer with php.net and I'll figure these out and supply 
patches to fix the test suite.

Thanks.
 [2012-02-07 15:55 UTC] tyrael@php.net
"--d variable_orders=EGPCS to run-tests"
if you mean adding that to Makefile.global (the Makefile template, which will 
run run-tests.php when you execute make test) then yeah, it is an elegant 
solution, but I think it would be better to fix run-tests.php itself, so for 
those who call it directly (half of the core/qa people...) will also be fixed.
Pierre told me that there is no clean way to fetch all environment vars from a 
php script if $_ENV isn't populated (you could parse it from the output of 
phpinfo() but that would be error-prone and messy).
So I would propose calling another php instance and fetching the environment 
variables from there using shell_exec.
See the attached patch.
(If somebody has a better idea, I'm all for it.)
 [2012-02-07 15:57 UTC] tyrael@php.net
The following patch has been added/updated:

Patch Name: run-tests.php.diff
Revision:   1328630230
URL:        https://bugs.php.net/patch-display.php?bug=60981&patch=run-tests.php.diff&revision=1328630230
 [2012-02-07 17:08 UTC] david at davidfavor dot com
Just tested supplied patch and seems to work well.
 [2012-02-07 20:36 UTC] tyrael@php.net
The following patch has been added/updated:

Patch Name: run-tests.php.diff
Revision:   1328646999
URL:        https://bugs.php.net/patch-display.php?bug=60981&patch=run-tests.php.diff&revision=1328646999
 [2012-02-07 20:38 UTC] tyrael@php.net
I've just noticed that I got the patch reversed, I fixed it, now it should apply 
without the "Reversed (or previously applied) patch detected!  Assume -R? [n]" 
question.
 [2017-10-24 07:12 UTC] kalle@php.net
-Status: Assigned +Status: Open -Assigned To: danielc +Assigned To:
 
PHP Copyright © 2001-2019 The PHP Group
All rights reserved.
Last updated: Sat Apr 20 14:01:25 2019 UTC