6 ms·
That is an unpopular opinion for the simple reason that some programs do in fact need to set envvars, particularly programs that will start child processes.
by usrbinbash 3y ago
That is an unpopular opinion for the simple reason that some programs do in fact need to set envvars, particularly programs that will start child processes.
- MrBuddyCasino 3y agoThat is still possible using the java.lang.ProcessBuilder API: you can launch a child process and give it a modified environment, but just at launch time. This side-steps the issue.
- ryan-c 3y agoPrograms that need to set environment variables for child processes should use `execvpe` or `execle`.
- account42 3y agoOr posix_spawn / posix_spawnp.
- badsectoracula 3y agoOr programs that rely on libraries that for some unfathomable reason expose some functionality only via environment variables without an API. looks at SDL
- account42 3y agoThere is SDL_SetHint [0] which doesn't modify the environment but instead changes the value internally to SDL only. [0] https://wiki.libsdl.org/SDL2/SDL_SetHint https://wiki.libsdl.org/SDL2/SDL_SetHint
- badsectoracula 3y agoThat is SDL2, what i had in mind is SDL1 - but also the SDL1-on-SDL2 implementation which had some SDL2-specific extras (for things like scaling).
- pajko 3y agoNope, execve() and friends ending in 'e' accept a pointer to a completely new set of environment variables, no need to do setenv. Windows has _execve() too.
- usrbinbash 3y agoThe fact that there is an alternative doesn't change the fact that a lot of software relies on the worse method to work.
- rerdavies 3y agoA lot of software doesn't modify the environment when exec-ing.
- usrbinbash 3y agoSo? A lot of software doesn't use file compression, should we remove these libraries?
- naniwaduni 3y agoIt makes it a pretty silly idea to invite people writing new programs in a new language to use that method, though.
- deleted 3y ago[deleted]
- kevincox 3y agoI think the probably is really that there are 2 times where you should be setting env vars 99% of the time. 1. Right after program startup before any threads are spawned. 2. After a fork before an exec. In both cases it can be known that no threads are running. (Ok, for 1 it can actually be non-trivial if you have code before main or if you call functions that spawn helper threads, but let's assume that you can know this). However no languages actually have ways to enforce this. So the APIs can be called at any time and are huge footguns. I think that the proposed improvement of `getenv_s` is great. It is cheap and easy to use, then software can slowly migrate off of the less safe stuff. You can imagine that if libc stopped using `getenv` internally most of this problem would be solved.
- Blikkentrekker 3y agoNo, in many cases one needs to set them interactively. Consider for instance something as simple a implementing a shell. Such a program needs to be able to set the environment based on user interaction and this change needs to show up in /proc/$pid/env.
- __david__ 3y agoWhy does a shell need its current environment to be visible in /proc/$pid/env (as opposed to just its initial environment)?
- Blikkentrekker 3y agoBecause the specification of the POSIX shell says that `export` changes the current environment of the running process, not just of any newly started processes. This is useful to recognize various processes I suppose. I have written code that scans the environment of processes to find particular processes and group them together.
- rerdavies 3y agoIf you need to set environment variables for child processes in a thread-safe manner, use execvpe or execle.