Bug#997951: jsvn wrapper shell script does not work at all

[Simon Tatham]

Package: svnkit
Version: 1.8.14-4

If I install svnkit and try to use the 'jsvn' command-line interface, I
see mysterious error messages, one of which bizarrely involves Cygwin:

$ jsvnadmin init test-repo
/usr/bin/jsvnadmin: 29: $cygwin: not found
Error: JAVA_HOME is not defined correctly.
  We cannot execute $JAVACMD

$ jsvn checkout svn://example.host/example/repo
/usr/bin/jsvn: 29: $cygwin: not found
Error: JAVA_HOME is not defined correctly.
  We cannot execute $JAVACMD

$ jsvnversion .
/usr/bin/jsvnversion: 29: $cygwin: not found
Error: JAVA_HOME is not defined correctly.
  We cannot execute $JAVACMD

All of these programs in /usr/bin are symlinks to the same shell script
/usr/share/svnkit/jsvn which is supposed to find and invoke the Java
interpreter on the actual svnkit class file in an appropriate manner.

But that shell script cannot possibly work, because it's completely full
of inappropriate backslashes which break all the shell syntax. For
example, the 'if' statement starting at line 29 of the script (cited in
the above error message involving $cygwin) looks like this:

if \$cygwin ; then
  [ -n "\$JAVA_HOME" ] && JAVA_HOME=`cygpath --unix "\$JAVA_HOME"`
  [ -n "\$CLASSPATH" ] && CLASSPATH=`cygpath --path --unix "\$CLASSPATH"`
fi

Further up the file, the shell variable 'cygwin' is defined to be either
'true' or 'false'. So 'if $cygwin' would expand to 'if true' or 'if
false' and do what the author expected. But 'if \$cygwin' will instead
try to run a program literally called '$cygwin' on your path, and (in
the typical case) not find one, which explains the error message above.
And the same error is visible in the code inside the 'if': the test
[ -n "\$JAVA_HOME" ] will always return success, because it's testing if
a completely literal string is non-empty.

There is just one $ sign in the whole script not preceded by a
backslash, and it's right at the bottom in the final 'exec', referring
to a shell variable 'mainclass', which is not defined or even mentioned
anywhere else in the script:

exec "\$JAVACMD" \$JAVA_OPTS \\
  "\$EXTRA_JVM_ARGUMENTS" \\
  -classpath "\$CLASSPATH" \\
  ${mainclass} \\
  "\$@"

It looks very much as if this isn't a shell script at all: it looks like
some kind of precursor or template file which should have been put
through a substitution step at build time. That substitution would have
filled in something sensible for ${mainclass}, and also removed all the
backslash-escapes from the rest of the script to turn it into valid
shell syntax. But in the Debian package build, that substitution step
(whatever it is) has been left out, so a file ends up in /usr/bin that
can't possibly do anything useful.

-- 
for k in [pow(x,37,0x1a1298d262b49c895d47f) for x in [0x50deb914257022de7fff,
0x213558f2215127d5a2d1, 0x90c99e86d08b91218630, 0x109f3d0cfbf640c0beee7,
0xc83e01379a5fbec5fdd1, 0x19d3d70a8d567e388600e, 0x534e2f6e8a4a33155123]]:
 print("".join([chr(32+3*((k>>x)&1))for x in range(79)])) # <anakin at pobox.com>