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