On Windows with Cygwin, owltools doesn't work in the combination "Cygwin shell, Windows java"

[GoogleCodeExporter]

What steps will reproduce the problem?

1. I have the following shell:

GNU bash, version 4.1.17(9)-release-(x86_64-unknown-cygwin)

2. I have the following Java:

java version "1.8.0_11"
Java(TM) SE Runtime Environment (build 1.8.0_11-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.11-b03, mixed mode)

I downloaded the owltools script and owltools-runner-all.jar.

Java, when started from the script, doesn't find the JAR because of path syntax 
confusion.

The following fixes helped.  Note that I also deleted the setting of 
java.library.path, as ../lib didn't exist in my environment with the above 
downloads.

--- owltools.orig   2014-10-11 17:23:24.929368900 +0200
+++ owltools    2014-10-11 17:22:59.057509400 +0200
@@ -18,7 +18,12 @@
 # failure message will make a little more sense.
 # JAVAPATH="java"

-PATH_SEP=":"
+if [ "`uname -o`" = "Cygwin" ]
+then
+    PATH_SEP=";"
+else
+    PATH_SEP=":"
+fi

 JAVAARGS=" "
 CMDARGS=" "
@@ -27,6 +32,14 @@
 PATH_TO_ME=`which $0`;
 PATH_TO_ME=`echo $PATH_TO_ME | sed -e "s/\(.*\)\/.*/\1/g"`

+if [ "`uname -o`" = "Cygwin" ]
+then
+    LAUNCHER_DIR="$PATH_TO_ME"
+else
+    LAUNCHER_DIR="`cygpath --mixed $PATH_TO_ME`"
+fi
+
+
 # Just the name of the script.
 SCRIPTNAME=`echo $PATH_TO_ME | sed -e "s/.*\/\(.*\)/\1/g"`

@@ -63,6 +76,10 @@
     DEREFERENCED_CLASSPATH=`ls -1 -L $PATH_TO_ME/$ARG | grep -v ontologyrelease`
     for CP_ENTRY in $DEREFERENCED_CLASSPATH
     do
+        if [ "`uname -o`" = "Cygwin" ]
+        then
+            CP_ENTRY="`cygpath --mixed \"$CP_ENTRY\"`"
+        fi
    if [ -z "$CLASSPATH" ]
    then
        CLASSPATH="$CP_ENTRY"
@@ -102,7 +119,7 @@
 fi

 ## Assemble and run the final command.
-CMD="$JAVAPATH -Xms2048M -DentityExpansionLimit=2048000 
-Djava.awt.headless=true -Djava.library.path=$PATH_TO_ME/../lib -classpath 
$CLASSPATH -DlauncherDir=$PATH_TO_ME $JAVAARGS 
owltools.cli.CommandLineInterface $CMDARGS"
+CMD="\"$JAVAPATH\" -Xms2048M -DentityExpansionLimit=2048000 
-Djava.awt.headless=true -classpath \"$CLASSPATH\" 
-DlauncherDir=\"$LAUNCHER_DIR\" $JAVAARGS owltools.cli.CommandLineInterface 
$CMDARGS"

 ## DEBUG
 ## Let's see a little of the environment if we declare DEBUG=1.

Original issue reported on code.google.com by allegris...@gmail.com on 11 Oct 2014 at 3:33

[GoogleCodeExporter]

This issue was closed by revision r2384.

Original comment by cmung...@gmail.com on 11 Oct 2014 at 4:06

• Changed state: Fixed

[GoogleCodeExporter]

This issue was closed by revision r2385.

Original comment by cmung...@gmail.com on 11 Oct 2014 at 4:09

[GoogleCodeExporter]

Thanks! Unfortunately uname doesn't accept -o on OS X

{{{
DESCRIPTION
     The uname utility writes symbols representing one or more system characteristics to the standard output.

     The following options are available:

     -a      Behave as though all of the options -mnrsv were specified.

     -m      print the machine hardware name.

     -n      print the nodename (the nodename may be a name that the system is known by to a communications network).

     -p      print the machine processor architecture name.

     -r      print the operating system release.

     -s      print the operating system name.

     -v      print the operating system version.

     If no options are specified, uname prints the operating system name as if the -s option had been specified.

}}}

I switched this for plain "uname", which yields "Darwin" on OS X and "Linux" on 
Linux, hopefully works for cygwin

Original comment by cmung...@gmail.com on 11 Oct 2014 at 4:11

[GoogleCodeExporter]

I also inverted the second test, as I think you made a typo there

Original comment by cmung...@gmail.com on 11 Oct 2014 at 4:12

[GoogleCodeExporter]

Thanks for your quick response!

You are right about my second test.

Plain "uname" returns CYGWIN_NT-6.3 for me, i.e. it includes the Windows 
version.

With bash it would be easy to test for this, using [[ "`uname`" == CYGWIN* ]].

BTW I made further modification.  I like to use a ~/tools/bin directory 
containing symlinks to all kinds of tools, including 
/path/to/owltools/owltools.  Therefore I enabled the owltools script to find 
its own path in such a situation (using readlink).  (BTW in the presence of the 
DIRNAME variable it's not necessary to once more determine PATH_TO_ME.)

Please find attached my latest version; hope it works for you.

Original comment by allegris...@gmail.com on 11 Oct 2014 at 4:52

Attachments:

• owltools