5 ms·

> We removed the majority of setenv calls. It was mostly used when spawning processes Could someone elaborate this for a non-developer? Why would you use `sete

> We removed the majority of setenv calls. It was mostly used when spawning processes Could someone elaborate this for a non-developer? Why would you use `setenv` (which I assume is functionally similar to `export key=value`, but correctly me if I'm wrong) (extensively) for spawning processes?

fulafel 2y ago
Environment variables are per-process, but inherited by child processes (not system wide). So when you start other programs you often set up env vars for them, or clear env vars that were used by your parent process to not inadvertantly perturb the child's behaviour.
- bhawks 2y ago
  Yes the proper way to do that is execve, not by changing global variables in your parent process. https://man7.org/linux/man-pages/man2/execve.2.html https://man7.org/linux/man-pages/man2/execve.2.html Using setenv is mostly always a hack that relies on a bunch of assumptions that could easily change and be hard to debug.
  - ptsneves 2y ago
    Unless there is a fork exec family of syscalls are not child processes but the same process itself. Small detail but important because sometimes you really want a separate process altogether.
    - gpderetta 2y ago
      in that case you do not need setenv to pass values to the underlying process though. And if you are forking without immediately execv in a multithreaded program, setenv is the last of your problems. edit: what's probably happening is that execve is four or five abstraction layers deeper (possibly in a third party dependency) than where the env variable need to be set without a clean way to pass the values through.
  - fulafel 2y ago
    The likely scenarios I was thinking (setenv vs execve) would both be called in the child process after fork. But of course here we get to the fascinating world of fork interactions with threads, and you could even have one thread fork()ing while another thread is doing a setenv().
- thrdbndndn 2y ago
  Regardless of whether it's a hack, my broader question is: is it common in Linux to manipulate environment variables on the fly for a process or program? I primarily use Windows, both as an end-user and an amateur programmer. From my experience, most programs on Windows don’t do this. If parameters are needed, they’re usually passed as arguments, while environment variables are used for more permanent settings, like %PATH%.
  - izacus 2y ago
    Yes, the fact that the original article exists shows that it's common :)
  - johannes1234321 2y ago
    PATH is a good example why steam does this: Steam is a program to launch a wide variety of other programs, which it doesn't fully control. Those programs (games) may do anything including launching further programs (utilities), so steam may set PATH so that the game finds those utilities. It can also be a way to pass license information or other configuration settings.
    - Tobu 2y ago
      Looks like the Steam team moved to control spawning and do execvpe. I would like to see at least in-process environment modification discouraged. Rust is dealing with the issue by considering getenv unsafe when coming through C, but getting rid of the read side is much harder than the write side.
  - jpk 2y ago
    One thing to note about command line arguments on Linux is, any user can typically inspect `/proc/{pid}/cmdline` and get the full command line used to start the process. So if you pass secrets like API keys, passwords, etc, via an argument, they're visible to the rest of the system. However, if you put secrets into the environment of the child process, only the user that owns the child process can inspect `/proc/{pid}/environ`.
    - 2y ago

fulafel 2y ago

Environment variables are per-process, but inherited by child processes (not system wide). So when you start other programs you often set up env vars for them, or clear env vars that were used by your parent process to not inadvertantly perturb the child's behaviour.

bhawks 2y ago
Yes the proper way to do that is execve, not by changing global variables in your parent process. https://man7.org/linux/man-pages/man2/execve.2.html https://man7.org/linux/man-pages/man2/execve.2.html Using setenv is mostly always a hack that relies on a bunch of assumptions that could easily change and be hard to debug.
- ptsneves 2y ago
  Unless there is a fork exec family of syscalls are not child processes but the same process itself. Small detail but important because sometimes you really want a separate process altogether.
  - gpderetta 2y ago
    in that case you do not need setenv to pass values to the underlying process though. And if you are forking without immediately execv in a multithreaded program, setenv is the last of your problems. edit: what's probably happening is that execve is four or five abstraction layers deeper (possibly in a third party dependency) than where the env variable need to be set without a clean way to pass the values through.
- fulafel 2y ago
  The likely scenarios I was thinking (setenv vs execve) would both be called in the child process after fork. But of course here we get to the fascinating world of fork interactions with threads, and you could even have one thread fork()ing while another thread is doing a setenv().
thrdbndndn 2y ago
Regardless of whether it's a hack, my broader question is: is it common in Linux to manipulate environment variables on the fly for a process or program? I primarily use Windows, both as an end-user and an amateur programmer. From my experience, most programs on Windows don’t do this. If parameters are needed, they’re usually passed as arguments, while environment variables are used for more permanent settings, like %PATH%.
- izacus 2y ago
  Yes, the fact that the original article exists shows that it's common :)
- johannes1234321 2y ago
  PATH is a good example why steam does this: Steam is a program to launch a wide variety of other programs, which it doesn't fully control. Those programs (games) may do anything including launching further programs (utilities), so steam may set PATH so that the game finds those utilities. It can also be a way to pass license information or other configuration settings.
  - Tobu 2y ago
    Looks like the Steam team moved to control spawning and do execvpe. I would like to see at least in-process environment modification discouraged. Rust is dealing with the issue by considering getenv unsafe when coming through C, but getting rid of the read side is much harder than the write side.
- jpk 2y ago
  One thing to note about command line arguments on Linux is, any user can typically inspect `/proc/{pid}/cmdline` and get the full command line used to start the process. So if you pass secrets like API keys, passwords, etc, via an argument, they're visible to the rest of the system. However, if you put secrets into the environment of the child process, only the user that owns the child process can inspect `/proc/{pid}/environ`.
  - 2y ago