[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
This page is part of the web mail archives of SRFI 98 from before July 7th, 2015. The new archives for SRFI 98 are here. Eventually, the entire history will be moved there, including any new messages.
- To: Aubrey Jaffer <agj@xxxxxxxxxxxx>
- Subject: Re: setenv?
- From: Abdulaziz Ghuloum <aghuloum@xxxxxxxxx>
- Date: Sat, 5 Jul 2008 18:15:34 -0700
- Cc: Abdulaziz Ghuloum <aghuloum@xxxxxxxxx>, srfi-98@xxxxxxxxxxxxxxxxx
- Delivered-to: srfi-98@xxxxxxxxxxxxxxxxx
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:in-reply-to:references :mime-version:content-type:message-id:cc:content-transfer-encoding :from:subject:date:to:x-mailer; bh=2BzL+uia8mNzOo4qLqQpbIBf1XLbfIK9yEtj/oFJ99k=; b=ZuTYRXfxSOiEuTh7vDAfaZjA6ssOWGc4qsVywQfUDSX/encHd6NW7qehd39FzKQzxP JMh1SB9bj+KMKld1SBX+QGEWyDzZ+IJsD7c/2c4mBmIPbWl8mEB/QD58YLhTYi+TB/ok /OcPSUG8PCWtb5SC3vbsdsssT0qhZBq4v0+nY=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=in-reply-to:references:mime-version:content-type:message-id:cc :content-transfer-encoding:from:subject:date:to:x-mailer; b=KcdUuumxIBRffrcGgHIpF8uUjP9YxprA4xpSdj9BatQf4hmNUMzyGaQL8APHYSUhIL 1tGx3Soa9Ss9l3v8P3tZT09vmZHvZppZp51yZ+Zy6coNkDqBlkEvTRY4AKijisK6wJk2 pkCKXr0jeIjcdbiltknapLpxMMCVq6MHXtfxw=
- In-reply-to: <20080706005550.1642751D7D7@xxxxxxxxxxxxxxxx>
- References: <8087ACC8-8C53-4918-9486-DCCA86974415@xxxxxxxxx> <20080706005550.1642751D7D7@xxxxxxxxxxxxxxxx>
On Jul 5, 2008, at 5:55 PM, Aubrey Jaffer wrote:
(getenv) returns what is essentially environ.
As others have already suggested, it's better to have a separate
procedure for this.
As for setenv, what would be the scope of the environment variables it
changes? Would it be processes spawned the Scheme process calling
That and subsequent calls to getenv. Basically, it would do what the
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
a srfi that provides a single procedure.