4 ms·

Unpopular opinion: Neither Go's os.Setenv nor Rust's std::env::set_var() should exist. I was pleased to find that Java only has System.getEnv(), but not a sette

Unpopular opinion: Neither Go's os.Setenv nor Rust's std::env::set_var() should exist. I was pleased to find that Java only has System.getEnv(), but not a setter.

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 ago
  That 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 ago
  Programs that need to set environment variables for child processes should use `execvpe` or `execle`.
  - account42 3y ago
    Or posix_spawn / posix_spawnp.
- badsectoracula 3y ago
  Or 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 ago
    There 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 ago
      That 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 ago
  Nope, 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 ago
    The 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 ago
      A lot of software doesn't modify the environment when exec-ing.
      - usrbinbash 3y ago
        So? A lot of software doesn't use file compression, should we remove these libraries?
    - naniwaduni 3y ago
      It 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 ago
  I 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 ago
    No, 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 ago
      Why does a shell need its current environment to be visible in /proc/$pid/env (as opposed to just its initial environment)?
      - Blikkentrekker 3y ago
        Because 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 ago
  If you need to set environment variables for child processes in a thread-safe manner, use execvpe or execle.
jeroenhd 3y ago
I think there are good reasons for Setenv and set_var to exist, but if they are implemented, they shouldn't be wrappers around POSIX' shitty API and implement their own environment variable system instead (one of which the initial variables are possibly initialised by a call to getenv to make them compatible). There's no reason why these languages need to restrict themselves the same way C does.
- MrBuddyCasino 3y ago
  The bug in Golang was because DNS lookups interact with the C library, which looks up environment variables. As long as everything happens in Goland, there is no problem - but this is simply not good enough.
  - jeroenhd 3y ago
    Go makes the assumption that the DNS lookups are thread-safe, but it doesn't have that guarantee (or the C library is spec-incompliant, but I doubt that). It's still something Go can fix. You can't fix C libraries loaded into Go programs (i.e. and external library calling C's setenv, or I suppose explicit FFI calls by the user), but Go can be responsible for the APIs it calls itself. That may necessitate writing a thread-safe alternative for DNS lookups, or documenting and/or adding compile time warnings that threaded programs doing DNS lookups will just crash sometimes, but the language's standard library can still make it much harder for developers to write buggy code.
    - MrBuddyCasino 3y ago
      My impression is that this was Golang's plan from the start - this is why they didn't want to use the C stdlib at all, issuing the Kernel syscalls directly from the Golang runtime. A good idea, but then they had to backpedal to solve issues such as DNS resolution respecting certain OS settings, and this bug is a symptom of that.
      - fch42 3y ago
        Yes, there are certain things in UNIX which _are_ part of the standard (POSIX / IEEE1003) but _aren't_ usually implemented as system calls. Name lookups (whether user identities or network resources) are the biggest chunk of these. You have a "choice" as a user/programmer here. Say, the existing name lookup interfaces in most libc implementations don't do DNS-over-HTTP (DoH); you can implement that yourself and just use the addresses returned by your library/package where the system calls ... want addresses. If you have the go stance, go all the way. Don't say "the C runtime is sh*te but I really really really want that one particular teensy tiny bit of it could someone somewhere somehow please do something to make it a little less sh*te". Legacy baggage is a burden and backwards compatibility shackles you. The C/Unix interfaces are full of this, and with the hindsight of 50 years noone today, not even "C programmers", would implement them all the same way again. But that doesn't mean their behaviour can be arbitrarily changed.
grodriguez100 3y ago
I fully agree with your unpopular opinion.
crabbone 3y ago
This is a bizarre take... Programmers have to deal with a lot of badly written programs all of the time. You'd need this functionality to either debug a program that responds differently to different values of environment variables, or to control it, because, maybe it's the only reasonable way to do so. It's OK to say that programmers shouldn't rely on this functionality ideally, but, for practical reasons, this functionality is needed. Same happens in "pure" functional languages, for example, when you need to debug programs in such languages interactively, and struggle to create the program state that reproduces the problem, or, in some extreme cases, due to I/O being "impure" even struggle to output diagnostic information.

Unpopular opinion: Neither Go's os.Setenv nor Rust's std::env::set_var() should exist. I was pleased to find that Java only has System.getEnv(), but not a setter.

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 ago
That 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 ago
Programs that need to set environment variables for child processes should use `execvpe` or `execle`.
- account42 3y ago
  Or posix_spawn / posix_spawnp.
badsectoracula 3y ago
Or 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 ago
  There 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 ago
    That 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 ago
Nope, 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 ago
  The 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 ago
    A lot of software doesn't modify the environment when exec-ing.
    - usrbinbash 3y ago
      So? A lot of software doesn't use file compression, should we remove these libraries?
  - naniwaduni 3y ago
    It 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 ago
I 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 ago
  No, 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 ago
    Why does a shell need its current environment to be visible in /proc/$pid/env (as opposed to just its initial environment)?
    - Blikkentrekker 3y ago
      Because 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 ago
If you need to set environment variables for child processes in a thread-safe manner, use execvpe or execle.

jeroenhd 3y ago

I think there are good reasons for Setenv and set_var to exist, but if they are implemented, they shouldn't be wrappers around POSIX' shitty API and implement their own environment variable system instead (one of which the initial variables are possibly initialised by a call to getenv to make them compatible). There's no reason why these languages need to restrict themselves the same way C does.

MrBuddyCasino 3y ago
The bug in Golang was because DNS lookups interact with the C library, which looks up environment variables. As long as everything happens in Goland, there is no problem - but this is simply not good enough.
- jeroenhd 3y ago
  Go makes the assumption that the DNS lookups are thread-safe, but it doesn't have that guarantee (or the C library is spec-incompliant, but I doubt that). It's still something Go can fix. You can't fix C libraries loaded into Go programs (i.e. and external library calling C's setenv, or I suppose explicit FFI calls by the user), but Go can be responsible for the APIs it calls itself. That may necessitate writing a thread-safe alternative for DNS lookups, or documenting and/or adding compile time warnings that threaded programs doing DNS lookups will just crash sometimes, but the language's standard library can still make it much harder for developers to write buggy code.
  - MrBuddyCasino 3y ago
    My impression is that this was Golang's plan from the start - this is why they didn't want to use the C stdlib at all, issuing the Kernel syscalls directly from the Golang runtime. A good idea, but then they had to backpedal to solve issues such as DNS resolution respecting certain OS settings, and this bug is a symptom of that.
    - fch42 3y ago
      Yes, there are certain things in UNIX which _are_ part of the standard (POSIX / IEEE1003) but _aren't_ usually implemented as system calls. Name lookups (whether user identities or network resources) are the biggest chunk of these. You have a "choice" as a user/programmer here. Say, the existing name lookup interfaces in most libc implementations don't do DNS-over-HTTP (DoH); you can implement that yourself and just use the addresses returned by your library/package where the system calls ... want addresses. If you have the go stance, go all the way. Don't say "the C runtime is sh*te but I really really really want that one particular teensy tiny bit of it could someone somewhere somehow please do something to make it a little less sh*te". Legacy baggage is a burden and backwards compatibility shackles you. The C/Unix interfaces are full of this, and with the hindsight of 50 years noone today, not even "C programmers", would implement them all the same way again. But that doesn't mean their behaviour can be arbitrarily changed.

grodriguez100 3y ago

I fully agree with your unpopular opinion.

crabbone 3y ago

This is a bizarre take... Programmers have to deal with a lot of badly written programs all of the time. You'd need this functionality to either debug a program that responds differently to different values of environment variables, or to control it, because, maybe it's the only reasonable way to do so. It's OK to say that programmers shouldn't rely on this functionality ideally, but, for practical reasons, this functionality is needed. Same happens in "pure" functional languages, for example, when you need to debug programs in such languages interactively, and struggle to create the program state that reproduces the problem, or, in some extreme cases, due to I/O being "impure" even struggle to output diagnostic information.