3 ms·

The Setenv Fiasco (2015)

49 points by luu 9y ago

emmelaich 9y ago
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 9y ago
"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_srbBSDCan2015.pdf https://www.bsdcan.org/2015/schedule/attachments/306_srbBSDC...
- rwallace 9y ago
  Can't this be accomplished by putting files in a temp directory?
- theamk 9y ago
  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 9y ago
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.

49 points by luu 9y ago

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 9y ago

"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_srbBSDCan2015.pdf https://www.bsdcan.org/2015/schedule/attachments/306_srbBSDC...

rwallace 9y ago
Can't this be accomplished by putting files in a temp directory?
theamk 9y ago
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 9y ago

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.