Subject: Re: [asdf-devel] asdf:run-shell-command - fix, delete or don't touch?
From: "Robert P. Goldman" <[email-masked]>
To: Faré <[email-masked]>
Cc: ASDF-devel <[email-masked]>, Robert Goldman <[email-masked]>, Zach Beane <[email-masked]>
Date: Thu, 6 Oct 2011 22:56:30 -0500

While it might be in some sense The Right Thing, I believe it is simply too disruptive to try to kill run-shell-command. Two reasons in particular:
1. I don't believe there is a full-functioned, well-maintained alternative
2. If you are doing things that involve foreign systems integration, then you need the foreign program invocation to be in ASDF. E.g., we have some systems that invoke perl scripts to massage data files, etc. You can't do that with an external library because of the inadequacies of load dependencies for asdf system definitions (as district from dependencies for systems themselves): most notably the nuisances of invoking functions in packages that do not yet exist and the side-effectiness of the resulting .asd files.

I am torn, but leaning towards (b). Really, effective invocation of external programs is one of the "batteries" I wish CL shipped with.

If we really decide to do (c), I think it's a radical enough change that we should start calling it ASDF 3.

I hope to get a chance to read over the relevant XCVB code, but will be insanely busy with Real Work(tm) for the next three weeks. If it's really done, I would be happy to bake it in as the first asdf contrib.

Best,
R

On Oct 6, 2011, at 19:49, Faré <[email-masked]> wrote:

> 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
> 
> _______________________________________________
> asdf-devel mailing list
> [email-masked]
> http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel