I see this in test-run-program: #+(and sbcl os-windows) (leave-test "SBCL won't let us pass unquoted arguments to cmd.exe" 0) #-(and sbcl os-windows) (progn (DBG "Testing echo ok 1 via run-program as a string") (assert-equal "ok 1" (dewindowize (run-program "echo ok 1" :output '(:string :stripped t))))) If we know that SBCL on Windows won't let us pass unquoted arguments to cmd.exe, should we raise a NOT-IMPLEMENTED-ERROR on that combination, and check for it in the test? Thanks, r
I believe the correct workaround to the unavoidable quoting on SBCL would be to use CMD /C /S which should remove one layer of quoting. But I'm not sure I have time to setup a Windows development environment at this point (I managed to install a Windows dual boot on my computer, though! Is there a way to run that into a virtual machine?) -#f On Thu, Nov 17, 2016, 13:59 Robert Goldman <rpgoldman@sift.net> wrote:
I see this in test-run-program:
#+(and sbcl os-windows) (leave-test "SBCL won't let us pass unquoted arguments to cmd.exe" 0)
#-(and sbcl os-windows) (progn (DBG "Testing echo ok 1 via run-program as a string") (assert-equal "ok 1" (dewindowize (run-program "echo ok 1" :output '(:string :stripped t)))))
If we know that SBCL on Windows won't let us pass unquoted arguments to cmd.exe, should we raise a NOT-IMPLEMENTED-ERROR on that combination, and check for it in the test?
Thanks, r
On 17 Nov 2016, at 23:41, Faré <fahree@gmail.com> wrote:
I believe the correct workaround to the unavoidable quoting on SBCL would be to use CMD /C /S which should remove one layer of quoting.
But I'm not sure I have time to setup a Windows development environment at this point (I managed to install a Windows dual boot on my computer, though! Is there a way to run that into a virtual machine?)
-#f
Yes, that’s a good point; that should work (the ECL issue should be the same as this). But: I think I just understood what the problem is: The function %normalize-system-command is used in two places: (1) in %system when launch-program is used and (2) in %redirected-system-command, which is called from %system if launch-program is not used The fact that both paths use the same function is actually suboptimal. Because in case (2), %redirected-system-command builds a large string out of what %normalize-system-command returns (it expects a string and adds to it), for (1) it would be much nicer if a list was returned, namely (“sh” “-c” …) or (“cmd” “/c” …) because that could be fed into launch-program as-is and would avoid the quoting issue entirely, no? So unless I’m missing something, - the cleanest fix might be to break up %normalize-system-command into two functions and - the easiest fix might be to (instead) have it always return a list and concatenate that list in %redirected-system-command. Elias
On Thu, Nov 17, 2016 at 5:59 PM, Elias Pipping <pipping.elias@icloud.com> wrote:
On 17 Nov 2016, at 23:41, Faré <fahree@gmail.com> wrote:
I believe the correct workaround to the unavoidable quoting on SBCL would be to use CMD /C /S which should remove one layer of quoting.
But I'm not sure I have time to setup a Windows development environment at this point (I managed to install a Windows dual boot on my computer, though! Is there a way to run that into a virtual machine?)
-#f
Yes, that’s a good point; that should work (the ECL issue should be the same as this).
But: I think I just understood what the problem is:
The function %normalize-system-command is used in two places: (1) in %system when launch-program is used and (2) in %redirected-system-command, which is called from %system if launch-program is not used
The fact that both paths use the same function is actually suboptimal. Because in case (2), %redirected-system-command builds a large string out of what %normalize-system-command returns (it expects a string and adds to it), for (1) it would be much nicer if a list was returned, namely (“sh” “-c” …) or (“cmd” “/c” …) because that could be fed into launch-program as-is and would avoid the quoting issue entirely, no?
So unless I’m missing something, - the cleanest fix might be to break up %normalize-system-command into two functions and - the easiest fix might be to (instead) have it always return a list and concatenate that list in %redirected-system-command.
The current code can certainly be improved upon, however, note that one design constraint that I followed was to avoid redundant indirections. Thus for instance, I tried hard not to pass "sh -c 'foo'" as a string to an API that was already calling /bin/sh -c --- but I *did* pass /bin/sh -c as a string in cases like the totally bogus CLISP that calls $SHELL instead of /bin/sh. On Windows, I tried to make passing a string a pass-through to the underlying run-program, when available, unless you used :force-shell t in which case I forced the use of CMD.EXE. This needs to be better documented, and I now think it was a subtly wrong design that followed the old ASDF 1 rule of being a "thin wrapper" rather than the new ASDF 2/3 rule of being an "abstraction layer" -- probably because I didn't understand then the discrepancy between the direct API call and the call to CMD.EXE. It makes more sense to have an interface that always does the same thing on supported implementations and throws an error on others, than one that does different things on different implementations. Thus, the right thing on Windows is probably to always pass the string to CMD.EXE unless :force-shell nil was passed, at which point a parameter-error is signaled on implementations that do not provide a pass-through. I am *not* going to do that, at least not any time soon. My ASDF cycles are for the plan branch. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Vision is the art of seeing what is invisible to others. — Jonathan Swift
participants (3)
-
Elias Pipping -
Faré -
Robert Goldman