You can specify relative paths in scripts. However, scripts that use relative paths no longer work if they are moved from their original directories. For example, suppose that a script named crawl.sh, in <app dir>/control, uses paths relative to <app dir>/control. This script works correctly only if it is invoked while stored in <app dir>/control, because only there will the relative paths be resolved correctly.

To avoid this problem, scripts can use preset variables that refer to specific directories. In Windows batch files, the variable%~dp0 resolves to the directory containing the script. In UNIX Bash scripts, the variable $0 resolves to the script name, and running the dirname command on it will give the script's directory. In BeanShell scripts for AppConfig.xml, the variable ${ENDECA_PROJECT_DIR} points to <app dir>. By using these variables, you can construct portable paths in location-independent scripts. All the scripts generated by the Deployment Template use this technique and can serve as examples.

For UNIX, the scripts generally start with the following lines:

WORKING_DIR=`dirname ${0} 2>/dev/null` 
. "${WORKING_DIR}/../config/script/set_environment.sh"

This sets the WORKING_DIR variable to the directory containing the script being run, and then addresses the set_environment.sh file in a different directory by making the path relative to WORKING_DIR. Wherever the script is invoked, the path to set_environment.sh will always resolve correctly.

For Windows, the scripts usually start with the following line:

call %~dp0..\config\script\set_environment.bat 

This addresses set_environment.bat through a path relative to%~dp0. It ensures that the reference is correct wherever the script is invoked.