3 ms·
The real skinny of it is that it’s in the name: “Environment”. If you’re calling setenv in the middle of your program, you fucked up. There are those things i
by wredue 3y ago
The real skinny of it is that it’s in the name: “Environment”.
If you’re calling setenv in the middle of your program, you fucked up.
There are those things in programming that should be extremely triggering to your “what the actual fuck?!” senses, and “setenv in the middle of runtime” is one of those things.
- kstrauser 3y agoTrue, but for every envvar a program reads, something called setenv on it originally. It’s not like no programs call setenv in the middle of runtime. Examples: - Shells - CI runner - Container launchers - IDEs
- tsukikage 3y agoThe child process's environment for these purposes is constructed without mutating its parent's environment - a copy is used - and before the child process actually runs the target code it was created to run. So there is no possibility of race between mutations to the environment and reads of the environment. If you are writing such a tool but doing something other than this, you are doing it wrong.
- DSMan195276 3y ago> but for every envvar a program reads, something called setenv on it originally That's not true, that's just misunderstanding how it works. `execve()` takes an entirely new copy of environment variables to give to the child, that's the "real" way to do it.
- stefan_ 3y agoNo, a process gets its environment variables from the operating system (just like argc, argv) before any code is ever executed and the majority never change them.
- ric2b 3y agoThen why does setenv even exist? Maybe that's the issue and it should be deprecated and throw compilation warnings?