On Thu, Oct 6, 2011 at 23:14, Daniel Herring dherring@tentpost.com wrote:
There are so many problems with "portable shell programming" that I don't think (b) [fix run-shell-command] can be done in general. [...] 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
Well, this is *exactly* what asdf:run-shell-command or xcvb-driver:run-program/process-output-stream is all about: it's a wrapper around whatever functionality is provided by the implementation, that basically allows you to spawn a process in a portable way (and, in XCVB, also to process the output of said command).
If a shell is ever involved, it's only because many implementations do not provide any better access to subprocesses than system(3).
asdf:run-shell-command adopts a "least common denominator" approach, where nothing can be portably run that has any kind of character in it that any implementation may interpret specially, including any of " $\;^!`"'(){}|<>?*&~". If you don't care for portability, you might use the richer interface of whichever implementation you're using.
(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...)
xcvb-driver:run-program/process-output-stream allows you to either give a list of strings as a command, that gets quoted the "standard" way or a string, where you control what quoting you use.
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.
That's what xcvb-driver:run-program/process-output-stream does. For a more powerful tool than this portable wrapper, one could use iolib's portable reimplementation of run-program, but it doesn't look like anyone's willing to implementing it for Windows, and it comes with a lot of baggage (libfixposix, cffi, etc.)
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) [delete asdf:run-shell-command] is the logical conclusion. After step (c), ASDF could ship with a copy of this shell library, much as most distros include ASDF...
Yup.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org