Problem with ACL on windows & proposed fix
Robert Goldman
rpgoldman at sift.net
Fri Jun 26 20:49:46 UTC 2015
Sorry -- I've been traveling, so sat on this bug report for a while.
Here's a test failure from Windows ACL. Looks like ACL is somehow not
running the windows CWD program helper (which should invoke CMD.EXE),
but instead is just taking the command and treating it as its own output.
the other expression (ASDF-TEST::GETCWD-FROM-RUN-PROGRAM) yields
that:
#P"%cd%\\"
(:HOST NIL :DEVICE NIL :DIRECTORY (:RELATIVE "%cd%") :NAME NIL :TYPE
NIL :VERSION :UNSPECIFIC)
This comes from:
(defun getcwd-from-run-program ()
(uiop:parse-native-namestring
(nest
;; TODO: fix run-program to use POWERSHELL.EXE rather than CMD, and
remove this kluge.
#+os-windows (string-trim " ")
(run-program
(os-cond ((os-unix-p) '("pwd" "-P")) ((os-windows-p) "echo %cd%"))
:output '(:string :stripped t)))
:ensure-directory t))
RUN-PROGRAM on Allegro invokes RUN-SHELL-COMMAND, about which their
documentation says:
"This function, originally written and named for Unix machines, is badly
misnamed for Windows, because on Windows, you can only run programs.
Shell commands, such as dir, are not acceptable as a value of the
command argument. See below in this entry for discussion on this point."
Looking below, I see:
"On Windows the name of the shell is cmd.exe. Here is an example of
using run-shell-command on Windows:
(run-shell-command "cmd /c start \"c:\\Program Files\\\"")
which suggests we should modify %NORMALIZE-COMMAND for Allegro to
prepend "CMD /C " to all commands when on windows.
I'll test this myself the next time I get into the office, but that
might not be till Monday afternoon. Or I might get lucky and find that
I can remotely access my windows VM....
Best,
r
More information about the asdf-devel
mailing list