ENV SubTask Not Working as Expected

[jimdelois]

For the env sub-task of the exec task, this line has the effect of creating multiple, distinct commands - not the intended effect of adding an environment variable to a command. This works for simple commands like echo (as per the test), but does not work as expected for scripts that delegate execution to other commands. For example, this does not work when executing ./vendor/bin/behat, which ultimately calls through to php where the environment variables are then lost.

It does not work on Linux or Mac operating systems. Would there be a downside to removing the the semicolon?

[jimdelois]

My original description and identification of the issue was clumsy, at best. There are more cogent descriptions of the issue here: https://stackoverflow.com/questions/30180187/setting-an-environment-variable-on-same-line-as-program-execution-is-different-t#

Adding an export to each variable and maintaining the semicolon appears to resolve the issue for all execution patterns that I have attempted. E.g., echo $HELLO, HELLO=world; THERE=there; php -r "print '$HELLO $THERE';", etc.

PR incoming.

[siad007]

PR incoming.

👍

[siad007]

@jimdelois thanks for the contribution - we have to think about such a feature carefully as it could have some side effects
and maybe it is not always wanted to export the env, when it is just needed for the child process.

Try the following snipped:

<exec executable="sh" outputProperty="outputProperty">
    <arg value="-c"/>
    <arg value="export HELLO=hello; export WORLD=world; php -r &quot;var_dump(\$_ENV);&quot;"/>
</exec>
<echo msg="${outputProperty}"/>

[siad007]

@mrook I set this to needs discussion as it is not clear, how to go with such a feature. Do you have an idea, how complex this would become for all decisions? Should all exported vars be cleaned after execution? What else could be a side effect here?

[jimdelois]

@siad007 - Thanks for the update and temporary recommendation. For what it's worth, during the meanwhile I have been using my own Task to remove the semicolon, defined as:

<?php

// phpcs:ignore PSR1.Classes.ClassDeclaration
class EnvExec extends \ExecTask
{
    protected function buildCommand()
    {
        parent::buildCommand();
        $parts = explode('; ', $this->realCommand);
        $cmd = array_pop($parts);
        $parts = join(' ', $parts);
        $this->realCommand = $parts . ' ' . $cmd;
    }
}

This has allowed me to successfully pass in a shell variable to my Behat script as per Phing's debug output:

  [envexec] Current OS is Darwin
  [envexec] Setting environment variable: BEHAT_HOST=http://172.16.192.128:32768
  [envexec] Executing command: BEHAT_HOST=http://172.16.192.128:32768 ./vendor/bin/behat --colors

... using a target defined as:

<target name="test:at">
	<property name="behat.host" value="http://localhost:8080" />
	<echo msg="Running ATs against ${behat.host}" />
	<envexec executable="./vendor/bin/behat" checkreturn="true" logoutput="true" passthru="true">
		<arg value="--colors" />
		<env key="BEHAT_HOST" value="${behat.host}" />
	</envexec>
</target>

I am good for the time being - please let me know if I can contribute further.

[jimdelois]

What is the status of this? It seems it was accepted and then reverted, which is a poor way of making a bug appear resolved. Any updates?

[mrook]

Thanks for your interest Jim. This was fixed in #1419, but we did not tag that PR to this issue.

[jimdelois]

Thanks, @mrook . However, that PR doesn't address this bug or take in any changes from the PR I submitted. As I noted above, the issue is in using the semi colons without the export. The proposed solution was to either remove the semi colons or add an export for each one.

When I add the test case I've already provided to the master branch, it fails on Mac.

I will continue to use my workaround, noted above.

[jimdelois]

@mrook @siad007 - Would it be possible to re-open this issue since... absolutely none of it was addressed?

[mrook]

We'll take another look at it.

[mrook]

@jimdelois the two commits above should fix this for both platforms (unix/windows). If they don't, we'll re-open this issue.