3 ms·
> The most common misuse I see is changing env before forking a child: nobody has to do that, execve() lets you pass arbitrary envp to the new process without c
by boring_twenties 3y ago
> The most common misuse I see is changing env before forking a child: nobody has to do that, execve() lets you pass arbitrary envp to the new process without changing yours.
That's pretty much never what you would want. You want to set a single variable while inheriting the rest of the existing environment. In order to do that with execve() you would have to copy the existing environment first, yuck.
And you wouldn't use setenv() before forking anyway, you would do it after forking, in the child, before exec.
- Too 3y agoWhat is yuck about copying the existing environment first?
- boring_twenties 3y agoIt's a complete waste all around? Wasted cycles at runtime, wasted development time, and a bunch of unnecessary lines of code to read and debug later.
- Too 3y agoWasted lines is a syntax sugar problem. It can be solved in the language level. Python for example has dict destructuring where you can solve this in under 10 characters. You could also imagine wrapper functions to execv taking in modifications to env only, that it merges with the inherited env. Copying is something that happens anyway if you write to the environment after fork, due to the copy-on-write model used by forking. If you don’t need to edit the environment at all, one could imagine a pure inherit option used. Besides, what size is the environment variables anyway? There are many other bigger bottlenecks if you are launching processes frequent enough for this to matter.