[armedbear-devel] run-program :environment nil

[Mark Evenson]

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.

> Also, in a shell environment, an empty variable is not the same as an
> inexistant variable, so I cannot just loop over all the existing
> variables to set them to an empty string.  I see no
> SYSTEM::%PROCESS-BUILDER-ENV-REM function…

This sounds like you really want the ability to constructs a clean
NEW environment.  If we were able to implement that, would your
need to iterate through existing variables disappear?