`ENV` propagation broken when spawining process with `clear_env: true` on MSYS2

[straight-shoota]

The following snippet builds a crystal program that prints ENV["FOO"]? and then calls that program with clear_env: true and the FOO variable assigned:

File.write("env-var.cr", %(puts ENV["FOO"]?))

Process.run("crystal", ["build", "env-var.cr"])

Process.run(File.join(".", "env-var"), clear_env: true, env: {"FOO" => "BAR"}, output: :inherit)

This should print BAR. It does so on all platforms, except MSYS2 (both CLANGARM64 and UCRT64) where the output is empty.

It works as expected with clear_env: false.
When reading the environment variable with a system command works as well (both "cmd", ["/c", "echo %FOO%"] and "sh", ["-c", "echo $FOO"]).

It seems to be that just the Crystal program is unable to read the environment properly.

Running the Crystal program through "cmd", ["/c", ".\\env-var"] doesn't help either. In fact, it doesn't even pick up env vars set after in cmd with "cmd", ["/c", "set FOO=BAZ && .\\env-var"]. 😕

The spec for clear_env: true uses cmd /c set to validate the effect, so we didn't notice this before.

---

Add a 👍 reaction to issues you find important.

[HertzDevil]

The process is failing with exit code 0xC0000135 = STATUS_DLL_NOT_FOUND, because PATH doesn't exist, which means none of the Crystal runtime's dependent DLLs can be located.

I tried forwarding the current %PATH% or adding --static to the build arguments, both worked.

[straight-shoota]

Ah, that makes sense.

Using Process.capture would've caught that. 🤦
We should probably use that in the process spec suite as well for #17047

I suppose we can close this then.

FTR: The difference between MSVC and MSYS2 binaries is that the latter load some libraries such as gc.dll from /ucrt64/bin (or similar) which needs to be in PATH. For MSVC binaries we place custom dynamic libraries next to the executable, so they can be found without PATH.