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, /bin/
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 confi
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 tuna
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 configurati
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 sear
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