Allow null values in environment variables
MisinformedDNA opened this issue · comments
We are seeing nullability warnings since Command.EnvironmentVariables
is of type IReadOnlyDictionary<string, string> and not IReadOnlyDictionary<string, string?>.
I would expect it to be the latter since it maintains consistency with CLR types:
Environment.SetEnvironmentVariable accepts a nullable string as its value and Environment.GetEnvironmentVariable returns a nullable string.
Are you interested in a PR to fix this?
Specifically this may unlock the ability to unset an environment variable via CliWrap which is not currently possible. Consider this test program:
cat debug-boom.sh
#!/bin/sh
var=${BOOM-NA}
echo "BOOM IS $var"
The program can distinguish between empty, unset and set env var BOOM. Here is a session demonstrating that env
UNIX command can manipulate this environment.
$ env -u BOOM debug-boom.sh
BOOM IS NA
$ env BOOM="" debug-boom.sh
BOOM IS
$ env BOOM=1 debug-boom.sh
BOOM IS 1
Note that env
can also remove an environment variable even if it is set globally:
$ BOOM=1 env -u BOOM debug-boom.sh
BOOM IS NA
As far as I can tell this functionality is currently missing from CliWrap API. The user cannot remove the environment variable that is set globally. At best the user can set it to an empty value, which is not the same as removing it.
If we allowed the Environment to have null string values, we could potentially interpret nulls as instructions to remove environment variables set globally.
Note that https://docs.microsoft.com/en-us/dotnet/api/system.environment.setenvironmentvariable?view=net-5.0 currently treats empty values and nulls identically, and it treats them as instructions to remove. This is different from current behavior of CliWrap that treats empty values as explicit as-is values and passes them down.
I think this actually requires dotnet/runtime#34446 to be fixed
Sounds good to me. You can send a PR.
Let's treat null
values as instruction to remove. Keep empty strings as is.