test-run-program.script

[Faré]

On Thu, Nov 17, 2016 at 5:59 PM, Elias Pipping <pipping.elias at icloud.com> wrote:
>
>> On 17 Nov 2016, at 23:41, Faré <fahree at 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