Find location of sourced shell script

Question

Is it possible that a sourced shell script knows its location? I've read determining path to sourced shell script but the answers focus on bash and tcsh and fail if a POSIX shell is used. $0 is also not the solution and yields wrong results.

A solution doesn't need to be 100% reliable. It's unlikely that the path contains hard or symlinks.

# sourcing the script should yield the absolute path to the script
. somedir/thescript

# within “thescript”
-> /tmp/foo/bar/somedir

Some background: The script is part of an existing application containing dozens of binaries in a bin directory in a known location (varies per architecture) relative to the sourced script. To use the application the user sources the script which prepends the bin directory to the PATH, so the application's binaries can be easily invoked in the current shell (whichever shell that might be).

Answer 1

The location of the sourced script is not available unless you are using a shell that offers extensions to the POSIX specification. You can test this with the following snippet:

env -i PATH=/usr/bin:/bin sh -c '. ./included.sh' | grep included

where included.sh contains

echo "$0"
set

In bash, the name of the sourced script is in $BASH_SOURCE. In zsh (in zsh compatibility mode, not in sh or ksh compatibility mode), it's in $0 (note that in a function, $0 is the function name instead). In pdksh and dash, it isn't available. In ksh93, this method doesn't reveal the solution, but the full path to the included script is available as ${.sh.file}.

If requiring bash or ksh93 or zsh is good enough, you can use this snippet:

if [ -n "$BASH_SOURCE" ]; then
  this_script=$BASH_SOURCE
elif [ -n "$ZSH_VERSION" ]; then
  setopt function_argzero
  this_script=$0
elif eval '[[ -n ${.sh.file} ]]' 2>/dev/null; then
  eval 'this_script=${.sh.file}'
else
  echo 1>&2 "Unsupported shell. Please use bash, ksh93 or zsh."
  exit 2
fi

You can try to guess the location of the script by looking at what files the shell has open. Experimentally this seems to work with dash and pdksh but not with bash or ksh93 which at least for a short script have closed the script file by the time they get around to executing it.

  open_file=$(lsof -F n -p $$ | sed -n '$s/^n//p')
  if [ -n "$open_file" ]; then
    # best guess: $open_file is this script
  fi

The script may not be the file with the highest-numbered descriptor if the script is sourced inside a complex script that has been playing with redirections. You may want to loop through the open files. This is not guaranteed to work anyway. The only reliable way to locate a sourced script is to use bash, ksh93 or zsh.

---

If you can change the interface, then instead of sourcing your script, have your script print out a shell snippet to be passed to eval in the caller. This is what scripts to set environment variables typically do. It allows your script to be written independently of the vagaries of the caller's shell and shell configuration.

#!/bin/sh
FOO_DIR=$(dirname -- "$0")
cat <<EOF
FOO_DIR='$(printf %s "$FOO_DIR" | sed "s/'/'\\''/g")'
PATH="\$PATH:$FOO_DIR/bin";
export FOO_DIR PATH
EOF

In the caller: eval "`/path/to/setenv`"

Answer 2

Adding to Gilles answer, you MAY be able to get the shell script (if $0 = ash) through the /proc/$$ interface. I don't know how accurate this is, but /proc/$$/fd/11 seems to always point to this_script with BusyBox's ash.

Providing this as a potential answer to those who come across this page (as did I).

Last answer was deleted -- so, my claim to this working is tested on 4 different HW platforms (x86, ARM, XLP, and powerpc). All give the same answer of fd/11. A readlink from /proc/$$/fd/11 yields my script.

Andy