[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: setenv?
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.
- 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
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.