-1

This question is related to: Getting the source directory of a Bash script from within - in that question, there is a perfect answer that shows show to get the directory of the currently running bash script (which includes reading the real location of symlinks).

SOURCE="${BASH_SOURCE[0]}"
while [ -h "$SOURCE" ]; do # resolve $SOURCE until the file is no longer a symlink
  DIR="$( cd -P "$( dirname "$SOURCE" )" >/dev/null && pwd )"
  SOURCE="$(readlink "$SOURCE")"
  [[ $SOURCE != /* ]] && SOURCE="$DIR/$SOURCE" # if $SOURCE was a relative symlink, we need to resolve it relative to the path where the symlink file was located
done
DIR="$( cd -P "$( dirname "$SOURCE" )" >/dev/null && pwd )"

This works perfectly, except that it is a lot of boilerplate code. I'm working on a script package that contains lots of small scripts that are using each other. This script package is hosted in a git repo, and it must be location independent. E.g. it should always work the same way, regardless of the directory it was cloned out to. One must be able to clone this repo into many different directories and use them independently. Many scripts are just wrappers around commands, or they are calling other scripts in the same directory, or relative to the containing directory. For example, here is a command that simulates the 'mongo' command, but runs it in a docker container:

#!/bin/bash

set -e

SOURCE="${BASH_SOURCE[0]}"
while [ -h "$SOURCE" ]; do # resolve $SOURCE until the file is no longer a symlink
  DIR="$( cd -P "$( dirname "$SOURCE" )" >/dev/null && pwd )"
  SOURCE="$(readlink "$SOURCE")"
  [[ $SOURCE != /* ]] && SOURCE="$DIR/$SOURCE" # if $SOURCE was a relative symlink, we need to resolve it relative to the path where the symlink file was located
done
DIR="$( cd -P "$( dirname "$SOURCE" )" >/dev/null && pwd )"
# mongo-container is another script that determines the container id
# and it must be referenced relatively to the containing directory
MONGOE="docker exec -ti `${DIR}/mongo-container`"
${MONGOE} mongo "$@"

90% of this code is used to determine the directory of the script, only 10% does something useful. I have about 20 scripts like this. It means that 90% of my bash scripts do nothing just "determine the contaning directory". When I look at them, I almost can't see what they do, because there is so much boilerplate code. There must be a better way, I just can't figure out.

Any ideas?

nagylzs
  • 3,954
  • 6
  • 39
  • 70
  • 2
    Most of the code is only there to resolve symlinks. Do you really need that? I think `dirname "$0"` should be sufficient in your case. – Socowi Oct 22 '18 at 09:10
  • These small scripts will be symlinked to ~/bin directories of various users on the system. So yes, reading symlinks is important. – nagylzs Oct 22 '18 at 09:24
  • 2
    I'm fairly sure you won't get better result than the question you linked. If you need to reuse the code, you could declare it in a system wide function or alias, or even just an external script you systematically call before your main script execution – Aserre Oct 22 '18 at 09:49
  • 2
    Typically, you avoid this by putting your code in well-known places when you *install* it, rather than making the script figure out what random directory you placed it in. – chepner Oct 22 '18 at 12:10
  • You are all saying that creating location independent code is a bad idea. The location of the script **is** the environment, and the script **can** use it. It just happens to be clumsy in bash. It proves that bash is not the perfect tool for the task. But it does not prove that location independent code is bad. Is there a good reason why not to write location independent code? I don't understand why "relative paths should be avoided"? Maybe they should be, but I need an explanation. – nagylzs Oct 22 '18 at 15:38

3 Answers3

2

Maybe you would like to 'factorize' this source code, in a dedicated common GNU/Bash script?

First, I think you may use the which command which is available on most of GNU operating system (often without additional installation)

https://savannah.gnu.org/projects/which/

Then you can create a 'common functionalities' file containing the source code you use to define the complete path, including symbolic link management, let's call it /tmp/myTrueDir/common.sh:

#!/bin/bash

set -e

# Usage: resolveCompleteAbsolutePath <$0 path to regard>
function resolveCompleteAbsolutePath() {
  local SOURCE="$1"
  while [ -h "$SOURCE" ]; do # resolve $SOURCE until the file is no longer a symlink
    DIR="$( cd -P "$( dirname "$SOURCE" )" >/dev/null && pwd )"
    SOURCE="$(readlink "$SOURCE")"
    [[ $SOURCE != /* ]] && SOURCE="$DIR/$SOURCE" # if $SOURCE was a relative symlink, we need to resolve it relative to the path where the symlink file was located
  done
  DIR="$( cd -P "$( dirname "$SOURCE" )" >/dev/null && pwd )"

  echo "$DIR"
}

Then you may use this at the beginning of all your little scripts (first we don't care having to manage symbolic links to reach the common.sh file which is in the same directory of your scripts)

currentDir=$( dirname "$( which "$0" )" )
source "$currentDir/common.sh"

Eventually, you can use the resolveCompleteAbsolutePath function (defined in your common.sh file), to get the complete path, including symbolic links resolution.

Such a way, your script will only contain the interesting source code you want, and the path management will be factorized in the same place.

For instance, you can easily test all this with this file system structure:

/tmp/myTrueDir/
/tmp/myTrueDir/common.sh
/tmp/myTrueDir/test.sh

With /tmp/myTrueDir/test.sh file having these sample lines:

#!/bin/bash

currentDir=$( dirname "$( which "$0" )" )
source "$currentDir/common.sh"
resolvedPath=$( resolveCompleteAbsolutePath "$0" )

echo "currentDir: $currentDir"
echo "resolvedPath: $resolvedPath"

Then you can create a symbolic link to your true directory, let's say:

ln -s /tmp/myTrueDir /tmp/mySymbDir

Then you can call your test script from the symbolic path (i.e. /tmp/mySymbDir/test.sh), and see it works like you want:

currentDir: /tmp/mySymbDir
resolvedDir: /tmp/myTrueDir
Bsquare ℬℬ
  • 4,423
  • 11
  • 24
  • 44
  • Well, if we don't care abount symbolic links, then a simple dirname $0 will do. But I need to care, and in that case, your code will certainly fail. The which command cannot be used, please read the question again. These scripts must be location independent, and they may not be on PATH at all. (Only **some** symlinks to **some** of them) – nagylzs Oct 22 '18 at 11:13
  • I guess my first answer was ambiguous, I edited it to give you complete explanation, with a working sample. Hoping it reaches your needs. – Bsquare ℬℬ Oct 22 '18 at 11:36
  • See [How to check if a program exists from a Bash script?](https://stackoverflow.com/q/592620/4154375) for information about problems with `which`, and what to use instead. – pjh Oct 22 '18 at 19:20
  • For applications like this, `${BASH_SOURCE[0]}` is better than `$0`. See [choosing between $0 and BASH_SOURCE](https://stackoverflow.com/q/35006457/4154375). – pjh Oct 22 '18 at 19:29
2

See BashFAQ/028 (How do I determine the location of my script? ...) for a good treatment of this problem. In particular, note the second paragraph: "It is important to realize that in the general case, this problem has no solution. Any approach you might have heard of, and any approach that will be detailed below, has flaws and will only work in specific cases. First and foremost, try to avoid the problem entirely by not depending on the location of your script!".

It may be that your situation is such that a good enough solution is possible. If your systems have a readlink that supports the -e option, try:

prog_realpath=$(readlink -e -- "${BASH_SOURCE[0]}")
prog_realdir=${prog_realpath%/*}/

Note that the value in prog_realpath will be wrong if the "real" path to the program ends with a newline character. That can be fixed, but it's a very unlikely situation, and it doesn't stop the value in prog_realdir being correct.

See Correct Bash and shell script variable capitalization for the reasons why I changed the names of SOURCE and DIR.

The trailing / on the prog_realdir value is to ensure that it is valid even if the program is in the root directory. Using dirname to get the directory would avoid the / problem, but is vulnerable to the trailing newline problem unless additional trickery is used. See shell: keep trailing newlines ('\n') in command substitution for more information about the trailing newline problem.

If your systems don't (all) support readlink -e, you may be able to use realpath instead. See What's the difference between “realpath” and “readlink -f” for more information about the availability of readlink and realpath on several OSes.

pjh
  • 6,388
  • 2
  • 16
  • 17
1

I tend to put the following line in my code

PROGDIR=$(cd $(dirname $0) && pwd)

This changes to the directory of the script and then runs pwd to get the directory path. I've never had issues with this.

Hope this helps.

Lewis M
  • 550
  • 3
  • 7
  • Yes, this works except when the script was executed from a symlink. It seems you did not read the whole question. – nagylzs Oct 22 '18 at 15:25