Weiqi Gao's Observations - cygwin tag

Your jirb, groovysh and clj Commands Doesn't Work In Cygwin

Tue, 08 Apr 2008 13:28:08 GMT

This is another one of those making things work in Cygwin posts. You can safely skip this post if you are not married to Cygwin, or have not followed my Ten Steps To Higher Cygwin Productivity.

The issue this time is with a little library called JLine, which is a BSD licensed library that brings GNU readline style command line editing to Java. I first learned about it through the Clojure programming language (a LISP with immutable variables and software transactional memory (STM)).

And of course, it doesn't work in my Cygwin xterm window. A little Googling landed me at JLine issue-1822900. A little looking around in the JLine source and some experiments later, I had a partial workaround, which I added as a comment to the issue.

While doing the Google search, I also noticed that both Groovy and JRuby use JLine to some extend (in jirb and groovysh). Sure enough, the same issue showed up in the Groovy JIRA as GROOVY-2584, to which I added the workaround.

A fresh download of the just released JRuby 1.1 showed the same symptom. The JLine workaround can be applied directly to the jruby script, which, thankfully, does contain infrastructure for Cygwin support.

There are other issues with JLine on a Cygwin xterm. But the workaround at least makes the repls workable.

The part that makes me uncomfortable is that I don't see how this workaround can be incorporated into a patch for JLine. In that regard, I concede Cygwin is a somewhat hacky platform. (Jonathan and Adam, if you are still reading...)

Java, Bash, Cygwin, ...

Mon, 10 Mar 2008 23:29:21 GMT

I haven't used the A, B, C, ... style title for a while. Today's post calls attention to all distributors of Java products that provides a Windows batch file and a Unix shell script to run their product:

YOUR SHELL SCRIPT DOESN'T WORK FOR CYGWIN

The problems usually stem from the assumption that a shell script works in the Unix like environment where paths are separated by a ":". Well, for Java under Cygwin, this assumption is no longer valid because the Windows version of the JDK commands such as java or javac expect the CLASSPATH environment variable and the arguments to the -classpath and -bootclassapth command line options to be in the Windows format—with a ";"-separator.

As an example, here is the java shell script shipped with the CICE/ARM closures prototype:

#!/bin/sh
CICEARM_HOME=`dirname $0`/..
java -Xbootclasspath/p:$CICEARM_HOME/lib/rt.jar "$@"

There are two problems with this script. First, it's self recursive, so you cannot put the directory that contains this script into your PATH, or it will call itself in an infinite loop. That's easily fixed by resolving the java call not through the PATH but through JAVA_HOME:

#!/bin/sh
CICEARM_HOME=`dirname $0`/..
"${JAVA_HOME}/bin/java" -Xbootclasspath/p:$CICEARM_HOME/lib/rt.jar "$@"

That brings us to the second problem: the mis-interaction between the Unix style directory names and path separators that bash uses and the JDK commands. If I install the CICE/ARM prototype in the /opt/cicearm-b05 directory, and add /opt/cicearm-b05/bin to my PATH, the above script will expand a simple java Foo command into:

C:\Program Files\Java\jdk1.6.0_10/bin/java -Xbootclasspath/p:/opt/cicearm-b05/bin/../lib/rt.jar Foo

Notice here that we are passing a Cygwin style path /opt/cicearm-b05/bin/../lib/rt.jar to the java command, which will interpret the path as a Windows style path. Most of the time, this will lead to the wrong result.

Fortunately, Cygwin provides a command cygpath that can be used to convert the Cygwin style path into a Windows style path. With the help of this command, and a little bit of uname magic to detect if the bash script is running in Cygwin, we can make the script run properly in Cygwin:

#!/bin/sh
CICEARM_HOME=`dirname $0`/..

# detect Cygwin
cygwin=false;
case "`uname`" in
  CYGWIN*) cygwin=true;
esac

BCP=${CICEARM_HOME}/lib/rt.jar

if $cygwin; then
  BCP=`cygpath --path --windows $BCP`
fi

"${JAVA_HOME}/bin/java" -Xbootclasspath/p:${BCP} "$@"

I know there are not a whole lot vocal Cygwin users out there. Most users would just fix their bash scripts for Cygwin quietly and move on. But for projects still in development, doing the same modification for every snapshot release becomes tiresome very quickly. That's why I usually send my modifications back to the project. And sometimes they even took it.

Using OpenSSH With Cygwin

Tue, 29 Aug 2006 02:14:02 GMT

I have learned a few more things about Cygwin since I posted Ten Steps To Higher Cygwin Productivity 14 days ago:

I need to add another word smbntsec to my CYGWIN environment variable in order for it to pick up the file permissions from Samba. This fixed a problem I have at work where my home directory is on a Samba share and no matter what I do (chmod 600 from within Cygwin, or change the security settings using Windows properties box) all files on that share are readable by the world. OpenSSH didn't like it because my private key is world readable. The smbntsec word cured that. And now I don't have to fall back to using my passwords to log in to remote systems.
I read up a bit about the OpenSSH ssh-agent, ssh-add commands and the way the OpenSSH ssh and scp commands interact with them. Here's what it boils down to:
- I can just use ssh without ever bothering with ssh-agent. In this mode I have to type in my key store pass phrase on every invocation of the ssh command.
- ssh-agent creates an in-memory cache of private keys and ssh-add add private keys to the cache managed by ssh-agent. If ssh knows where to look, it will try to look up the private key it needs from ssh-agent's cache. If the key is already there, it won't prompt me for the pass phrase.
- ssh-agent tells the world how to get hold of it through a pair of environment variables: SSH_AUTH_SOCK and SSH_AGENT_PID. If ssh-agent is invoked with an optional command, e.g., ssh-agent xterm, that command (in this case xterm) will be run in an environment where SSH_AUTH_SOCK and SSH_AGENT_PID are set to the correct values. Otherwise, it just prints out the settings in bash script format:
```
[weiqi@gao] $ ssh-agent
SSH_AUTH_SOCK=/tmp/ssh-euTnCkoNOS/agent.3336; export SSH_AUTH_SOCK;
SSH_AGENT_PID=3328; export SSH_AGENT_PID;
echo Agent pid 3328;
```
To make it all work in my setup, I added a line to my startxwin.bat batch file
```
%RUN% ssh-agent > /etc/profile.d/ssh-agent.sh
```
right before the xterms are run. This way, by the time the xterms are started, the file /etc/profile.d/ssh-agent.sh is already written and contains the correct environment variables. The bash shell running inside each xterm will source this file as part of the start up process. Consequently they will have the correct environment for ssh, scp and ssh-add to talk with the agent. I still need to run ssh-add (and be prompted for the private key store pass phrase) in one of the xterms to populate the agent's key cache. Subsequent ssh and scp invocations will find the key in the cache and won't prompt me for the key store pass phrase.

[Update Thu Aug 31 19:57:10 CST 2006] (It helps if I tested my script before I posted it.) The above script has two flows: 1) it doesn't kill the old ssh-agent, 2) it should have used Windows file names since startxwin.bat is a Windows batch file. The correct script is

c:\cygwin\bin\pkill ssh-agent
del c:\cygwin\etc\profile.d\ssh-agent.sh
c:\cygwin\bin\ssh-agent > c:\cygwin\etc\profile.d\ssh-agent.sh