[asdf-devel] New test and windows
I pushed a new test for asdf:run-shell-command that I believe will not work on Windows. The first step should be to use reader switches to remove the test contents when running on Windows, but ideally we should supply some windows code to take the place of the posix code where appropriate. The current test relies on /usr/bin/true and /usr/bin/false to test how asdf:run-shell-command checks exit codes. To be honest, I don't even know if Windows commands /have/ exit codes! See tests/run-shell-command-test.script I suspect that this means no one is running these tests, since there hasn't been a loud cry of outrage!
On Fri, 2010-12-24 at 09:38 -0600, Robert Goldman wrote:
I pushed a new test for asdf:run-shell-command that I believe will not work on Windows. The first step should be to use reader switches to remove the test contents when running on Windows, but ideally we should supply some windows code to take the place of the posix code where appropriate.
The current test relies on /usr/bin/true and /usr/bin/false to test how asdf:run-shell-command checks exit codes.
AFAIK POSIX requires «true» and «false» to reside in /bin not /usr/bin -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib
On 12/24/10 Dec 24 -9:55 AM, Stelian Ionescu wrote:
On Fri, 2010-12-24 at 09:38 -0600, Robert Goldman wrote:
I pushed a new test for asdf:run-shell-command that I believe will not work on Windows. The first step should be to use reader switches to remove the test contents when running on Windows, but ideally we should supply some windows code to take the place of the posix code where appropriate.
The current test relies on /usr/bin/true and /usr/bin/false to test how asdf:run-shell-command checks exit codes.
AFAIK POSIX requires «true» and «false» to reside in /bin not /usr/bin
OK, now checking both POSIX and Mac positions for these files. Pushed a new version. Thanks, Stelian. r
On 12/24/10 Dec 24 -10:31 AM, Robert Goldman wrote:
On 12/24/10 Dec 24 -9:55 AM, Stelian Ionescu wrote:
On Fri, 2010-12-24 at 09:38 -0600, Robert Goldman wrote:
I pushed a new test for asdf:run-shell-command that I believe will not work on Windows. The first step should be to use reader switches to remove the test contents when running on Windows, but ideally we should supply some windows code to take the place of the posix code where appropriate.
The current test relies on /usr/bin/true and /usr/bin/false to test how asdf:run-shell-command checks exit codes.
AFAIK POSIX requires «true» and «false» to reside in /bin not /usr/bin
OK, now checking both POSIX and Mac positions for these files. Pushed a new version. Thanks, Stelian.
Actually, I am not sure I did the right thing here. I am looking at the POSIX standard now (which I'm not good at navigating). It seems like what POSIX mandates is only that I be able to say "true" or "false" to any compliant shell, and it will do the right thing. I don't /believe/ that it dictates a location. So perhaps I have done the wrong thing here by giving a full pathname, and I should simply be using "true" and "false" without directory specifiers. If anyone more conversant with POSIX would speak up, that would be helpful. best, r
On Fri, 2010-12-24 at 10:40 -0600, Robert Goldman wrote:
On 12/24/10 Dec 24 -10:31 AM, Robert Goldman wrote:
On 12/24/10 Dec 24 -9:55 AM, Stelian Ionescu wrote:
On Fri, 2010-12-24 at 09:38 -0600, Robert Goldman wrote:
I pushed a new test for asdf:run-shell-command that I believe will not work on Windows. The first step should be to use reader switches to remove the test contents when running on Windows, but ideally we should supply some windows code to take the place of the posix code where appropriate.
The current test relies on /usr/bin/true and /usr/bin/false to test how asdf:run-shell-command checks exit codes.
AFAIK POSIX requires «true» and «false» to reside in /bin not /usr/bin
OK, now checking both POSIX and Mac positions for these files. Pushed a new version. Thanks, Stelian.
Actually, I am not sure I did the right thing here. I am looking at the POSIX standard now (which I'm not good at navigating).
It seems like what POSIX mandates is only that I be able to say "true" or "false" to any compliant shell, and it will do the right thing. I don't /believe/ that it dictates a location.
So perhaps I have done the wrong thing here by giving a full pathname, and I should simply be using "true" and "false" without directory specifiers.
That's even better, especially since most shells have them as built-ins -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib
On 12/24/10 Dec 24 -10:51 AM, Stelian Ionescu wrote:
On Fri, 2010-12-24 at 10:40 -0600, Robert Goldman wrote:
On 12/24/10 Dec 24 -10:31 AM, Robert Goldman wrote:
On 12/24/10 Dec 24 -9:55 AM, Stelian Ionescu wrote:
On Fri, 2010-12-24 at 09:38 -0600, Robert Goldman wrote:
I pushed a new test for asdf:run-shell-command that I believe will not work on Windows. The first step should be to use reader switches to remove the test contents when running on Windows, but ideally we should supply some windows code to take the place of the posix code where appropriate.
The current test relies on /usr/bin/true and /usr/bin/false to test how asdf:run-shell-command checks exit codes.
AFAIK POSIX requires «true» and «false» to reside in /bin not /usr/bin
OK, now checking both POSIX and Mac positions for these files. Pushed a new version. Thanks, Stelian.
Actually, I am not sure I did the right thing here. I am looking at the POSIX standard now (which I'm not good at navigating).
It seems like what POSIX mandates is only that I be able to say "true" or "false" to any compliant shell, and it will do the right thing. I don't /believe/ that it dictates a location.
So perhaps I have done the wrong thing here by giving a full pathname, and I should simply be using "true" and "false" without directory specifiers.
That's even better, especially since most shells have them as built-ins
Done now. Pretty sure this will not work on Windows, but I have no idea how to fix it. For now, I believe that this test will simply not run on Windows, which is as good as I can manage w/o any windows machine....
Robert, Just got a chance to look at the tests in LispWorks 6.0.1 on Win7. I couldn't use the 'run-tests.sh' script for obvious reasons. I tried to load 'run-shell-command-test.script' by hand but ran into an issue with loading 'script-support.lisp' because *DEFAULT-PATHNAME-DEFAULTS* was not cwd. I wrapped the load command with a LET binding for the cwd and then ran into an issue with finding the temporary ASDF FASL. I did a little perusing of the tests and noticed that 'test1.script', for example, is specific to Unix/Posix/Linux/etc systems. So, my impression is that the tests are fundamentally not usable on Windows at the moment. It appears that there is a fair amount of work required to update the tests so that they are not Unix/Posix/Linux/etc specific. I have some motivation to improve Windows support for ASDF because I have come to rely on it quite a bit, so I'll start working through the tests as time allows and see if I can get things rolling. Happy New Year, ~ Tom ---------------------------------------------------------------- Thomas M. Hermann Odonata Research LLC http://www.odonata-research.com/ http://www.linkedin.com/in/thomasmhermann On Fri, Dec 24, 2010 at 10:55 AM, Robert Goldman <rpgoldman@sift.info>wrote:
On 12/24/10 Dec 24 -10:51 AM, Stelian Ionescu wrote:
On Fri, 2010-12-24 at 10:40 -0600, Robert Goldman wrote:
On 12/24/10 Dec 24 -10:31 AM, Robert Goldman wrote:
On 12/24/10 Dec 24 -9:55 AM, Stelian Ionescu wrote:
On Fri, 2010-12-24 at 09:38 -0600, Robert Goldman wrote:
I pushed a new test for asdf:run-shell-command that I believe will not work on Windows. The first step should be to use reader switches to remove the test contents when running on Windows, but ideally we should supply some windows code to take the place of the posix code where appropriate.
The current test relies on /usr/bin/true and /usr/bin/false to test how asdf:run-shell-command checks exit codes.
AFAIK POSIX requires «true» and «false» to reside in /bin not /usr/bin
OK, now checking both POSIX and Mac positions for these files. Pushed a new version. Thanks, Stelian.
Actually, I am not sure I did the right thing here. I am looking at the POSIX standard now (which I'm not good at navigating).
It seems like what POSIX mandates is only that I be able to say "true" or "false" to any compliant shell, and it will do the right thing. I don't /believe/ that it dictates a location.
So perhaps I have done the wrong thing here by giving a full pathname, and I should simply be using "true" and "false" without directory specifiers.
That's even better, especially since most shells have them as built-ins
Done now. Pretty sure this will not work on Windows, but I have no idea how to fix it. For now, I believe that this test will simply not run on Windows, which is as good as I can manage w/o any windows machine....
_______________________________________________ asdf-devel mailing list asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
On 12/27/10 Dec 27 -7:45 AM, Thomas M. Hermann wrote:
Robert,
Just got a chance to look at the tests in LispWorks 6.0.1 on Win7. I couldn't use the 'run-tests.sh' script for obvious reasons. I tried to load 'run-shell-command-test.script' by hand but ran into an issue with loading 'script-support.lisp' because *DEFAULT-PATHNAME-DEFAULTS* was not cwd. I wrapped the load command with a LET binding for the cwd and then ran into an issue with finding the temporary ASDF FASL.
I did a little perusing of the tests and noticed that 'test1.script', for example, is specific to Unix/Posix/Linux/etc systems. So, my impression is that the tests are fundamentally not usable on Windows at the moment. It appears that there is a fair amount of work required to update the tests so that they are not Unix/Posix/Linux/etc specific. I have some motivation to improve Windows support for ASDF because I have come to rely on it quite a bit, so I'll start working through the tests as time allows and see if I can get things rolling.
If you can get any of the tests running on windows, it might be helpful to distinguish between those that do and don't work. I suppose this would require adding a batch script paralleling run-tests.sh. If you were to do that, you could push something onto *features* to indicate windowsness. Currently, we have to try all the possible features, since there's no implementation-independent way to indicate OS. cheers, r
I can write a batch script for the testing on Windows. I have other obligations, but will try to get to it around the end of the week. ~ Tom ---------------------------------------------------------------- Thomas M. Hermann Odonata Research LLC http://www.odonata-research.com/ http://www.linkedin.com/in/thomasmhermann On Mon, Dec 27, 2010 at 9:11 AM, Robert Goldman <rpgoldman@sift.info> wrote:
On 12/27/10 Dec 27 -7:45 AM, Thomas M. Hermann wrote:
Robert,
Just got a chance to look at the tests in LispWorks 6.0.1 on Win7. I couldn't use the 'run-tests.sh' script for obvious reasons. I tried to load 'run-shell-command-test.script' by hand but ran into an issue with loading 'script-support.lisp' because *DEFAULT-PATHNAME-DEFAULTS* was not cwd. I wrapped the load command with a LET binding for the cwd and then ran into an issue with finding the temporary ASDF FASL.
I did a little perusing of the tests and noticed that 'test1.script', for example, is specific to Unix/Posix/Linux/etc systems. So, my impression is that the tests are fundamentally not usable on Windows at the moment. It appears that there is a fair amount of work required to update the tests so that they are not Unix/Posix/Linux/etc specific. I have some motivation to improve Windows support for ASDF because I have come to rely on it quite a bit, so I'll start working through the tests as time allows and see if I can get things rolling.
If you can get any of the tests running on windows, it might be helpful to distinguish between those that do and don't work.
I suppose this would require adding a batch script paralleling run-tests.sh. If you were to do that, you could push something onto *features* to indicate windowsness. Currently, we have to try all the possible features, since there's no implementation-independent way to indicate OS.
cheers, r
participants (3)
-
Robert Goldman -
Stelian Ionescu -
Thomas M. Hermann