On Thu, 6 Oct 2011, Faré 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.
There are so many problems with "portable shell programming" that I don't think (b) can be done in general. Tools can be written to paper over the commonly used functions, but even POSIXy shells have surprising variety. C shells are not POSIX, and the DOS prompt is a whole other beast.
Autoconf has perhaps the best attempt at documenting and addressing the issues. http://www.gnu.org/software/autoconf/manual/html_node/Portable-Shell.html
For most programmatic use, the shell is simply a hurdle in the way of invoking another process. So why use it?
IMO, the right approach is to have a core CL library that gives direct access to the exec() family of functions on unix and the closest equivalent on other OSes (createprocess on MSWin). Argument quoting for string manipulation is a shell thing and should be discouraged in programmatic use (one thing the CL path designers got right). Quotes cannot be added programmatically in all cases; so the user really must be responsible for adding escapes where needed, again preferably using exec so the shell is not involved. (MSWin is a basket case in that each process implements its own command-line parsing however it pleases. So auto-quote becomes a generic function dispatching on the target process...)
Other libraries can then build features on top of this core. However, "run this program with these arguments" is handled nicely by execv, and pretty much everything more sophisticated is better handled inside CL.
Fortunately, most CLs expose a variant of execv Allegro excl.osi:execve ECL ext:run-program SBCL sb-ext:run-program LW system:call-system (with the arglist options) ...
Long story short, I wouldn't invest more in ASDF's command. I would try to promote an execv-style wrapper as a de facto standard, possibly with an optional attempt at quoting for MSWin. Once that is chosen (and probably polished a bit more), port the handful of systems using run-shell-command to this other library, and then step (c) is the logical conclusion. After step (c), ASDF could ship with a copy of this shell library, much as most distros include ASDF...
Later, Daniel