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

Reply via email to