On 2/29/16 Feb 29 -1:32 PM, Jason Miller wrote:
On 11:46 Mon 29 Feb , Robert Goldman wrote:
the 3.1.7 release candidate now passes all tests on Mac and Linux, for me at least.
UIOP does not seem able to detect cygwin -- it has code that looks like uiop:os-unix-p should return t when cygwin is running, but that code seems not to work. It looks for a :CYGWIN feature which is not present, at least not under SBCL. I can see that uname -o returns "Cygwin", but can't run that from inside SBCL -- catch 22.
I believe that code only detects if the lisp host was linked with cygwin, which makes sense because then the lisp host will think that it is running on a posix system. If the lisp host is linked as a native windows executable, then using windows style pathnames is correct
I agree that it's *correct* -- it's just that windows-style pathnames is not what you get if you invoke the lisp from a bash script in Cygwin. The bash script uses standard facilities to find itself, so it grabs up cygwin pathnames.
To detect cygwin, I probably simply must set a CYGWIN environment variable from the bash script (where it's easy to detect) and use that to figure out when CYGWIN pathnames might be around.
Then I need to figure out exactly how the cygwin pathnames are creeping into the lisp, and either nip them in the bud or translate them. Unfortunately, I don't know how to do the translation. To do it, I must invoke CYGPATH from inside a lisp running on Windows, and there I'm lost.