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