I think Zig not having a way to "modify the environment map" is a good thing, personally. Global state should be avoided at all costs. If a downstream library's setting isn't exposed through a config struct, and can only be configured through environment variables, it was misdesigned.
That may be true from a purist perspective, but it goes against Zig's design principle of interoperability.
> Although Zig is independent of C, and, unlike most other languages, does not depend on libc, Zig acknowledges the importance of interacting with existing C code.
> Therefore, we do make a C call to store the env variables that are parsed
lol, what? This is definitely not the way you should be trying to do whatever this is trying to do.
I'll try to find it, and edit if I can, but I'll try to find the context for the sister thread discussing why Zig intentionally doesn't support setting env vars for a running process.
Yeah. This is some weird shit for launching multiple processes and having the first set env vars that the other then pick up.
I think I’d probably be forced to bitch slap a colleague if they designed applications like that.
So how do you picture designing a shell or an init process?
I probably should have qualified with “unless they have an extremely good reason for doing so”
That said. Applications likely to be using zdotenv are probably not what you’re talking about here and should not likely be setting env especially since setenv is “dangerous”.
The way you'd do that in Zig is by duplicating and providing that env map to the child process. You wouldn't modify the existing envmap.
You would fork first on POSIX systems.
I've written a shell in zig, you don't need to fork before building the new envmap