Non-Uppercase Environment Variables duplicated with an Uppercase version

[chrislake]

Whilst attempting to run cmd.exe to execute a batch file, where within we unset an environment variable, I found that the exec-maven-plugin duplicates any non-uppercased environment variables with an uppercased one. Example:

<plugin>
  <groupId>org.codehaus.mojo</groupId>
  <artifactId>exec-maven-plugin</artifactId>
  <version>3.1.0</version>
  <executions>
    <execution>
      <id>showproblem</id>
      <phase>validate</phase>
      <goals>
        <goal>exec</goal>
      </goals>
      <configuration>
        <executable>cmd.exe</executable>
        <commandlineArgs>/c dobuild.cmd</commandlineArgs>
      </configuration>
    </execution>
  </executions>
</plugin>

Running "mvn validate" shows:

[INFO] Scanning for projects...
[INFO]
[INFO] ----------------------< my:plugin >----------------------
[INFO] Building plugin 0.0.1
[INFO] --------------------------------[ jar ]---------------------------------
[INFO]
[INFO] --- exec-maven-plugin:3.1.0:exec (showproblem) @ plugin ---

>SET
AaA_TestVariable=This is already set
AAA_TESTVARIABLE=This is already set
ALLUSERSPROFILE=C:\ProgramData
ANT_HOME=C:\apps\apache-ant-1.10.12
BUILD_NUMBER=999
CLASSWORLDS_JAR="C:\apps\apache-maven-3.8.3\boot\plexus-classworlds-2.6.0.jar"
CLASSWORLDS_LAUNCHER=org.codehaus.plexus.classworlds.launcher.Launcher
CommonProgramFiles=C:\Program Files\Common Files
COMMONPROGRAMFILES=C:\Program Files\Common Files
COMMONPROGRAMFILES(X86)=C:\Program Files (x86)\Common Files
CommonProgramFiles(x86)=C:\Program Files (x86)\Common Files
COMMONPROGRAMW6432=C:\Program Files\Common Files
CommonProgramW6432=C:\Program Files\Common Files
COMSPEC=C:\WINDOWS\system32\cmd.exe
ComSpec=C:\WINDOWS\system32\cmd.exe
DRIVERDATA=C:\Windows\System32\Drivers\DriverData
DriverData=C:\Windows\System32\Drivers\DriverData
ERROR_CODE=0
GIT_LFS_PATH=C:\apps\Git LFS
HOMEDRIVE=C:
JAVACMD=C:\develop\.git-repos\JDK\windows\amd64\bin\java.exe
JAVA_HOME=C:\develop\.git-repos\JDK\windows\amd64
jvmConfig=\.mvn\jvm.config
JVMCONFIG=\.mvn\jvm.config
...
__PSLOCKDOWNPOLICY=0
__PSLockDownPolicy=0

>ECHO AaA_TestVariable = [This is already set]
AaA_TestVariable = [This is already set]

>SET AaA_TestVariable=

>ECHO AaA_TestVariable = [This is already set]
AaA_TestVariable = [This is already set]

>SET AaA_TestVariable=

>ECHO AaA_TestVariable = []
AaA_TestVariable = []
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  9.552 s
[INFO] Finished at: 2022-08-05T12:47:57+10:00
[INFO] ------------------------------------------------------------------------

We can workaround the problem as shown, by unsetting the variable twice, or unsetting it first in the POM and then unsetting it again once in the batch file, but I don't think the variables should be duplicated in the first place.

[wheezil]

👍 this is breaking our build in which maven calls msbuild, and then msbuild tries to insert the env vars into a case-insensitive set which then errors out for a duplicate :-(. The error comes out something like:
System.ArgumentException: Item has already been added. Key in dictionary: 'PROGRAMDATA' Key being added: 'ProgramData'
The MS-side of this is dotnet/msbuild#5726
Which they've pondered, but refused to fix because "it's hard".
So now I'm trying to understand, how we can make this work at all? Does anyone have a workaround? We cannot manually change all of our env vars, some of them seem to be set in the toolchain or by parts of the environment we have no control over.

[wheezil]

There is a fairly simple fix to ExtendedExecutor.launch()
First, squirrel away the env that comes with the ProcessBuilder:

    boolean isWindows = System.getProperty("os.name").toLowerCase().contains("win");
    Map<String,String> existingEnv = new TreeMap<>(String.CASE_INSENSITIVE_ORDER);

Second, remove any keys that already exist, case-insensitive fashion:

        if (isWindows && existingEnv.containsKey(key)) {
            pb.environment().remove(key);
        }

I shall endeavor to submit a patch

[wheezil]

Hmmmm, the simple fix doesn't actually work for MSBuild, which seems to want to re-add all of the env vars in their "natural" case, and this leads to the collision and error reported in https://developercommunity.visualstudio.com/t/Build-Error:-MSB6001-in-Maven-Build/10527486?sort=newest

The real problem is that CommandLineUtils.getSystemEnvVars() is UPPERCASING all of the env vars, and this confuses MSBuild when it sees the MixedCase equivalents.

[slawekjaranowski]

Maybe simply use System.getenv instead of magic from CommandLineUtils will be the best ...
I don't have access to windows in order to check it

[wheezil]

Yeah, the problem is that CommandLineUtils intentionally UPPERCASES on Windows, but this is a mistake

…

On Fri, May 10, 2024, 09:46 Slawomir Jaranowski ***@***.***> wrote: Maybe simply use System.getenv instead of magic from CommandLineUtils will be the best ... I don't have access to windows in order to check it — Reply to this email directly, view it on GitHub <#328 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADKXHCLZYYALEZNWQZUXDVLZBTTVZAVCNFSM55UTBTR2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMJQGQ4DGNBRGUYQ> . You are receiving this because you commented.Message ID: ***@***.***>

[slawekjaranowski]

I don't know why it is doing in this way ....

such implementations from plexus-utils / maven-shared-utils .... are used in many place and I see only in exec-m-p it is a problem

The question is that env name should be uppercased on windows at all, or should be used as is ...