Here's my response from last night. The mailing list doesn't seem to
like my alternative address.
cheers,
r
--- Begin Message ---
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 protected]> 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 protected]
> http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
--- End Message ---
_______________________________________________
asdf-devel mailing list
[email protected]
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
