[armedbear-devel] run-program :environment nil

[Rudi Schlatte]

On Mar 27, 2012, at 14:26 , Mark Evenson wrote:

> 
> On Mar 26, 2012, at 6:12 PM, Pascal J. Bourguignon wrote:
> 
>> 
>> (lisp-implementation-version) --> "1.0.1"
>> 
>> 
>> The documentation of extensions:run-program is misleading:
>> 
>>   :environment 
>>       An alist of STRINGs (name . value) describing the new
>>       environment. The default is to copy the environment of the current
>>       process.
>> 
>> The alist doesn't describe the NEW environment, it is only MERGED into
>> the current environment.
> 
> […]
> 
> Which behavior would you prefer?
> 
> We certainly have imprecise documentation here.  The merged environment
> behavior what is easiest with the underlying JVM API which is based
> on the notion of UNIX exec().  In practice, I would venture that
> that most people would expect the merged behavior, as it is the
> common pattern for such wrappers around UNIX execv() and friends
> which have to copy the environment anyways at an operating system
> level before it replaces it with the new code.  (Ok, since every
> contemporary OS probably has "copy-on-write" semantics here, I'll
> stop making OS-dependent statements of doubtful utility).
> 
> I would advocate tightening the documentation.  If Pascal has a
> further need here, I'll take a stab at a version which would somehow
> "wipe" the inherited environment.
> 
> Since the semantics of our EXT:RUN-PROGRAM implementation were
> cribbed from SBCL's under the need to implement just as much as
> ASDF2 required, we should analyze what SBCL does in this situation
> as well.

I think the most basic unix syscall is execve(2), which takes an explicit, possibly empty environment.  exec(3) and its siblings are implemented using execve.

SBCL takes an explicit environment parameter, using the current environment by default but never merging.  This seems like a sane approach.

Rudi