On Fri, Oct 7, 2011 at 08:40, Zach Beane xach@xach.com wrote:
Faré fahree@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