[asdf-devel] asdf:run-shell-command - fix, delete or don't touch?

[Faré]

Do we want to (a) leave run-shell-command half-broken on various
combination of OSes and implementations as soon as any argument needs
quoting, do we want to (b) use heavy artillery to solve the problem
correctly, or should we not just (c) delete this broken functionality
that obviously nobody can or should be relying on for anything
serious?

My preference goes to (c) delete the damn thing (replacing the
function body by an error that suggests a good replacement), but only
if it doesn't create a quagmire for users.

So I could really use some feedback from the ASDF constituency on that.

If we want option (b), I just updated xcvb-driver so its
run-program/process-output-stream does all that asdf:run-shell-command
does, in addition to its previous functionality that allows actually
using the command output. And xcvb-driver supports all the
implementations that asdf:run-shell-command does, and more
(cormanlisp, though untested). Moreover it works correctly on Windows,
including with ClozureCL despite a bug and on Allegro (wanted here).
But it's about 300 lines of complex code, as opposed to about 100 of
trivial wrappers in the current half-broken implementation. See from
requires-escaping-p to run-program/process-output-stream in
xcvb/driver.lisp on
http://common-lisp.net/gitweb?p=projects/xcvb/xcvb.git

Note that unlike XCVB, ASDF itself doesn't use run-shell-command. The
obvious suspects cffi-grovel and sb-grovel don't use it either.
Actually, I wonder if *anyone* uses asdf:run-shell-command. In my
local checkouts, only asdf-install (obsolete) and an experimental file
in mcclim (that could be fixed if needed) explicitly call
asdf:run-shell-command.

Xach - would it be easy for you to test Quicklisp with a version of
ASDF without run-shell-command (or fmakunbound'ing it early on) and
see if anything breaks?

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org