On Wed, Aug 24, 2011 at 1:28 PM, Koert Kuipers <ko...@tresata.com> wrote: > my problem is that the scripts for my cassandra 0.7 instance don't work > properly. the problem lies in the code snippets below. when i run the > scripts they source /usr/share/cassandra/cassandra.in.sh, which has the > wrong settings (it now loads all the jars from > /usr/share/brisk/cassandra/lib). i know i can fix it by settings > CASSANDRA_INCLUDE but i think thats not a very nice solution. > > why was the decision made that the central "casssandra.in.sh" should have > higher priority than the local one? doesn't that break local installs?
It was considered the element of least surprise. If it exists in /usr/share/cassandra then Cassandra's been "installed", and in the absence of any other data, that's probably what should be used. If it's a local copy *and* there's a copy installed in /usr/share/cassandra, it's probably the owner of the local copy that needs to know what they are doing and intervene with CASSANDRA_INCLUDE. > wouldnt it make more sense if scripts assumed they were in SOMEDIR/bin and > then tried to load casssandra.in.sh from SOMEDIR first with the highest > priority? I don't think so, but then I was the one that reasoned out the current search order, so YMMV. :) > code snippet: > if [ "x$CASSANDRA_INCLUDE" = "x" ]; then > # Locations (in order) to use when searching for an include file. > for include in /usr/share/cassandra/cassandra.in.sh \ > /usr/local/share/cassandra/cassandra.in.sh \ > /opt/cassandra/cassandra.in.sh \ > ~/.cassandra.in.sh \ > `dirname $0`/cassandra.in.sh; do > if [ -r $include ]; then > . $include > break > fi > done > -- Eric Evans Acunu | http://www.acunu.com | @acunu