Ответ BASH_SOURCE[] (bash-3.0 и более поздние версии) кажется самым простым, хотя BASH_SOURCE[] не задокументировано для работы вне тела функции (в настоящее время он работает, что противоречит справочной странице).

Самый надежный способ, предложенный Вираваном Пурванто, — это проверить FUNCNAME[1] внутри функции:

function mycheck() { declare -p FUNCNAME; }
mycheck

Потом:

$ bash sourcetest.sh
declare -a FUNCNAME='([0]="mycheck" [1]="main")'
$ . sourcetest.sh
declare -a FUNCNAME='([0]="mycheck" [1]="source")'

Это эквивалентно проверке вывода caller, значения main и source различают контекст вызывающего объекта. Использование FUNCNAME[] избавляет вас от захвата и анализа caller выходных данных. Тем не менее, вам нужно знать или рассчитать вашу локальную глубину вызова, чтобы быть правильным. Такие случаи, как сценарий, полученный из другой функции или сценария, приведут к тому, что массив (стек) станет глубже. (FUNCNAME — это специальная переменная массива bash, она должна иметь непрерывные индексы, соответствующие стеку вызовов, если она никогда не равна unset.)

function issourced() {
    [[ ${FUNCNAME[@]: -1} == "source" ]]
}

(В bash-4.2 и более поздних версиях вы можете использовать более простую форму ${FUNCNAME[-1]} вместо последнего элемента в массиве. Улучшено и упрощено благодаря комментарию Денниса Уильямсона ниже.)

Однако ваша проблема, как указано, заключается в следующем: «У меня есть сценарий, в котором я не хочу, чтобы он вызывал «выход», если он находится в источнике». Обычная bash идиома для этой ситуации:

return 2>/dev/null || exit

Если сценарий является исходным, то return завершит исходный сценарий и вернется к вызывающей стороне.

Если скрипт выполняется, то return вернет ошибку (перенаправлено), а exit завершит скрипт как обычно. И return, и exit могут принимать код выхода, если это необходимо.

К сожалению, это не работает в ksh (по крайней мере, не в версии, производной от AT&T, которая у меня есть здесь), она рассматривает return как эквивалент exit, если вызывается вне функции или скрипта с точечным источником.

Обновлено: что вы можете сделать в современных версиях ksh, так это проверить специальную переменную .sh.level, для которой задана глубина вызова функции. Для вызванного скрипта это изначально будет не установлено, для скрипта с точечным источником будет установлено значение 1.

function issourced {
    [[ ${.sh.level} -eq 2 ]]
}

issourced && echo this script is sourced

Это не так надежно, как версия bash, вы должны вызывать issourced() в файле, который вы тестируете, на верхнем уровне или на известной глубине функции.

(Вас также может заинтересовать этот код на github, который использует функцию дисциплины ksh и некоторые ловушки отладки обман для эмуляции массива bash FUNCNAME.)

Канонический ответ здесь: http://mywiki.wooledge.org/BashFAQ/109 также предлагает $- как еще один индикатор (хотя и несовершенный) состояния оболочки.

Примечания:

• можно создать функции bash с именами «основной» и «источник» (переопределяет встроенную), эти имена могут появляться в FUNCNAME[], но пока проверяется только последний элемент в этом массиве, двусмысленности нет. .
• У меня нет хорошего ответа на pdksh. Самое близкое, что я могу найти, относится только к pdksh, где каждый источник сценария открывает новый файловый дескриптор (начиная с 10 для исходного сценария). Почти наверняка не то, на что вы хотите положиться...

^{Примечание редактора. Решение этого ответа работает надежно, но только для bash. Его можно упростить до
(return 2>/dev/null).}

TL;DR

Попробуйте выполнить оператор return. Если сценарий не получен, это вызовет ошибку. Вы можете поймать эту ошибку и продолжить, как вам нужно.

Поместите это в файл и назовите его, скажем, test.sh:

#!/usr/bin/env sh

# Try to execute a `return` statement,
# but do it in a sub-shell and catch the results.
# If this script isn't sourced, that will raise an error.
$(return >/dev/null 2>&1)

# What exit code did that give?
if [ "$?" -eq "0" ]
then
    echo "This script is sourced."
else
    echo "This script is not sourced."
fi

Выполните его напрямую:

shell-prompt> sh test.sh
output: This script is not sourced.

Источник:

shell-prompt> source test.sh
output: This script is sourced.

Для меня это работает в zsh и bash.

Пояснение

Оператор return вызовет ошибку, если вы попытаетесь выполнить его вне функции или если источник сценария отсутствует. Попробуйте это из командной строки:

shell-prompt> return
output: ...can only `return` from a function or sourced script

Вам не нужно видеть это сообщение об ошибке, поэтому вы можете перенаправить вывод на dev/null:

shell-prompt> return >/dev/null 2>&1

Теперь проверьте код выхода. 0 означает ОК (ошибок не было), 1 означает, что произошла ошибка:

shell-prompt> echo $?
output: 1

Вы также хотите выполнить оператор return внутри подоболочки. Когда оператор return запускает его. . . хорошо . . . возвращается. Если вы выполните его в подоболочке, он вернется из этой подоболочки, а не из вашего скрипта. Чтобы выполнить в подоболочке, оберните его в $(...):

shell-prompt> $(return >/dev/null 2>$1)

Теперь вы можете увидеть код выхода из под-оболочки, который должен быть равен 1, потому что внутри под-оболочки возникла ошибка:

shell-prompt> echo $?
output: 1

FWIW, прочитав все остальные ответы, я нашел для себя следующее решение:

Обновление: на самом деле, кто-то заметил исправленную ошибку в другом ответе, которая коснулась и моего. Я думаю, что обновление здесь также является улучшением (см. правки, если вам интересно).

Это работает для всех скриптов, которые начинаются с #!/bin/bash, но также могут быть получены из разных оболочек, чтобы узнать некоторую информацию (например, настройки), которая хранится вне функции main.

Согласно комментариям ниже, этот ответ, по-видимому, не работает для всех вариантов bash. Также не для систем, где /bin/sh основано на bash. То есть для bash v3.x на MacOS не работает. (В настоящее время я не знаю, как это решить.)

#!/bin/bash

# Function definitions (API) and shell variables (constants) go here
# (This is what might be interesting for other shells, too.)

# this main() function is only meant to be meaningful for bash
main()
{
# The script's execution part goes here
}

BASH_SOURCE=".$0" # cannot be changed in bash
test ".$0" != ".$BASH_SOURCE" || main "$@"

Вместо последних двух строк вы можете использовать следующий (на мой взгляд, менее читаемый) код, чтобы не устанавливать BASH_SOURCE в других оболочках и разрешить set -e работать в main:

if ( BASH_SOURCE=".$0" && exec test ".$0" != ".$BASH_SOURCE" ); then :; else main "$@"; fi

Этот скрипт-рецепт имеет следующие свойства:

• Если выполняется bash обычным способом, вызывается main. Обратите внимание, что это не включает вызов типа bash -x script (где script не содержит пути), см. ниже.

• Если источником является bash, main вызывается только в том случае, если вызывающий скрипт имеет то же имя. (Например, если он исходит сам или через bash -c 'someotherscript "$@"' main-script args.., где должно быть main-script, то, что test видит как $BASH_SOURCE).

• Если источник/выполнение/чтение/evaled оболочкой, отличной от bash, main не вызывается (BASH_SOURCE всегда отличается от $0).

• main не вызывается, если bash читает скрипт со стандартного ввода, если только вы не установите $0 в качестве пустой строки, например: ( exec -a '' /bin/bash ) <script

• Если bash оценивается с помощью eval (eval "`cat script`" все кавычки важны!) из какого-либо другого скрипта, это вызывает main. Если eval запускается напрямую из командной строки, это похоже на предыдущий случай, когда скрипт читается из стандартного ввода. (BASH_SOURCE пусто, а $0 обычно равно /bin/bash, если не принуждать к чему-то совершенно другому.)

• Если main не вызывается, возвращается true ($?=0).

• Это не зависит от неожиданного поведения (ранее я писал undocumented, но я не нашел документации, что вы не можете unset или изменить BASH_SOURCE):

  • BASH_SOURCE is a bash reserved array. But allowing BASH_SOURCE=".$0" to change it would open a very dangerous can of worms, so my expectation is, that this must have no effect (except, perhaps, some ugly warning shows up in some future version of bash).
  • Нет документации, что BASH_SOURCE работает вне функций. Однако обратное (то, что это работает только в функциях) также не задокументировано. Наблюдение состоит в том, что это работает (проверено с bash v4.3 и v4.4, к сожалению, у меня больше нет bash v3.x) и что слишком много скриптов сломается, если $BASH_SOURCE перестанет работать, как наблюдается. Следовательно, я ожидаю, что BASH_SOURCE останется таким же и для будущих версий bash.
  • Напротив (хорошая находка, кстати!) рассмотрим ( return 0 ), что дает 0, если получено, и 1, если нет. Это происходит немного неожиданно не только для меня , и (согласно прочитанному там) POSIX говорит, что return от подоболочка - это неопределенное поведение (и return здесь явно из подоболочки). Возможно, эта функция в конечном итоге получит достаточно широкое распространение, так что ее больше нельзя будет изменить, но AFAICS существует гораздо более высокая вероятность того, что какая-то будущая версия bash случайно изменит поведение возврата в этом случае.

• К сожалению, bash -x script 1 2 3 не запускает main. (Сравните script 1 2 3, где script не имеет пути). В качестве обходного пути можно использовать следующее:

  • bash -x "`which script`" 1 2 3
  • bash -xc '. script' "`which script`" 1 2 3
  • То, что bash script 1 2 3 не запускает main, можно считать особенностью.

• Обратите внимание, что ( exec -a none script ) вызывает main (bash не передает свой $0 скрипту, для этого нужно использовать -c как показано в последнем пункте).

Таким образом, за исключением некоторых угловых случаев, main вызывается только тогда, когда скрипт выполняется обычным образом. Обычно это именно то, что вам нужно, особенно потому, что в нем отсутствует сложный, трудный для понимания код.

Обратите внимание, что он очень похож на код Python:

if __name__ == '__main__': main()

Что также предотвращает вызов main, за исключением некоторых крайних случаев, поскольку вы можете импортировать/загружать скрипт и применять этот __name__='__main__'

Почему я думаю, что это хороший общий способ решения проблемы

Если у вас есть что-то, что может быть получено из нескольких оболочек, оно должно быть совместимо. Однако (прочитайте другие ответы), поскольку нет (простого в реализации) переносимого способа обнаружения sourceing, вам следует изменить правила.

Установив, что скрипт должен выполняться /bin/bash, вы именно это и сделаете.

Это решает все случаи, кроме следующих, в которых скрипт не может запускаться напрямую:

• /bin/bash не установлен или не работает (т.е. в загрузочной среде)
• Если вы направите его в оболочку, как в curl https://example.com/script | $SHELL
• (Примечание: это верно только в том случае, если ваш bash достаточно свежий. Сообщается, что этот рецепт не работает для определенных вариантов. Поэтому обязательно проверьте, работает ли он для вашего случая.)

Однако я не могу думать ни о какой реальной причине, по которой вам это нужно, а также о возможности параллельного получения точно такого же сценария! Обычно вы можете обернуть его, чтобы выполнить main вручную. Как это:

• $SHELL -c '. script && main'
• { curl https://example.com/script && echo && echo main; } | $SHELL
• $SHELL -c 'eval "`curl https://example.com/script`" && main'
• echo 'eval "`curl https://example.com/script`" && main' | $SHELL

Примечания

• Этот ответ был бы невозможен без помощи всех других ответов! Даже не те, которые изначально заставили меня опубликовать это.

• Обновление: отредактировано в связи с новыми открытиями, найденными в https://stackoverflow.com/a/28776166/490291.

Это работает позже в скрипте и не зависит от переменной _:

## Check to make sure it is not sourced:
Prog=myscript.sh
if [ $(basename $0) = $Prog ]; then
   exit 1  # not sourced
fi

or

[ $(basename $0) = $Prog ] && exit

Я дам ответ, специфичный для BASH. Корн шелл, извините. Предположим, имя вашего сценария include2.sh ; затем создайте функцию внутри include2.sh с именем am_I_sourced. Вот моя демо-версия include2.sh:

am_I_sourced()
{
  if [ "${FUNCNAME[1]}" = source ]; then
    if [ "$1" = -v ]; then
      echo "I am being sourced, this filename is ${BASH_SOURCE[0]} and my caller script/shell name was $0"
    fi
    return 0
  else
    if [ "$1" = -v ]; then
      echo "I am not being sourced, my script/shell name was $0"
    fi
    return 1
  fi
}

if am_I_sourced -v; then
  echo "Do something with sourced script"
else
  echo "Do something with executed script"
fi

Теперь попробуйте выполнить его разными способами:

~/toys/bash $ chmod a+x include2.sh

~/toys/bash $ ./include2.sh 
I am not being sourced, my script/shell name was ./include2.sh
Do something with executed script

~/toys/bash $ bash ./include2.sh 
I am not being sourced, my script/shell name was ./include2.sh
Do something with executed script

~/toys/bash $ . include2.sh
I am being sourced, this filename is include2.sh and my caller script/shell name was bash
Do something with sourced script

Так что это работает без исключения и не использует хрупкие $_ материалы. Этот трюк использует средство самоанализа BASH, то есть встроенные переменные FUNCNAME и BASH_SOURCE; см. их документацию на странице руководства bash.

Только две оговорки:

1) вызов am_I_called должен выполняться в исходном скрипте, но не внутри какой-либо функции, иначе ${FUNCNAME[1]} вернет что-то еще. Да... ты мог бы проверить ${FUNCNAME[2]} -- но ты только усложняешь себе жизнь.

2) функция am_I_called должна находиться в исходном скрипте, если вы хотите узнать, какое имя включенного файла.

Я хотел бы предложить небольшую поправку к очень полезному ответу Денниса, чтобы сделать его немного более переносимым, я надеюсь:

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

потому что [[ не распознается (несколько анально сохраняющим ИМХО) POSIX-совместимой оболочкой Debian, dash. Кроме того, кавычки могут понадобиться для защиты от имен файлов, содержащих пробелы, опять же в указанной оболочке.

$_ довольно хрупкий. Вы должны проверить это как первое, что вы делаете в сценарии. И даже в этом случае не гарантируется, что он будет содержать имя вашей оболочки (если оно получено) или имя скрипта (если оно выполнено).

Например, если пользователь установил BASH_ENV, то в начале скрипта $_ будет содержать имя последней команды, выполненной в скрипте BASH_ENV.

Лучший способ, который я нашел, - использовать $0 следующим образом:

name="myscript.sh"

main()
{
    echo "Script was executed, running main..."
}

case "$0" in *$name)
    main "$@"
    ;;
esac

К сожалению, этот способ не работает из коробки в zsh из-за того, что опция functionargzero делает больше, чем предполагает ее название, и включена по умолчанию.

Чтобы обойти это, я поместил unsetopt functionargzero в свой .zshenv.

Я следовал компактному выражению mklement0.

Это здорово, но я заметил, что это может привести к сбою в случае ksh при вызове следующим образом:

/bin/ksh -c ./myscript.sh

(он думает, что это источник, а не потому, что он выполняет подоболочку) Но выражение будет работать, чтобы обнаружить это:

/bin/ksh ./myscript.sh

Кроме того, даже если выражение компактно, его синтаксис совместим не со всеми оболочками.

Итак, я закончил со следующим кодом, который работает для bash, zsh, dash и ksh.

SOURCED=0
if [ -n "$ZSH_EVAL_CONTEXT" ]; then 
    [[ $ZSH_EVAL_CONTEXT =~ :file$ ]] && SOURCED=1
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
    [[ $0 != "$BASH_SOURCE" ]] && SOURCED=1
elif grep -q dash /proc/$$/cmdline; then
    case $0 in *dash*) SOURCED=1 ;; esac
fi

Не стесняйтесь добавлять поддержку экзотических оболочек :)

Я не думаю, что есть какой-либо портативный способ сделать это как в ksh, так и в bash. В bash вы можете обнаружить это, используя вывод caller, но я не думаю, что в ksh существует эквивалент.

Мне нужен был однострочный вариант, который работает на [mac, linux] с bash.version >= 3, и ни один из этих ответов не подходит.

[[ ${BASH_SOURCE[0]} = $0 ]] && main "$@"

Прямо к делу: вы должны оценить, равна ли переменная "$0" имени вашей командной консоли.

Вот так:

#!/bin/bash

echo "First Parameter: $0"
echo
if [[ "$0" == "bash" ]] ; then
    echo "The script was sourced."
else
    echo "The script WAS NOT sourced."
fi

Через SHELL:

$ bash check_source.sh 
First Parameter: check_source.sh

The script WAS NOT sourced.

Через ИСТОЧНИК:

$ source check_source.sh
First Parameter: bash

The script was sourced.

Довольно сложно иметь 100% портативный способ определения того, был ли скрипт источником или нет.

Что касается моего опыта (7 лет с Shellscripting), единственный безопасный способ (не полагаться на переменные среды с PID и т. д., что небезопасно из-за того, что является чем-то ПЕРЕМЕННЫМ), вы должны:

• расширить возможности вашего if
• используя переключатель / регистр, если хотите.

Оба варианта не могут масштабироваться автоматически, но это более безопасный способ.

Например:

когда вы получаете сценарий через сеанс SSH, значение, возвращаемое переменной "$0" (при использовании источника), равно -bash.

#!/bin/bash

echo "First Parameter: $0"
echo
if [[ "$0" == "bash" || "$0" == "-bash" ]] ; then
    echo "The script was sourced."
else
    echo "The script WAS NOT sourced."
fi

#!/bin/bash

echo "First Parameter: $0"
echo
if [[ "$0" == "bash" ]] ; then
    echo "The script was sourced."
elif [[ "$0" == "-bash" ]] ; then
    echo "The script was sourced via SSH session."
else
    echo "The script WAS NOT sourced."
fi