[asdf-devel] run-shell-command

[Faré]

On Fri, Oct 21, 2011 at 17:11, Robert Goldman <rpgoldman at sift.info> wrote:
> I don't agree with the claim "better tools are available" yet.  ASDF is
> the standard for the community.  Making people use a different tool is
> like insisting that C programmers use something other than `make`.  It
> raises the bar too high.
>
I didn't mean "ASDF is deprecated",
just "ASDF:RUN-SHELL-COMMAND is deprecated".

ASDF itself doesn't use RUN-SHELL-COMMAND.
R-S-C has a bad interface, a fragile implementation, and can't be fixed.
Other alternatives exist that are easier to use in all cases;
XCVB-DRIVER:RUN-PROGRAM/FOR-SIDE-EFFECTS is an example.
It will take either a shell command string
(but then, it offers you functions to properly escape the contents)
or a list of program and arguments
(that will be interpreted according to your platform's C API).

There isn't EVER any good reason to use R-S-C.
By definition, if you use it, you're using ASDF,
and could thus defsystem-depends-on a better library using ASDF.
If you don't care about portability, then you can already use
your platform's interface, that is much more powerful
than RUN-SHELL-COMMAND.
If you do care about portability, you shouldn't be using R-S-C.
Finally, format controls are a *very* fragile way to produce shell
commands in presence of special characters in file names
or directory names (think Windows). R-S-C encourages sloppy code.

Die, RUN-SHELL-COMMAND, die!

(And yes, I'll be supporting it until it's dead and buried;
that's what I've been doing with ASDF.)

> I don't agree because the cost of adding these libraries is too high.
> To do this now for a system I want to rely on I must (1) locate the new
> run-shell-command library (2) blow that run-shell-command library into
> my revision control system (3) forevermore monitor the library for
> modifications.
>
Quicklisp makes this cost much lower.
And if you Lisp infrastructure doesn't allow you to easily maintain
libraries, you have a problem of your own.

> [For many applications quicklisp may help, but for keeping our
> commercial stuff up and running, we need absolute control, and that
> means keeping stuff under revision control.  I believe that just about
> any company developing software would be in the same position.]
>
Yes, at Google, we have plenty of external libraries under revision control.
I'm using git to manage the branching between our code and upstream.

> This is especially true since the CL community does not yet have a good
> solution to (3).
>
That's not specific to the CL community, is it?
I remember experiencing just as much DLL hell with C/C++ code.
One solution that works: git modules.
But once again, any problem with distribution of Lisp libraries
has to be solved outside ASDF itself.
Quicklisp and clbuild are attempts to help.

> Currently, the implementations attempt to keep good working versions of
> ASDF out there.  There is no corresponding crutch for arbitrary
> libraries (which would include our hypothetical RUN-SHELL-COMMAND).
>
Neither should they be. We need implementations to package ASDF
(and possibly a quicklisp installer?) because it's so basic a need,
required to bootstrap more things. Once you can bootstrap,
you don't need more.

> For software that does not intend to be fully portable, for one or two
> calls to RUN-SHELL-COMMAND, it is far easier to do your own #+allegro,
> #+sbcl, #+ccl (or whatever) than it is to import and track a new
> library.  For one thing, I am confident that if I get the small number
> of individual calls right, they will be truly right and will stay right.
>
But RUN-SHELL-COMMAND really invites you to write sloppy code
that will bite you in the ass if it's deployed beyond your own machine.

> In fact, in the original two applications that got me started finding
> problems with ASDF:RUN-SHELL-COMMAND, I did just that.  They will
> probably only ever run on ACL, SBCL and maybe CCL.  The conditional
> compilation alternatives seem far less rickety than trying to get
> RUN-SHELL-COMMAND to work properly, or to grok another portability library.
>
I've started thinking of XVCB-DRIVER as just as basic as ASDF.
	(asdf:load-system :xcvb-driver)

> Of course, an end application case, such as I have in mind is a
> different use case from a core library such as, e.g., CFFI, where you
> want full portability, and the advantages of trusting someone else to
> get the shell commands right on all platforms pay off better.
>
Certainly. Yet even then, R-S-C is only inviting trouble.

I agree that there's an issue with getting all the CL batteries
included everywhere we need them.

> Maybe I'm starting to agree with you ---  ASDF:RUN-SHELL-COMMAND will
> never be good enough, and programmers are just better off avoiding it.
> Better not to have anything than to have something that does The Wrong
> Thing.
>
Well at least the various known R-S-C bugs seem to be fixed on Unix.
But R-S-C will never work well on Windows, and never be full-featured
wrt output redirection.

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