[asdf-install-devel] Patch for Windows tar execution

[Dan Muller]

I just sent another patch to Gary. (At least, I hope I did. I let
darcs send it for me, I hope I had it configured right.) This replaces
my earlier attempts, and I was more careful about backwards
compatibility. Here's the description, followed by some thought on
further refinements.

----------------------------------------------------------------------

Improved Windows tar execution

Made tar execution on Windows work much more like it does on Unix, and
took steps to avoid argument quoting problems.

- *shell-search-paths* gets set from PATH on Windows. See code for
   rationale. This variable now contains a list of pathnames, not a
   list of lists.

- On Windows, tar is called directly rather than via a
  shell. 

- On Windows, we assume that cygpath.exe is in *CYGWIN-BIN-DIRECTORY*
  or the path, and we use it to prep tar arguments explicitly instead
  of relying on the shell's backquote handling. This should be more
  likely to work out-of-the-box, while still giving precedence to the
  setting of *CYGWIN-BIN-DIRECTORY* which some people might have
  customized.

- Due to the previous change, *CYGWIN-BASH-PROGRAM* is no longer
  needed and is deprecated. If non-nil, a warning is issued where it
  would formerly have been used. I recommend removing it entirely in
  the near future, but perhaps the warning will be helpful to people
  that currently customize it.

- Refactored TAR-ARGUMENTS out of existence, replacing it with
  TAR-ARGUMENT. This was advisable because of the more complex logic
  to be executed per-argument in the Windows case. It also makes it
  clearer how similar the three cases (Windows, SCL, and other) really
  are.

- Changed the Lispworks version of RETURN-OUTPUT-FROM-PROGRAM so that
  it does *not* glom the program and all the arguments together into a
  string. Doing so caused CALL-SYTEM-SHOWING-OUTPUT to run the command
  under a shell rather than directly, which gives rise to all kinds of
  argument quoting issue.

- Changed DIRECTORIFY quite a bit. It wasn't working for me at all as
  it stood, not even on simple paths. My first rewrite messed up on
  paths that appeared to end with a file type.

Summarizing: On Windows we will now use *GNU-TAR-PROGRAM* and
*SHELL-SEARCH-PATHS* just like on UNIX. We still assume Cygwin and
still run cygpath on the tar arguments. We no longer use
*CYGWIN-BASH-PROGRAM*, but we still honor *CYGWIN-BIN-DIRECTORY*. Are
these changes 100% backwards compatible? No, some failure cases will
fail differently. But out-of-the-box success, using Cygwin, and
without customization, is more likely.

----------------------------------------------------------------------

Thoughts on further refinements:

- Note that the program still assumes that if you're on Windows,
  you're using Cygwin, and cygpath must be available. A further
  enhancement would be to run cygpath only conditionally; then native
  DOS-like Gnu tar versions might work out-of-the-box. A good strategy
  would be to run cygpath only if it's in the same directory as tar.

- It would be easy to make the tar argument list configurable; I had
  another version that did this. The default argument list could be
  specified, e.g., like this: '("-C" :OUTPUT "-xzvf" :INPUT). This
  would make it dead easy to accomodate most non-Gnu tars. Changing
  the name of *GNU-TAR-PROGRAM* to *TAR-PROGRAM* would then be
  advisable for clarity.

- The changes I made to Lispworks' RETURN-OUTPUT-FROM-PROGRAM are
  probably applicable to some other platforms, too. Running programs
  directly without the shell usually gives more predictable
  results. Configurable tar program and arguments would give people a
  way to force use of the shell if they really felt the need -- just
  specify the shell as the "tar program" and customize the arg list as
  needed.

- I believe that *CYGWIN-BIN-DIRECTORY* should be deprecated. Using
  PATH should be adequate (even on UNIX, I would have thought), and if
  that's not desirable for some reason, people can easily customize
  *SHELL-SEARCH-PATHS* instead, and/or customize *GNU-TAR-PROGRAM* to
  include path.

And that could be the last word on running an external tar. I hope.

-- 
Dan Muller