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

[Faré]

On Fri, Oct 7, 2011 at 08:40, Zach Beane <xach at xach.com> wrote:
> Faré <fahree at gmail.com> writes:
>
>> 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.
>
> My preference is to leave it as-is.
>
>> 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?
>
> Of Quicklisp projects, it breaks CommonQT, elephant, gsll, umlisp, and
> cl-gene-searcher.
>
You win, thanks to superior data. Thanks, Zach!

My plan:
1- declare the interface deprecated for now
2- work with the authors of said software to migrate off of it.
3- when no one is known to use it anymore, make it issue a warning at
compile and/or runtime.
4- after a few versions, make it issue an error

As for replacements, are there serious contenders besides
xcvb-driver:run-program/process-output-stream?
If not, I'll list it as the "official" replacement -- though first I
may need to get it into Quicklisp.

PS: I looked at the following, and none of them provide
either the implementation coverage, os portability,
correctness wrt escaping arguments, or output processing option
that xcvb-driver:run-program/process-output-stream provides.
Therefore, I propose that the "official" replacement be xcvb-driver.

GBBopen:run-external-program
asdf-install::shell-command
cffi-grovel::%invoke
uffi-compat:run-shell-command
elephant::launch-background-program
executor::spawn-process-from-executable
external-program::run external-program::start
gsharp-play::play-tracks
iolib-grovel::%invoke
kmrcl::command-output
mcclim's clim-listener::run-program, dwim::run-shell-command
colorize::system from
parse-declarations/doc/colorize-lisp-examples.lisp or
cffi/doc/colorize-lisp-examples.lisp
philip-jose::spawn-process
trivial-shell::%shell-command

PS2: Yes, Daniel, you can implement a successful synchronous
run-program on top of system(3), thanks to careful quoting, which of
course depends on POSIX vs Windows. See how I do it in xcvb-driver.
Therefore, it's not necessarily a bug to not support more than this.
For asynchronous use, you'd need good support for either threads or
event loops, at which point it's way out of the scope of either ASDF
or XCVB, and for portability you might as well use IOLib (though it
doesn't support Windows at this point).

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