Open mattimo opened 1 year ago
Just so I understand, what are you trying to accomplish by looking at the Env field? It's a read-only environment, so the contents shouldn't be particularly interesting as they won't change over time. I agree that the current behavior of the API is slightly confusing, and we should probably fix that, but I think you likely want a different kind of API.
I'm trying to "source" a shell script and use the exports from there to create an env that I can pass to exec.Cmd.
I thought it would be easiest to just loop through Runner.Vars or Runner.Env to create the slice that I can then put into exec.Cmd. I'd of couse have to copy all the "exported" Vars into Env first.
From the code I understood that Env should actually satisfy WriteEnviron once a sub shell was created so I was hoping that it was just a bug.
Then you should call Runner.Run
and then look at the Runner.Vars
field; Env
is generally read-only, so it might not contain all the vars that your sourced script defined.
I see. Thanks for the explanation! I tried this earlier with a subshell but the vars were also empty but I think I can just use the runner without a subshell and I should be fine for now.
The question if the subshell vars should be empty still remains for me though.
Yeah, you shouldn't need to use a subshell to source a script. I still agree that Env/Vars works a bit weird with subshells, and I'll leave this issue open for that.
Consider the following code
This prints
The documentation for
Subshell()
states the following:So I would have expected the runner from the subshell to include a copy of Env.
The same behavior is shown for Vars too. The interesting thing is that even when Running something in the runner
r
the behavior doesn't change.