Also, you can use bash to debug bin/cassandra:
PS4=' $BASH_SOURCE:$LINENO: ' bash -x bin/cassandra
This should print the filename of the file being executed/sourced and the line
number being currently executed, so it should be easier to find out what
happened, where and when. Of course,
What you complain about may be useful to someone else who might appreciate the
added flexibility. I'd personally be opposed to a single script, as I'd rather
not edit something that might cause conflicts or be overwritten on upgrades
(the location of the include and environment files being
Standard unix/linux systems policy is that editable configurable files
go under /etc. It is not proper to edit files under /{s}bin or
/usr/{s}bin. $PATH contains /{s}bin and /usr/{s}bin files as executables
that can be run by a user, so that's why the basic separation of the
runnable files and
Thanks for the answer, it did not help much. I have read this several times and
this I already know, It still does not answer the question, why there is the
need for three files instead of a single file. Not to mention multiple
different config files.
All these files are more or less
The bin/cassandra script has an explanation
(https://github.com/apache/cassandra/blob/trunk/bin/cassandra#L24):
# As a convenience, a fragment of shell is sourced in order to set one or
# more of these variables. This so-called `include' can be placed in a
# number of locations and will be
Greetings,
I've been working with Cassandra for more than a year but I still wonder about
one thing:
To run the server there is a bash script (cassandra) which uses another script
(cassandra.in.sh) which uses yet another bash script (cassandra-env.sh).
What is the reason behind this?
Why there
