JMX, SNMP, Java, etc...

Today I have started experimenting using Mercurial (hg) with ssh. Here are the two first pitfalls in which I have fallen.

As very well documented in the SSH section of the Distributed revision control with Mercurial, the first step is to set up your ssh configuration and make sure you can ssh to the server where the repository you want to access is located.

The easiest way to check that this is working is simply to ssh to the server. If you manage to log in, then check that you have hg in your PATH:

   $ ssh server-host
   $ hg version
   $ ^D

Then you need to check that everything still work in non interactive mode:

   $ ssh server-host hg version

The first pitfall

When I tried the second command above (ssh server-host hg version) I got the following error:

   dfuchs@server-host's password: 
   remote: ksh: hg:  not found
   abort: no suitable response from remote hg!

Since I had already verified that my PATH was correct on the remote server, my first idea was that for some reason my .profile (where I set my PATH variable) was not sourced when running ssh in non interactive mode. I quickly hacked my .profile to verify this (just added an echo "sourcing .profile" line in it), and bingo!
The file was not sourced.

A quick google search revealed that one way to fix this was to make my .kshrc source my .profile if my .profile hadn't been sourced already.

I modified my .profile to put a marker variable:

   PROFILE=yes;export PROFILE

and my .kshrc to source my .profile if the marker wasn't set:

   case "z$PROFILE" in
      z) # echo sourcing profile ; 
         . ~/.profile ;;
      z*) # echo "profile already sourced" 
         ;;
   esac

Tried ssh server-host hg version again, same result. This was obviously not working. Worse, it looked as if my .kshrc wasn't even sourced ever.

After reading my way through several internet searches and man pages such as

   man ssh 
   man sshd
   man sshd_config
   man ksh

I finally found a solution:

• Create (or edit it if it already exists) a file named ~/.ssh/environment
• and put this line inside:

   ENV=~/.kshrc

This will make ssh export the ENV variable before calling ksh. In non interactive mode, ksh will source the file pointed to by the ENV variable. (see man ksh for more details).

   $ ssh server-host hg version
   dfuchs@server-host's password: 
   Mercurial Distributed SCM (version 0.9.3)

Youpi!!!

Update: On some systems, exporting ENV=~/.kshrc may not work: ksh will never source your ~/.kshrc or consult your ENV variable when invoked in non interactive mode through ssh. This may depend on the exact flavour of ssh/ksh that your system is using. In that case, you may want to reconsider your choice of login shell, and switch to bash. bash and ksh are mostly compatible - except from a few minor things, like the command print - which is a built-in equivalent to echo in ksh but doesn't exists in bash. I was able to switch painlessly from ksh to bash by simply adding:

type print 1> /dev/null 2> /dev/null
if [ $? -gt 0 ] ; then
   # define print if it does not exists
   print() {
     echo "$@"
   }
fi

at the beginning of the few of my ksh shell scripts that were using print.

The second pitfall

I fell in the second pitfall when I tried to do an hg clone. If you want to specify an absolute path when specifying the remote workspace in

   hg clone ssh://server-host<workspace-path> 

then <workspace-path> must begin with //, otherwise it's interpreted to be local to your home dir. so

   hg clone ssh://server-host/export/hg/repos

refers in fact to ~/export/hg/repos, while

   hg clone ssh://server-host//export/hg/repos

refers to /export/hg/repos. Again this is very well explained in the SSH section of the Distributed revision control with Mercurial.

Well of course all of this might not happen if your server machine has hg installed directly in /usr/bin...

Hope this help,
-- daniel