I had the same concerns, so I decided to grab the Open Source version of LimeWire (http://www.limewire.org) and see what could be done. It turns out that in RunLime.java, the class that gets invoked to start up LimeWire, there is a line where it looks for the limewire.props in the current directory. This is why the runlime.sh script states that "This script must be executed in your LimeWire install directory".

So a simple fix was to create a new script under /usr/local/bin, or wherever you prefer. This script, assuming a jre or java executable is in your PATH, is simply:
= = = = = Cut Here = = = = =
<pre>
#!/bin/sh -p
J2SE_PREEMPTCLOSE=1; export J2SE_PREEMPTCLOSE
LIME_HOME=/usr/local/LimeWire
CLASSPATH=
for f in $LIME_HOME/*.jar; do
if [ "_$CLASSPATH" = "_" ]; then
CLASSPATH=$f
else
CLASSPATH=${CLASSPATH}:$f
fi
done
export CLASSPATH
cd $HOME
java RunLime
</pre>
= = = = = Cut Here = = = = =

This solution is very simple, and seems to work without any problems. It will probably not work for a user who does not have a limewire.props in their home directory, though. This could be fixed by making the script a little smarter, maybe copying a default limewire.props from /etc/skel if it does not exist.

A more elegant solution that I've implemented is a change to RunLime.java. I've modified RunLime.java to look for the limewire.props in the user's home directory, if such a directory exists. If the file does not exist, it creates it with some default values. This is a little tricky on Windows though, since there isn't always a user home directory. I'm still working out all the issues with this, and haven't even considered what to do on a Mac yet...