On 10/3/11 Oct 3 -9:34 AM, Faré wrote:
Dear Robert,
On Mon, Oct 3, 2011 at 09:18, Robert Goldman rpgoldman@sift.info wrote:
P.S. I just rebased and pushed run-shell-command, which was not (of course) a fast-forward push....
regarding your rebase & push, it seems that you (probably intentionally) didn't push to master, only to a branch. To push to the branch, I recommend you delete the old branch and push to a new one. You could reuse the same name, but it would only create confusion to people pulling and not manually fixing their repo based on input from the mailing-list, so I suggest using a different name.
You are right; I just pushed to the branch. I think the tests are CLOSE to being ready for merging to master, but I don't think they are ready yet.
Killing a topic branch and respawning every time one rebases it to master seems ... kludgy, and likely to be at least as disruptive as a non-fast-forward push, as far as I can tell. There is probably a more graceful way to handle this (rebase on the origin instead of in my working dor?), but I don't know what it is.
Also, regarding implementing a proper, portable, run-shell-command, see again how I do most of it in xcvb's driver.lisp, including universal proper quoting of arguments on either windows or unix. It's painful enough that I don't know if we want that for asdf. Also, xcvb's driver.lisp's run-program/* is geared toward processing the output of run-program rather than letting it happen on the console (for some value of console that might not make sense on Windows). If you can make it run portably in *both* situations, I'll be glad.
Another "solution" might be to deprecate asdf's run-shell-command and recommend that packages that previous were using it should instead be using another solution that actually works portably, whether xcvb's driver.lisp, trivial-shell, or any other solution that is being maintained.
Deprecating RUN-SHELL-COMMAND seems like a quite drastic change, and I'm not sure it solves the problem (since we still want RUN-SHELL-COMMAND to work during the period when it is being phased out). Also, a portable means of interacting with shell programs seems like the sort of thing the CL environment should provide "out of the box," and "with ASDF" is pretty close to "out of the box."
Anyway, for now, let's confine our ambitions to seeing if we can portably determine whether R-S-C is working in its current form!
Best, Robert