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
On Fri, Jun 26, 2015 at 4:49 PM, Robert Goldman rpgoldman@sift.net wrote:
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.
Indeed, %run-program has these lines: ;; NB: We do NOT add cmd /c here. You might want to. #+(or allegro clisp) command
Retrospectively, that's probably a mistake.
which suggests we should modify %NORMALIZE-COMMAND for Allegro to prepend "CMD /C " to all commands when on windows.
Yup.
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....
I'll be back from camping this Sunday night. Hopefully next weekend I have time to try.
The situation is becoming pressing: the latest sbcl has made it to debian testing, and is incompatible with the asdf 3.1.4 that is currently available there. We really ought to issue a new asdf ASAP.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Reality must take precedence over public relations, for Mother Nature cannot be fooled. — R.P. Feynman
Ok. Maybe we'll have to issue a 3.1.5 and then follow it almost immediately with a 3.1.6 that will have better Windows support. THEN we can finally move forward again. Best, R
Sent from my iPhone
On Jun 27, 2015, at 23:40, Faré fare@tunes.org wrote:
On Fri, Jun 26, 2015 at 4:49 PM, Robert Goldman rpgoldman@sift.net wrote: 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.
Indeed, %run-program has these lines: ;; NB: We do NOT add cmd /c here. You might want to. #+(or allegro clisp) command
Retrospectively, that's probably a mistake.
which suggests we should modify %NORMALIZE-COMMAND for Allegro to prepend "CMD /C " to all commands when on windows.
Yup.
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....
I'll be back from camping this Sunday night. Hopefully next weekend I have time to try.
The situation is becoming pressing: the latest sbcl has made it to debian testing, and is incompatible with the asdf 3.1.4 that is currently available there. We really ought to issue a new asdf ASAP.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Reality must take precedence over public relations, for Mother Nature cannot be fooled. — R.P. Feynman
On Sun, Jun 28, 2015 at 12:58 AM, Robert P. Goldman rpgoldman@sift.net wrote:
Ok. Maybe we'll have to issue a 3.1.5 and then follow it almost immediately with a 3.1.6 that will have better Windows support. THEN we can finally move forward again.
It might be worth seeing whether a simple fix of eliminating that clause avoiding cmd /c for Allegro and/or CLISP will solve the issue on Windows.
Otherwise, yes, it looks like the issue might not be a regression, but we didn't notice previously because we weren't testing as much on Windows and/or had fewer regression tests.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Everything has its limit — iron ore cannot be educated into gold. — Mark Twain
On 6/28/15 Jun 28 -6:10 AM, Faré wrote:
On Sun, Jun 28, 2015 at 12:58 AM, Robert P. Goldman rpgoldman@sift.net wrote:
Ok. Maybe we'll have to issue a 3.1.5 and then follow it almost immediately with a 3.1.6 that will have better Windows support. THEN we can finally move forward again.
It might be worth seeing whether a simple fix of eliminating that clause avoiding cmd /c for Allegro and/or CLISP will solve the issue on Windows.
Otherwise, yes, it looks like the issue might not be a regression, but we didn't notice previously because we weren't testing as much on Windows and/or had fewer regression tests.
OK. I'm going to try this today.
cheers, r
On 6/27/15 Jun 27 -11:40 PM, Faré wrote:
On Fri, Jun 26, 2015 at 4:49 PM, Robert Goldman rpgoldman@sift.net wrote:
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.
Indeed, %run-program has these lines: ;; NB: We do NOT add cmd /c here. You might want to. #+(or allegro clisp) command
Retrospectively, that's probably a mistake.
which suggests we should modify %NORMALIZE-COMMAND for Allegro to prepend "CMD /C " to all commands when on windows.
Yup.
Actually, I have a question about this: RUN-PROGRAM is supposed to run a program directly by default (as distinguished from RUN-SHELL-COMMAND), which has the (much more ambiguous) behavior of running through a shell.
So it occurs to me that there are two possibilities:
1. We should be invoking CMD.EXE explicitly on Windows in ACL, as we discuss here. But there's a second possibility:
2. The definition of GETCWD-FROM-RUN-PROGRAM is wrong (see below). If G-F-R-P requires CMD.EXE, then doesn't that mean that GETCWD-FROM-RUN-PROGRAM is wrong because "echo %cd%" is a "shell" directive, and not a program to run? Doesn't %cd% require CMD.EXE? Indeed, doesn't G-F-R-P actually require a shell of some sort to do its job? Even on Unix, pwd is a shell command, right? So G-F-R-P should have :FORCE-SHELL T, shouldn't it?
Oh, no, I see. if you provide a single string like "echo %cd%", you are implicitly specifying that you want the shell. But in this case why does (RUN-PROGRAM '("pwd" "-P")) work on Unix variants? Doesn't pwd require a shell?
If my claim is correct, then an alternative patch is to:
1. Supply :FORCE-SHELL T in G-F-R-P 2. Change %normalize-system-command to explicitly supply "CMD /C" on Windows + ACL.
I think that might be more correct than making ACL always explicitly use "CMD /C", since always supply CMD.EXE would make it impossible for ACL + Windows to ever provide the simpler behavior, right?
<sigh>I should have put this in a launchpad ticket</sigh>
Best, r
Am Sun, 28 Jun 2015 12:22:10 -0500 schrieb Robert Goldman rpgoldman@sift.net:
On 6/27/15 Jun 27 -11:40 PM, Faré wrote:
On Fri, Jun 26, 2015 at 4:49 PM, Robert Goldman rpgoldman@sift.net wrote:
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.
Indeed, %run-program has these lines: ;; NB: We do NOT add cmd /c here. You might want to. #+(or allegro clisp) command
Retrospectively, that's probably a mistake.
which suggests we should modify %NORMALIZE-COMMAND for Allegro to prepend "CMD /C " to all commands when on windows.
Yup.
Actually, I have a question about this: RUN-PROGRAM is supposed to run a program directly by default (as distinguished from RUN-SHELL-COMMAND), which has the (much more ambiguous) behavior of running through a shell.
So it occurs to me that there are two possibilities:
- We should be invoking CMD.EXE explicitly on Windows in ACL, as we
discuss here. But there's a second possibility:
- The definition of GETCWD-FROM-RUN-PROGRAM is wrong (see below). If
G-F-R-P requires CMD.EXE, then doesn't that mean that GETCWD-FROM-RUN-PROGRAM is wrong because "echo %cd%" is a "shell" directive, and not a program to run? Doesn't %cd% require CMD.EXE? Indeed, doesn't G-F-R-P actually require a shell of some sort to do its job? Even on Unix, pwd is a shell command, right? So G-F-R-P should have :FORCE-SHELL T, shouldn't it?
Oh, no, I see. if you provide a single string like "echo %cd%", you are implicitly specifying that you want the shell. But in this case why does (RUN-PROGRAM '("pwd" "-P")) work on Unix variants? Doesn't pwd require a shell?
At least here on Debian Linux there exist the external binary versions /bin/echo and /bin/pwd additionally to the built-in shell commands.
If my claim is correct, then an alternative patch is to:
- Supply :FORCE-SHELL T in G-F-R-P
- Change %normalize-system-command to explicitly supply "CMD /C" on
Windows + ACL.
I think that might be more correct than making ACL always explicitly use "CMD /C", since always supply CMD.EXE would make it impossible for ACL + Windows to ever provide the simpler behavior, right?
<sigh>I should have put this in a launchpad ticket</sigh>
Best, r
On 6/28/15 Jun 28 -12:44 PM, edgar wrote:
Am Sun, 28 Jun 2015 12:22:10 -0500 schrieb Robert Goldman rpgoldman@sift.net:
On 6/27/15 Jun 27 -11:40 PM, Faré wrote:
On Fri, Jun 26, 2015 at 4:49 PM, Robert Goldman
....
why does (RUN-PROGRAM '("pwd" "-P")) work on Unix variants? Doesn't pwd require a shell?
At least here on Debian Linux there exist the external binary versions /bin/echo and /bin/pwd additionally to the built-in shell commands.
Thank you. I mistakenly looked only in /usr/bin.
Fixed... This means that G-F-R-P was correct all along: because pwd is a runnable program, we don't need to specify :FORCE-SHELL for Unix variants. Because the Windows command is a string, instead of a list, we don't have to force a shell.
And there's /bin/pwd on Mac OS X, too.
On Sun, Jun 28, 2015 at 1:22 PM, Robert Goldman rpgoldman@sift.net wrote:
If my claim is correct, then an alternative patch is to:
- Supply :FORCE-SHELL T in G-F-R-P
- Change %normalize-system-command to explicitly supply "CMD /C" on
Windows + ACL.
I think that might be more correct than making ACL always explicitly use "CMD /C", since always supply CMD.EXE would make it impossible for ACL + Windows to ever provide the simpler behavior, right?
<sigh>I should have put this in a launchpad ticket</sigh>
Yes, I believe the reason I didn't add the cmd /c is because I wanted to expose the ability to not use cmd /c, at which point we probably should indeed somehow arrange for it to be explicitly used in this case. — then test case, not the code, is wrong (though the code is still wrong for the :force-shell t case if that case fails to add cmd /c without our asking — I didn't check).
PS: note that nothing is guaranteed to exist in /bin except /bin/sh itself. Indeed, nothing else exists on NixOS.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org — Question authority! — Yeah, says who?
-
edgar -
Faré -
Robert Goldman -
Robert P. Goldman