fix(system): use wrapper for local env when necessary#182
fix(system): use wrapper for local env when necessary#182water-sucks merged 3 commits intonix-community:mainfrom
Conversation
|
@Sporif I would really appreciate your input on this change, since you reported the issue as well. |
cf0f5c1 to
67eb3af
Compare
|
It now works perfectly for local and remote activation, thanks! I just had two small nits, feel free to ignore them. |
I think they might have disappeared or something? Don't see them at all. I'll just request you for review and you can post them as an actual review requesting changes :} |
Sorry, I forgot to press submit review 😅. |
67eb3af to
d787539
Compare
d787539 to
bd31c7f
Compare
All good! I'm gonna merge this since you have tested it a bit; I've also done some testing on my own end and everything seems to check out. |
The current wrapper for setting variables through SSH env var sanitation barriers works pretty well in that instance, but needed to be expanded to work with local systems so that it can pass through
sudo/other root escalation barriers as well, since those tend to sanitize the environment variables for the subprocess they run.As such, this PR adds tests for the now-exported shell wrapper builder, and makes all systems use it when environment variables need to be passed through these barriers. I added an extra method to inherit environment variables explicitly when necessary as well, although this does need to be done on a per-process and opt-in basis, since I do not want to risk breaking subcommand invariants when they are invoked through
sudo(i.e.sudorewrites the HOME of the process to be/root, so we shouldn't preserve that; things like that that are more of a hassle to maintain than just opting-in to env var preservation).Closes #180, for real this time hopefully.