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

[Daniel Herring]

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