Last Updated: February 25, 2016
·
780
· destructuring

Configuration for development and deployment

Usually a project has an environment variable like INSTALLROOT, PROJECTHOME. By controlling how these variables are set, scripts can be written with relocatable directory roots. Within a checked out project, those variables can default to something relative to the current directory. When used from another project, it can be anywhere.

Using my macports project as an example, MACPORTS controls where the port command and ports are installed. A good default for development in a git workarea is "$(pwd)/local":

: ${MACPORTS:="$(cd -P -- "$(dirname -- "${BASH_SOURCE}")/.." && pwd -P)/install"}

The rest of the scripts always reference $MACPORTS so my macports can build ports anywhere. In my home directory, I can deploy macports project (located in .macports) to "$HOME/local" simply by setting MACPORTS.

export MACPORTS="$HOME/local"
$HOME/.macports/bin/build ports

In addition to an install var like $MACPORTS, there's a similar var for the project home, which I call $shome; it's solely for development. It's calculated similarly to $MACPORTS and assumes scripts are located in a subdirectory like bin, libexec, etc.

shome=""$(cd -P -- "$(dirname -- "${BASH_SOURCE}")/.." && pwd -P)"

Unlike MACPORTS, shome is not a default since it is not relocatable. By fully qualifying all project access with $shome, I can use any of the following to run the build script:

bin/build
cd bin; ./build
cd; ~/.macports/bin/build

Using $BASHSOURCE instead of $0 lets me define and use shome in a script sourced in .bashrc. My projects have a bin/profile which gets sourced to alter PATHs, set up aliases, define functions. It helps to know where bin/_profile is in case I want to source other scripts and configuration relative to the project. $0, when source, unhelpfully returns -bash.