>From: Abdulaziz Ghuloum <xxxxxx@gmail.com>
Subject: Re: setenv?
Date: Sat, 5 Jul 2008 18:15:34 -0700

> > As for setenv, what would be the scope of the environment variables it
> > changes?  Would it be processes spawned the Scheme process calling
> > setenv?
>
> That and subsequent calls to getenv.  Basically, it would do what the libc
> setenv does.
>
> > What standing do child processes have in R6RS?
>
> I don't understand your question.  Most Scheme systems provide some sort
> of fork/exec/process functionality and many (I presume) already have a
> setenv so it would make sense to put it under this srfi instead of having
> a srfi that provides a single procedure.

If we want setenv, a few issues would arise.

- Libc's setenv() (and presumably POSIX.1-2001's) has the third
  argument to specify whether the call can overwrite the existing
  value or not.  Many existing Scheme implementation's setenv
  (actually, all of ones I'm aware of) don't have that argument.
  Which API should we follow?

- If we have setenv, how about unsetenv?  POSIX.1-2001 has it.

- If we allow modifying the environment, should we say about
  thread safety?  Most SRFIs so far don't consider multithreads
  and it's not even in r6rs, we can follow the tradition of not to
  mention about it.  But I can expect multithreaded implementations
  are getting norm, and it may be good to take it into account
  for new srfis.  (Since retrofitting MT-safety would be a great pain.)

FYI, here's setenv-like procedures of various implementations
(it may be outdated).

setenv <variable> <name>     : Chicken, Scsh, Guile
setenv! <variable> <name>    : stklos
sys-putenv <variable> <name> : Gauche
putenv <variable> <name>     : Bigloo, PLT

--shiro