How to detect if a script is being sourced

Asked 21/4, 2010 at 13:28 Answered 8/2 at 0:31

345

I have a script where I do not want it to call exit if it's being sourced.

I thought of checking if $0 == bash but this has problems if the script is sourced from another script, or if the user sources it from a different shell like ksh.

Is there a reliable way of detecting if a script is being sourced?

Guarantor answered 21/4, 2010 at 13:28 Comment(2)

I had a similar issue a while back and solved it by avoiding 'exit' in all cases; "kill -INT $$" terminates the script safely in either case. – Bittersweet 2/3, 2018 at 13:36

Did you notice this answer? It is given 5 years later from the accepted, but it has "batteries included". – Velamen 7/1, 2019 at 20:42

This seems to be portable between Bash and Korn:

[[ $_ != $0 ]] && echo "Script is being sourced" || echo "Script is a subshell"

A line similar to this or an assignment like pathname="$_" (with a later test and action) must be on the first line of the script or on the line after the shebang (which, if used, should be for ksh in order for it to work under the most circumstances).

Doubles answered 21/4, 2010 at 22:49 Comment(12)

Unfortunately it's not guaranteed to work. If the user has set BASH_ENV, $_ at the top of the script will be the last command run from BASH_ENV. – Yaekoyael 4/4, 2011 at 22:14

This will also not work if you use bash to execute the script, e.g. $ bash script.sh then the $_ would be /bin/bash instead of ./script.sh, which is the case you expect, when the script is invoked in this way: $ ./script.sh In any case detecting with $_ is a problem. – Uncommonly 12/9, 2012 at 20:43

Additional tests could be included to check for those invocation methods. – Doubles 19/2, 2013 at 1:33

Unfortunely, that's wrong! see my answer – Extraction 11/4, 2014 at 11:33

@UpAndAdam: True, captured or used immediately. I have described the latter in my answer. – Doubles 5/5, 2015 at 0:41

Might be good to emphasize that point given the importance of portability in this question – Ernestineernesto 5/5, 2015 at 1:25

To summarize: While this approach typically works, it is not robust; it fails in the following 2 scenarios: (a) bash script (invocation via shell executable, which this solution misreports as sourced), and (b) (far less likely) echo bash; . script (if $_ happens to match the shell sourcing the script, this solution misreports it as a subshell). Only shell-specific special variables (e.g, $BASH_SOURCE) allow robust solutions (it follows that there is no robust POSIX-compliant solution). It is possible, albeit cumbersome, to craft a robust cross-shell test. – Extern 2/3, 2016 at 4:47

@JPope2014: The answer is in the OP's question. "Initially I though checking if $0 == bash but this has problems if the script is sourced from another script, or if the user sources it from ksh." – Doubles 30/8, 2016 at 17:29

fails when echo "anything" is used before this – Cohe 13/9, 2016 at 11:37

@meso_2600: I say "must be on the first line of the script" in my answer. – Doubles 13/9, 2016 at 22:31

This doesn't work. I tested on Ubuntu 14.04 with BASH. – Oza 11/5, 2017 at 15:29

Does not work for me. Should not be the accepted answer. – Unfit 8/3, 2021 at 18:4

292

Robust solutions for bash, ksh, zsh, including a cross-shell one, plus a reasonably robust POSIX-compliant solution:

Version numbers given are the ones on which functionality was verified - likely, these solutions work on much earlier versions, too - feedback welcome.
Using POSIX features only (such as in dash, which acts as /bin/sh on Ubuntu), there is no robust way to determine if a script is being sourced - see below for the best approximation.

Important:

The solutions determine whether the script is being sourced by its caller, which may be a shell itself or another script (which may or may not be sourced itself):

Also detecting the latter case adds complexity; if you do not need to detect the case when your script is being sourced by another script, you can use the following, relatively simple POSIX-compliant solution:

 # Helper function
 is_sourced() {
   if [ -n "$ZSH_VERSION" ]; then 
       case $ZSH_EVAL_CONTEXT in *:file:*) return 0;; esac
   else  # Add additional POSIX-compatible shell names here, if needed.
       case ${0##*/} in dash|-dash|bash|-bash|ksh|-ksh|sh|-sh) return 0;; esac
   fi
   return 1  # NOT sourced.
 }

 # Sample call.
 is_sourced && sourced=1 || sourced=0

All solutions below must run in the top-level scope of your script, not inside functions.

One-liners follow - explanation below; the cross-shell version is complex, but it should work robustly:

bash (verified on 3.57, 4.4.19, and 5.1.16)

(return 0 2>/dev/null) && sourced=1 || sourced=0

ksh (verified on 93u+)

[[ "$(cd -- "$(dirname -- "$0")" && pwd -P)/$(basename -- "$0")" != "$(cd -- "$(dirname -- "${.sh.file}")" && pwd -P)/$(basename -- "${.sh.file}")" ]] && sourced=1 || sourced=0

zsh (verified on 5.0.5)

[[ $ZSH_EVAL_CONTEXT =~ :file$ ]] && sourced=1 || sourced=0

cross-shell (bash, ksh, zsh)

(
  [[ -n $ZSH_VERSION && $ZSH_EVAL_CONTEXT =~ :file$ ]] || 
  [[ -n $KSH_VERSION && "$(cd -- "$(dirname -- "$0")" && pwd -P)/$(basename -- "$0")" != "$(cd -- "$(dirname -- "${.sh.file}")" && pwd -P)/$(basename -- "${.sh.file}")" ]] || 
  [[ -n $BASH_VERSION ]] && (return 0 2>/dev/null)
) && sourced=1 || sourced=0

POSIX-compliant; not a one-liner (single pipeline) for technical reasons and not fully robust (see bottom):

sourced=0
if [ -n "$ZSH_VERSION" ]; then 
  case $ZSH_EVAL_CONTEXT in *:file) sourced=1;; esac
elif [ -n "$KSH_VERSION" ]; then
  [ "$(cd -- "$(dirname -- "$0")" && pwd -P)/$(basename -- "$0")" != "$(cd -- "$(dirname -- "${.sh.file}")" && pwd -P)/$(basename -- "${.sh.file}")" ] && sourced=1
elif [ -n "$BASH_VERSION" ]; then
  (return 0 2>/dev/null) && sourced=1 
else # All other shells: examine $0 for known shell binary filenames.
     # Detects `sh` and `dash`; add additional shell filenames as needed.
  case ${0##*/} in sh|-sh|dash|-dash) sourced=1;; esac
fi

Explanations

bash

(return 0 2>/dev/null) && sourced=1 || sourced=0

^{Note: The technique was adapted from user5754163's answer, as it turned out to be more robust than the original solution, [[ $0 != "$BASH_SOURCE" ]] && sourced=1 || sourced=0[1]}

Bash allows return statements only from functions and, in a script's top-level scope, only if the script is sourced.
- If return is used in the top-level scope of a non-sourced script, an error message is emitted, and the exit code is set to 1.
(return 0 2>/dev/null) executes return in a subshell and suppresses the error message; afterwards the exit code indicates whether the script was sourced (0) or not (1), which is used with the && and || operators to set the sourced variable accordingly.
- Use of a subshell is necessary, because executing return in the top-level scope of a sourced script would exit the script.
- ^{Tip of the hat to @Haozhun, who made the command more robust by explicitly using 0 as the return operand; he notes: per bash help of return [N]: "If N is omitted, the return status is that of the last command." As a result, the earlier version [which used just return, without an operand]
  produces incorrect result if the last command on the user's shell has a non-zero return value.}

ksh

[[ "$(cd -- "$(dirname -- "$0")" && pwd -P)/$(basename -- "$0")" != "$(cd -- "$(dirname -- "${.sh.file}")" && pwd -P)/$(basename -- "${.sh.file}")" ]] && sourced=1 || sourced=0

Special variable ${.sh.file} is somewhat analogous to $BASH_SOURCE; note that ${.sh.file} causes a syntax error in bash, zsh, and dash, so be sure to execute it conditionally in multi-shell scripts.

Unlike in bash, $0 and ${.sh.file} are NOT guaranteed to be the same - at different times either may be a relative path or mere file name, while the other may be a full one; therefore, both $0 and ${.sh.file} must be resolved to full paths before comparing. If the full paths differ, sourcing is implied.

zsh

[[ $ZSH_EVAL_CONTEXT =~ :file$) ]] && sourced=1 || sourced=0

$ZSH_EVAL_CONTEXT contains information about the evaluation context: substring file, separated with :, is only present if the script is being sourced.

In a sourced script's top-level scope, $ZSH_EVAL_CONTEXT ends with :file, and that's what this test is limited to. Inside a function, :shfunc is appended to :file; inside a command substitution, :cmdsubst, is appended.

Using POSIX features only

If you're willing to make certain assumptions, you can make a reasonable, but not fool-proof guess as to whether your script is being sourced, based on knowing the binary filenames of the shells that may be executing your script.
Notably, this means that this approach doesn't detect the case when your script is being sourced by another script.

^{The section "How to handle sourced invocations" in this answer discusses the edge cases that cannot be handled with POSIX features only in detail.}

Examining the binary filename relies on the standard behavior of $0, which zsh, for instance, does not exhibit.

Thus, the safest approach is to combine the robust, shell-specific methods above - which do not rely on $0 - with a $0-based fallback solution for all remaining shells.

In short: The following solution:

in the shells that are covered with shell-specific tests: works robustly.
in all other shells: works only as expected when the script is being sourced directly from such a shell, as opposed to from another script.

^{Tip of the hat to Stéphane Desneux and his answer for the inspiration (transforming my cross-shell statement expression into a sh-compatible if statement and adding a handler for other shells).}

sourced=0
if [ -n "$ZSH_VERSION" ]; then 
  case $ZSH_EVAL_CONTEXT in *:file) sourced=1;; esac
elif [ -n "$KSH_VERSION" ]; then
  [ "$(cd -- "$(dirname -- "$0")" && pwd -P)/$(basename -- "$0")" != "$(cd -- "$(dirname -- "${.sh.file}")" && pwd -P)/$(basename -- "${.sh.file}")" ] && sourced=1
elif [ -n "$BASH_VERSION" ]; then
  (return 0 2>/dev/null) && sourced=1 
else # All other shells: examine $0 for known shell binary filenames.
  # Detects `sh` and `dash`; add additional shell filenames as needed.
  case ${0##*/} in sh|-sh|dash|-dash) sourced=1;; esac
fi

Note that, for robustness, each shell binary filename (e.g. sh) is represented twice - once as-is and a second time, prefixed with -. This is to account for environments, such as macOS, where interactive shells are launched as login shells with a custom $0 value that is the (path-less) shell filename prefixed with -.^{Thanks, t7e.} (While sh and dash are perhaps unlikely to be used as interactive shells, others that you may need to add to the list may.)

^{[1] user1902689 discovered that [[ $0 != "$BASH_SOURCE" ]] yields a false positive when you execute a script located in the $PATH by passing its mere filename to the bash binary; e.g., bash my-script, because $0 is then just my-script, whereas $BASH_SOURCE is the full path. While you normally wouldn't use this technique to invoke scripts in the $PATH - you'd just invoke them directly (my-script) - it is helpful when combined with -x for debugging.}

Extern answered 27/2, 2015 at 23:37 Comment(16)

${0##*/} and $() aren't portable to at least one older Bourne shell (that I still have to use, even if it is a shame that it is necessary): echo ${0##*/} yields bad substitution, and echo $(dirname $0) gives syntax error: '(' unexpected. echo $0 gives -sh. – Sexism 2/10, 2020 at 15:49

This fails your test and I did not source anything: echo $( echo $( echo 321 | echo $( return 0 2>/dev/null ) ) ); echo $? – Pregnable 20/10, 2021 at 18:17

There is a case where bash specific code fails under bash 5 – Coimbra 14/2, 2022 at 2:39

@Thatoneguyfromthemovie, it's unclear how your example command relates to the answer, which is about scripts. Note that in your command you'll only ever see echo's own exit code, which is 0 - it doesn't matter what exit code the command inside the command substitution ($(...)) sets; try echo $(nosuchcommand); echo $? – Extern 14/2, 2022 at 15:3

The Bash version doesn't play nice with set -euo pipefail. – Haden 20/4, 2022 at 5:35

@mhvelplund, I don't see a problem if I execute that statement first - can you describe the problem in detail? On a general note, the unspoken assumption - not just for this answer, but probably most Unix shell-scripting answer - is that options are at their default. – Extern 20/4, 2022 at 12:16

Please update zsh with case $ZSH_EVAL_CONTEXT in *:file*) sourced=1;; esac because the output can be toplevel:file:shfunc and not just toplevel:file – Sunlit 11/5, 2022 at 21:12

@t7e, I've updated the answer to make it clearer that all snippets require running in the script's top-level scope, not inside functions. Making them all work inside functions as well, across all shells, adds too much complexity. – Extern 12/5, 2022 at 2:38

Ok, I'll add my answer then, because I struggled to understand why that function did not work for me. – Sunlit 12/5, 2022 at 8:6

The bash method also works for zsh for me. – Habitue 7/6, 2022 at 6:46

ubuntu 22 adds dashes, so I had to do something like that case "$(printf '%s' "${0##*/}" | sed 's/-//')" in sh|dash|bash) echo "Bash is sourced";; esac – Sunlit 20/6, 2022 at 16:52

Thanks, @Sunlit - please see my update at the bottom. I wasn't aware of Ubuntu, but it can happen on macOS too, for interactive shells. For simplicity and performance and since the list is likely to be small, I've simply doubled the case branch entries ('sh|-sh|...) rather than rely on a command substitution with sed – Extern 21/6, 2022 at 13:33

I guess, you need to change return 1 # NOT sourced. to exit 1 # NOT sourced. Because if it is sourced, use return 0 but if it is not, exit 1. return 1 may not stop the sequence while exit 1 will be safe because the script was run in a new shell. – Sunlit 23/6, 2022 at 13:9

@t7e, the is_sourced() function isn't designed to exit, it is designed to return to the caller and communicate the sourced status via its exit code (0 for sourced, 1 for non-sourced); The sample statement is_sourced && sourced=1 || sourced=0 acts on that code. – Extern 23/6, 2022 at 13:13

In the current code, you have a comment return 1 # NOT sourced, but that case where is_sourced=1 is the case where it is sourced. Remove the word NOT in the comment. – Reiterant 25/12, 2023 at 0:35

@HumpbackWhale194, 1 as an exit code correctly indicates the non-sourced case, signaled via a nonzero exit code. That is, the exit-code logic is the inverse of the logic expressed in the quasi-Boolean sourced variable: In other words: exit code 0` means success - which triggers the && operand - and any nonzero exit code means failure, which triggers the || operand in the is_sourced && sourced=1 || sourced=0 statement. – Extern 25/12, 2023 at 1:18

228

If your Bash version knows about the BASH_SOURCE array variable, try something like:

# man bash | less -p BASH_SOURCE
#[[ ${BASH_VERSINFO[0]} -le 2 ]] && echo 'No BASH_SOURCE array variable' && exit 1

[[ "${BASH_SOURCE[0]}" != "${0}" ]] && echo "script ${BASH_SOURCE[0]} is being sourced ..."

Composed answered 21/4, 2010 at 15:30 Comment(9)

That's maybe the cleanest way as $BASH_SOURCE is intended for that purpose exactly. – Postmark 22/8, 2011 at 10:27

Note that this won't work under ksh which is a condition that the OP specified. – Doubles 19/2, 2013 at 1:31

Is there a reason to use ${BASH_SOURCE[0]} instead of just $BASH_SOURCE? And ${0} vs $0? – Incapacious 11/1, 2016 at 10:47

BASH_SOURCE is an array variable (see manual) that holds a stack trace of sources, where ${BASH_SOURCE[0]} is the latest one. The braces are used here to tell the bash what is part of the variable name. They are not necessary for $0 in this case, but they do not hurt either. ;) – Outfight 22/1, 2016 at 17:23

@Konrad, and if you expand $array, you get ${array[0]} by default. So, again, is there a reason[...]? – Sowder 20/5, 2016 at 16:1

Thanks for the "less -p <pattern>" usage -- very useful option which I had missed. – Bittersweet 2/3, 2018 at 13:30

yeahhh, $_ vs $0 doesn't work, ${BASH_SOURCE[0]} vs $0 works! – Epiglottis 13/10, 2018 at 3:23

@CharlesDuffy the only reason I can think of is that $array == ${array[0]} is a weird and unexpected bit of idiosyncratic syntax. A reader unfamiliar with that fact about bash variable expansion could be confused by the less-explicit syntax. – Dissolution 17/12, 2018 at 20:28

Not sure if the double "" quotes within the double [[ ]] brackets are necessary. – Bisk 5/5, 2021 at 14:30

This seems to be portable between Bash and Korn:

[[ $_ != $0 ]] && echo "Script is being sourced" || echo "Script is a subshell"