
The Setenv Fiasco (2015) - luu
http://www.club.cc.cmu.edu/~cmccabe/blog_the_setenv_fiasco.html
======
emmelaich
It's not a good API but no-one uses setenv to communicate among threads.

You'd only do it just before fork/exec and nowadays you can just pass the
whole env in the exec call.

------
mpweiher
"Viewed from a C routine there are four levels of scope:

a) Automatic variables, whose life is the subroutines’;

b) External variables, whose life is the memory load;

c) Shell environment variables, whose life is the session;

d) Files, which last forever.

It would be nice if all of these looked the same. For example:

• a,b, and d are binary; c is string

• only c has "export" and "readonly”,

• a,b, and d are accessed by address;

• c has associative searches for "x=”.

We could have a storage class "session" which was like "extern” except it
lives longer. Unfortunately, this requires enormous system changes. So make
session variables look just like files, i.e. that a new set of routines sopen,
sseek, sclose, sread, and swrite exactly image open, seek, ... except that
they work on session files."

[https://www.bsdcan.org/2015/schedule/attachments/306_srbBSDC...](https://www.bsdcan.org/2015/schedule/attachments/306_srbBSDCan2015.pdf)

~~~
theamk
The environment variables are not about "sessions", they are about arbitrary
process trees. For example, during my regular usage, I launch dozens of
scripts with slightly altered env vars (want to see time in Australia?
override TZ). Build system uses env variables to pass settings around. Remote
connections use them to override language settings.

I think the better equivalent would be things like "current
user/groups/ulimits" (which are all even more restricted than strings), or
inheritable command-line.

------
convolvatron
at some point I just gave up, if you're going to be manipulating it - to dump
it into a map. use the map for yourself and reserialize it if you're going to
have children.

