extending uiop/run-program

Elias Pipping pipping.elias at icloud.com
Tue Aug 2 16:52:56 UTC 2016

> On 02 Aug 2016, at 00:06, Elias Pipping <pipping.elias at icloud.com> wrote:
> Dear Robert,
>> On 01 Aug 2016, at 04:25, Robert Goldman <rpgoldman at sift.net> wrote:
>> If you were to move your work on uiop:run-program to a long-lived topic
>> branch, I could test it on a wide variety of implementations on Mac and
>> Linux.
> Sure, that sounds good. I’ve requested an account on
>  https://gitlab.common-lisp.net
> for this purpose.

The branch is now up at


with the first bug fix. I’ve also pushed to another branch


the name of which is supposed to convey how messy it could potentially be (and how
I might `push —force` to it). I’ve added a test script (to the messy branch only) that’s
not currently connected in any way to the existing testing infrastructure. It serves me
as a survey tool, since a test failure at this point can mean either a problem with
run-program or with my understanding of it (I didn’t know about ccl’s

  (with-open-file (… :sharing :lock))

until yesterday e.g. and there’s an odd issue with string streams under cmucl that I wrote to
cmucl-help to about because I’m not sure if cmucl is doing something wrong or I am).

The output currently looks like this for me:


A quick glance reveals that clisp stands out as being particularly badly supported by
run-program and that there’s an error with run-program on cmucl (the one I mentioned
a few lines earlier). Among the tests that are skipped, there’s some where run-program
has asserts in place to catch combinations of parameters that aren’t supported by the
underlying implementation but also some where run-program fails to catch problems and
the implementation either generates an error or silently misbehaves (both are marked
with FIXMEs in the test script).


More information about the asdf-devel mailing list