Skip to content

LAUNCH-PROGRAM: Support augmenting the child process's environment

Eric Timmons requested to merge launch-program-additional-environment into master

Add :ADDITIONAL-ENVIRONMENT argument to LAUNCH-PROGAM and RUN-PROGRAM. This must be an alist with string keys and values, representing environment variables to add to the child's environment.

Supported on ABCL, Allegro, Clozure, CMUCL, ECL, Lispworks, and SBCL.

Called this the rather verbose :ADDITIONAL-ENVIRONMENT so as to not have any collision with the corresponding argument in the implementation. This is for backwards compatibility, so that if someone is augmenting the environment using the implementation's native argument we don't stomp on their toes. Additionally, it makes super clear that the environment is augmented instead of replaced (something that's often ambiguous in the implementations).

Some quirks:

  • If you provide this argument on ECL, then ECL no longer searches the path for the COMMAND. PR submitted upstream to address this.
  • On CMUCL, the default environment of the child is the same environment in which CMUCL started, not the current environment. This behavior persists when using :ADDITIONAL-ENVIRONMENT as well.

Documentation for supported implementations:

Notes on unsupported implementations:

I did not attempt to extend this to implementations not already supported by LAUNCH-PROGRAM, as those all currently fallback to something equivalent to system(3). I think that any effort spent on those implementations is better spent getting them to implement a proper API we can use via LAUNCH-PROGRAM instead of figuring out how to assemble a shell command that robustly sets the environment variables before running the user's command. Theoretically it wouldn't be too hard on POSIX OSes (just use /usr/bin/env), but I have zero clue on doing it properly in Windows.

Edited by Eric Timmons

Merge request reports