This answer, a work in progress; Your code
while [ "$index" -lt "$elements" ]
do
?????????
echo "Your Directory is ~/$root/${gitdir[0]}/${gitdir[1]}/${colours[2]}"
done
becomes
fullPath="/${root}/"
index=1
while [ "$index" -lt "$elements" ] ; do
# append values from $gitdir until you are done
fullPath="${fullPath}/${gitdir[$index]}"
(( index++ ))
done
# not sure how colours got introduced to this but same idea
fullPath="${fullPath}/${colours[2]}"
echo "Your Directory is ~/${fullPath}"
use of (( index++ ))
implies using a version of bash, ksh, zsh (maybe others) that support arithmetic evaluations.
That said, it's not clear what your input into gitdir[@] will be and why you need to "count" the levels. Why not just accept user input as arguments, document the order of arguments and then enforce that by testing inputs before starting actual processing. Something like ...
case $# in
[012] ) echo "usage: myScript root path colour [colour2 ...]" 1>&2 ; exit 1 ;;
3 )
# minimal number of args acceptable
root="$1"
localPath="$2"
colour[1]="$3"
;;
* )
# assume more than 1 colour passed
root="$1"
localPath="$2"
shift 2 ; cntr=1
while (( $# > 1 )) ; do
colour[$cntr]="$1"
shift
((cntr++))
done
;;
esac
# you get the idea. recall that a leading '/' on localPath will mess things up
# build a trap for that like
case "${localPath}" in
[/]* ) echo "bad input for localPath, no leading '/' char please" 1>&2 ;;
esac
# validate inputs
if [[ ! -d "${root}" ]] ; then
echo "can't find rootdir=${root}" 1>&2
cleanInput=false
fi
if ! cd "${root}" ; then
echo "can't find rootdir=${root}" 1>&2
exit 1
fi
# we are in root now, make sure that localPath is real
if [[ ! -d "${localPath}" ]] ; then
echo "can't find localPath=${localPath}" 1>&2
cleanInput=false
fi
if ! ${cleanInput:-true} ; then
echo "found errors, please try again"
exit 1
fi
# now do your real stuff.
echo "about to use args passed in root=${root}, localPath=${localPath} colours=${colours[@]} ...."
These are meant to be illustrative about various techniques you can use and NOT a perfect solution to your problem (as I'm still unclear if you have a very specific need or if you're just learning about various ways to solve your problem). Now you have a tool kit of several techniques that should help you organize and test your user input before starting the main processing of your script.
Also per other comments of others, you may find the shell select
"framework" valuable, so search here for [bash] select
. I've seen numerous good solutions that use that for offering users a list of possible actions.
IHTH.