Run a script in the same directory as the current script
Asked Answered
H

5

94

I have two Bash scripts in the same folder (saved somewhere by the user who downloads the entire repository):

  • script.sh is run by the user
  • helper.sh is required and run by script.sh

The two scripts should be in the same directory. I need the first script to call the second one, but there are two problems:

  1. Knowing the current working directory is useless to me, because I don't know how the user is executing the first script (could be with /usr/bin/script.sh, with ./script.sh, or it could be with ../Downloads/repo/scr/script.sh)
  2. The script script.sh will be changing to a different directory before calling helper.sh.

I can definitely hack together Bash that does this by storing the current directory in a variable, but that code seems needlessly complicated for what I imagine is a very common and simple task.

Is there a standard way to reliably call helper.sh from within script.sh? And will work in any Bash-supported operating system?

Hypoglossal answered 16/8, 2016 at 15:19 Comment(0)
S
89

Since $0 holds the full path of the script that is running, you can use dirname against it to get the path of the script:

#!/bin/bash

script_name=$0
script_full_path=$(dirname "$0")

echo "script_name: $script_name"
echo "full path: $script_full_path"

so if you for example store it in /tmp/a.sh then you will see an output like:

$ /tmp/a.sh
script_name: /tmp/a.sh
full path: /tmp

so

  1. Knowing the current working directory is useless to me, because I don't know how the user is executing the first script (could be with /usr/bin/script.sh, with ./script.sh, or it could be with ../Downloads/repo/scr/script.sh)

Using dirname "$0" will allow you to keep track of the original path.

  1. The script script.sh will be changing to a different directory before calling helper.sh.

Again, since you have the path in $0 you can cd back to it.

Site answered 16/8, 2016 at 15:23 Comment(5)
Briefly, using $0 won't work as expected with script sourcing. For bash there is the BASH_SOURCE alternative.Await
$0 will NOT work for sub script files executed inside the original scriptMetropolitan
@AlexChe I used ${BASH_SOURCE%/*} and it worked when executed manually but failed when started by cron. Changed it to $(dirname "$0") and now everything works fine.Inapproachable
@AndreKR, is it possible that cron uses other shell, not Bash, on your system? See this question for an example.Await
@AlexChe Good point. I didn't have a shebang in the script and the crontab shell is set to /bin/sh - which apparently on Ubuntu is dash.Inapproachable
S
55

$0 is considered unsafe and fragile by many devs. I have found another solution, it is safe for a chain of bash scripts and source.

If a.sh needs to execute b.sh (located in the same folder) using a child bash process:

#!/bin/bash
__dir="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
bash ${__dir}/b.sh

If a.sh needs to execute b.sh (located in the same folder) using the same bash process:

#!/bin/bash
__dir="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
source ${__dir}/b.sh
Sparerib answered 2/11, 2018 at 16:47 Comment(4)
Your link points to a deleted comment. Do you have another source to support the unsafe claim? Related posts that explain about the issues with $0: choosing between $0 and BASH_SOURCE, how to get script directory in POSIX sh?.Disport
@CrisLuengo Believe this is the link: mywiki.wooledge.org/BashFAQ/028Malraux
@CrisLuengo actually the accepted answer at least explains why $0 is the incorrect thing to do. Cause $0 gives the wrong location in the case the script is sourced, cause then $0 contains the location of the script that is doing the sourcing and not the location of the script being sourced.Dmso
I used ${BASH_SOURCE%/*} and it worked when executed manually but failed when started by cron. Changed it to $(dirname "$0") and now everything works fine.Inapproachable
N
16

Is there a standard way to reliably call helper.sh from within script.sh? And will work in any Bash-supported operating system?

In most cases, when helper.sh is in the same directory as script.sh, you can use in script.sh command:

. ${0%/*}/helper.sh

Explanation:
$0 stores the name of your process (in most cases it's the full path to your script).
${parameter%word} removes suffix pattern word from variable $parameter (in the command above it removes file name /* from the full path stored in variable $0).

If for some reasons (described in other answers) you don't want to use $0, you can use $BASH_SOURCE instead:

. ${BASH_SOURCE%/*}/helper.sh

And if you want, you can use source instead of .:

source ${BASH_SOURCE%/*}/helper.sh

As for me, it's the easiest way to achieve your goal.

Nardoo answered 20/2, 2021 at 14:14 Comment(1)
I used ${BASH_SOURCE%/*} and it worked when executed manually but failed when started by cron. Changed it to $(dirname "$0") and now everything works fine.Inapproachable
P
1

This is the standard variable block I have in all of my scripts:

# Initialize global variables.
{
  declare SCRIPT_INVOKED_NAME="${BASH_SOURCE[${#BASH_SOURCE[@]}-1]}"
  declare SCRIPT_NAME="${SCRIPT_INVOKED_NAME##*/}"
  declare SCRIPT_INVOKED_PATH="$( dirname "${SCRIPT_INVOKED_NAME}" )"
  declare SCRIPT_PATH="$( cd "${SCRIPT_INVOKED_PATH}"; pwd )"
  declare SCRIPT_RUN_DATE="$( date )"
}

I then use SCRIPT_PATH to load other scripts in the same directory:

source "${SCRIPT_PATH}/script-helpers.inc.sh"
Procto answered 9/4, 2023 at 22:17 Comment(0)
A
0

You can use the $0 variable. But this won't be as simple as getting current script name:

d=${0%/*}
[ x"$d" = x"$0" ] && d=.   # portable variant, use [[ ...]] in bash freely
readonly d                 # optional, for additional safety

# ... later on
. "$d"/helper.sh

This works well in set -e case as well.

Alexandrina answered 30/4, 2021 at 11:6 Comment(3)
What is the [ x"$d" = x"$0" ] syntax please? What is the syntactical function of x before the arguments to the equality operator. Or in the following idiom [ -z ${var+x} ] ?Repute
@vonspotz For the first question: it saves you from errors that may be caused if either $0 or $d become starting with a hypen - otherwise it would be interpreted as a directive to [ ... ] command.Alexandrina
@vonspotz For the second question: ${var+x} means "substitute with x if $var is set". Even if $var is empty, this would result in x string being substituted. But in case $var was not set at all, nothing will be substituted. So this is a totally different to the [ x"$foo" = x"$bar" ] question.Alexandrina

© 2022 - 2024 — McMap. All rights reserved.