OK, now I got similar error on a different project which does not even have EnvInject set. The project used standard 'set environment variables' setting to override PATH and it stopped working once EnvInject was installed. Original PATH setting has been used instead.

Additional side effect: on a Windows slave there is predefined environment variable named Path. When setting PATH=C:\Program Files\7-Zip;${PATH} as EnvInject setup, it results in both PATH and Path injected variables, where Path is original (without 7-Zip) and PATH contains 7-Zip. Anyway, the build later fails since apparently Windows checks Path and not PATH (or probably these two count as one and it depends on what order they are set).

As a workaround I have corrected EnvInject setup to set Path not PATH and it works. However, standard environment setup feature from Jenkins did not work this way, i.e. correctly expanded Path with the same setup as above (PATH=C:\Program Files\7-Zip;${PATH})

If I understand, there is an issue on Windows.
EnvInject plugin make a difference between PATH and Path, where it is the same thing on windows.
Is it all?

No.

At first, I don't understand why EnvInject distinguishes PATH from Path on Windows, when standard Jenkins variable setup implementation does not behave this way.

Secondly, the issue is also about installing EnvInject makes standard environment setup working incorrectly. I used to have jobs which added to PATH within standard 'set environment variables' and these are no longer applied, even though I have not enabled any EnvInject option in the project. It seems that installing EnvInject itself breaks the way Jenkins handles environment variables for the build (or at least PATH variable). This is true for Unix-based build as well.

To reproduce the issue:

• on the node set environment variable PATH
• create a new free style build and tie it on this node
• in the job check 'set environment variable' and add something to the PATH
• int the build step use shell step and run 'echo ${PATH}'
• notice that PATH does not contain modifications from standard settings

While I understand that this field is not part of EnvInject setup, I find it breaking since installing EnvInject is enough to break jobs that are set up like this (the jobs do not even need to have EnvInject configured).

I'm sorry for not getting back to you sooner.
From an Unix environment, I can't reproduce the problem.
Could you attach your job configuration file, maybe I missed something.

More information
1) EnvInject plugin distinguishes PATH from Path from Windows because it is written in Java and I don't take in consideration of that at the moment.

2) If you don't use EnvInject, nothing is modified.
It is not intrusive.
Therefore, I don't understand your remark

I have verified on a clean Jenkins installation that it works correctly indeed. It seems that there is some conflict with "Hudson setenv plugin". It was installed so long ago that I didn't remember it was a plugin; thought that setting environment was a Jenkins built-in. Clean Jenkins installation convinced me it's not.

Anyway, seems not to be a problem. Rather my configuration issue.

Turned out it was a configuration issue.