incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Koert Kuipers <ko...@tresata.com>
Subject Re: question about cassandra.in.sh
Date Thu, 25 Aug 2011 15:13:57 GMT
hey eric, the one thing i do not agree that it is the element of least
surprise. i would argue that the default behavior for *nix appplications is
that they find out what their home directory is and operate relative to
that. something like:

script_dir="$(dirname "$(readlink -f ${BASH_SOURCE[0]})")"
home_dir=${script_dir%/bin}

or production quality code from hadoop-config.sh which is sourced by the
main hadoop script:
this="${BASH_SOURCE-$0}"
bin=$(cd -P -- "$(dirname -- "$this")" && pwd -P)
script="$(basename -- "$this")"
this="$bin/$script"
# the root of the Hadoop installation
if [ -z "$HADOOP_HOME" ]; then
  export HADOOP_HOME=`dirname "$this"`/..
fi

i find setting a variable in your shell like CASSANDRA_INCLUDE to be error
prone. at some point i will forget what i set it to and them i am by
accident using the wrong application. once applications are aware of their
home dir all i have to do is "ln -s /usr/lib/cassandra-0.7/bin/nodetool
/usr/sbin/nodetool-0.7" and then i can use it without risk of confusion.

best, koert

On Wed, Aug 24, 2011 at 9:48 PM, Eric Evans <eevans@acunu.com> wrote:

> On Wed, Aug 24, 2011 at 1:28 PM, Koert Kuipers <koert@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
>

Mime
View raw message