Repository navigation
Environment.SetEnvironmentVariable() works differently to setenv() p/Invoke #30525
Description
I've been working on adding login shell support to PowerShell in PowerShell/PowerShell#10050.
One of the optimisations I've been trying to add is a short circuit at startup so we don't check for login twice.
The idea we settled on was to set an environment variable, which for the purposes of this issue looks like this:
static void DoPowerShellLogin()
{
if (Environment.GetEnvironmentVariable("ALREADY_CHECKED_LOGIN") != null)
{
return;
}
Environment.SetEnvironmentVariable("ALREADY_CHECKED_LOGIN", "1");
exec("/path/to/pwsh", new string[] { null });
}
[DllImport("libc")]
private static extern int exec(string path, string[] args);In the debugger, this successfully created the environment variable in the first pass, but on the other side of the exec call it wasn't defined.
I played with this a bit and eventually tried a direct invocation of the setenv syscall:
static void DoPowerShellLogin()
{
if (Environment.GetEnvironmentVariable("ALREADY_CHECKED_LOGIN") != null)
{
return;
}
setenv("ALREADY_CHECKED_LOGIN", "1", true);
exec("/path/to/pwsh", new string[] { null });
}
[DllImport("libc")]
private static extern int exec(string path, string[] args);
[DllImport("libc")]
private static extern int setenv(string name, string value, bool overwrite);And this now worked.
Most interestingly, before calling exec but after calling setenv, Environment.GetEnvironmentVariable("ALREADY_CHECKED_LOGIN") returned null.
I'm assuming this behaviour is by design, but I'm not really sure why it is the way it is; I certainly didn't expect setenv to work when Environment.SetEnvironmentVariable() didn't.
Activity
rjmholt commentedon Aug 8, 2019
Environment information:
MichalStrehovsky commentedon Aug 8, 2019
This is a known problem on Unix with no good solution: see e.g. dotnet/coreclr#635.
If you use
Environment.SetEnvironmentVariable, useProcess.Startto start the process. The environment variables you set on the managed side will be passed to the new process.If you want to use libc
exec, usesetenv. Basically, you need to stick to one thing (libc calls or managed APIs).rjmholt commentedon Aug 8, 2019
Ah didn't think to search coreclr; this is definitely a duplicate of https://github.com/dotnet/coreclr/issues/635.
In our case, the complicating factor is that there is no new process. Only an
execwith nofork.Thanks for linking that issue!