[armedbear-devel] run-program :environment nil

[Ville Voutilainen]

Forwarding my reply to the list too. :)

On 29 March 2012 16:55, Ville Voutilainen <ville.voutilainen at gmail.com> wrote:
> On 29 March 2012 16:41, Rudi Schlatte <rudi at ifi.uio.no> wrote:
>> Ville Voutilainen <ville.voutilainen at gmail.com> writes:
>>> Here's a tentative patch. I opted for a new keyword argument, since
>>> the new function approach would've led to duplication or to a macro
>>> that has the new argument anyway.  Untested so far, so this is for
>>> general review. Also lacking the docstring changes.
>> Here's my version, using your getenv and process-builder changes.  I
>> get by with only the :environment key, see the docstring for an example
>> on how to overwrite PATH and keep the rest.  Lightly tested.
>
> Looks reasonable. Some questions though:
>
>> -(defun run-program (program args &key environment (wait t))
>> +(defun run-program (program args &key (environment nil environment-p) (wait t))
>
> Ah, yes, this works too, no need for a separate clear-env. But, does
> this change the
> semantics? Our previous code did an environment-merge if an
> environment is supplied.
> This one will clear and insert, and requires using getenv-all if you
> want to replace
> only some parts. I don't want to do such a semantics change. By
> avoiding the semantics
> change, I don't need to worry about breaking asdf.
>
> For that point, I'm still biased towards the clear-env keyword arg
> approach. In that
> approach, getenv-all is just an utility function that you can use if
> you want to do
> weird-complex environment processing, but possibly the most common use cases are
> still "replace a couple of values by providing an environment without
> clearing" and
> "run in a very restricted environment with only a handful of
> variables", neither of
> which requires the use of getenv-all.
>
> Comments?