On Mon, Sep 9, 2013 at 2:51 AM, Faré fahree@gmail.com wrote:
On Mon, Sep 9, 2013 at 1:25 AM, Dave Cooper david.cooper@genworks.com wrote:
CCL 1.9
The second failure just looks like the extra space after the "ok 1" as we were seeing before. Perhaps this is also a CCL issue? Can anyone from Clozure comment on this?
As I mentioned before, it's a CCL bug. I filed http://trac.clozure.com/ccl/ticket/1110
Ok - so this issue is closed as far as this email thread is concerned.
Also, I think I confirmed that CCL's ccl:run-program on Windows really
does
need the "cmd /c " prepended to be able to run a normal program.
...
I believe it might be a matter of searching %PATH% or not. It's really better to have an interface that doesn't call CMD when you don't want it called. The price to pay may then be to have to specify a full path for the target command. Note that uiop:run-program already accepts a :force-shell t argument for people who want CMD /C to be forced. (PS: definitely not tested under Windows.)
Yes absolutely right. Sorry for taking so long to understand this. I confirmed it with various calls to the CCL executable itself (using the full pathname etc).
So the reason we do the (cons "cmd" (strcat "/c " command)) on CCL is because ccl:run-program requires the executable as a separate argument, and it would be too convoluted/error-prone to try to parse the executable out of a string given by the user and call the ccl:run-program with it as a separate argument. So when the user gives a string argument we just use "cmd" as the executable. Sounds reasonable enough.
When and if CCL provides a run-program which allows direct command-line access, as Fare suggests in http://trac.clozure.com/ccl/ticket/1110, then uiop:run-program will be able to call this version of run-program when given a string, and just pass the string directly.
You worry too much about your job. Stop it. You're not paid enough to
worry.