This page is part of the web mail archives of SRFI 98 from before July 7th, 2015. The new archives for SRFI 98 contain all messages, not just those from before July 7th, 2015.
From: Abdulaziz Ghuloum <aghuloum@xxxxxxxxx> 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