У меня есть сценарий, в котором я не хочу, чтобы он вызывался, exitесли он получен.

Я подумал о том, чтобы проверить, $0 == bashесть ли проблемы, если сценарий получен из другого сценария или если пользователь получает его из другой оболочки, например ksh.

Есть ли надежный способ определить, что сценарий был получен?

Это похоже на переносимость между Bash и Korn:

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

Строка, аналогичная этой, или подобное присвоение pathname="$_"(с более поздним тестом и действием) должна находиться в первой строке скрипта или в строке после шебанга (который, если используется, должен быть для ksh, чтобы он работал в большинство обстоятельств).

Если ваша версия Bash знает о переменной массива BASH_SOURCE, попробуйте что-то вроде:

# 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 ..."

Надежные решения для bash, ksh,zsh , в том числе кросс-оболочка один, плюс достаточно надежный POSIX-совместимые решения :

• Приведенные номера версий - это те, на которых была проверена функциональность - вероятно, эти решения работают и на гораздо более ранних версиях - обратная связь приветствуется .

• Используя только функции POSIX (например, in dash, который действует как /bin/shв Ubuntu), не существует надежного способа определить, идет ли сценарий из источника - для получения наилучшего приближения см. Ниже .

Последующие строки - пояснение ниже; версия с несколькими оболочками сложна, но она должна работать надежно:

• bash (проверено в 3.57 и 4.4.19)

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

• ksh (проверено на 93u +)

  [[ $(cd "$(dirname -- "$0")" && 
     printf '%s' "${PWD%/}/")$(basename -- "$0") != "${.sh.file}" ]] &&
       sourced=1 || sourced=0

• zsh (проверено на 5.0.5) - обязательно вызовите это вне функции

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

• поперечная оболочка (bash, ksh, zsh)

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

• POSIX-совместимый ; не однострочный (однотрубный) по техническим причинам и не полностью устойчивый (см. внизу):

  sourced=0
  if [ -n "$ZSH_EVAL_CONTEXT" ]; 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|dash) sourced=1;; esac
  fi

Объяснение:

удар

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

^{Примечание: метод был адаптирован из ответа пользователя user5754163 , поскольку он оказался более надежным, чем исходное решение, [[ $0 != "$BASH_SOURCE" ]] && sourced=1 || sourced=0[1]}

• Bash допускает returnоператоры только из функций и, в области видимости верхнего уровня скрипта, только если источник скрипта получен .

  • Если returnиспользуется в области верхнего уровня сценария без источников , выдается сообщение об ошибке и устанавливается код выхода 1.

• (return 0 2>/dev/null)выполняется returnв подоболочке и подавляет сообщение об ошибке; затем код завершения указывает на то, был ли найденный скрипт ( 0) или нет ( 1), который используется с &&и ||операторов , чтобы установить sourcedпеременную , соответственно.

  • Использование подоболочки необходимо, потому что выполнение returnв области верхнего уровня сценария с исходным кодом приведет к его завершению.
  • ^{Наконечник шляпы @Haozhun , который сделал команду более устойчивой, явно используя 0в качестве returnоперанда; он отмечает: для каждой подсказки return [N]: «Если N опущено, возвращается статус последней команды». В результате более ранняя версия [которая использовалась просто return, без операнда] дает неверный результат, если последняя команда в оболочке пользователя имеет ненулевое возвращаемое значение.}

КШ

[[ \
   $(cd "$(dirname -- "$0")" && printf '%s' "${PWD%/}/")$(basename -- "$0") != \
   "${.sh.file}" \
]] && 
sourced=1 || sourced=0

Специальная переменная ${.sh.file}чем-то аналогична $BASH_SOURCE; обратите внимание, что это ${.sh.file}вызывает синтаксическую ошибку в bash, zsh и dash, поэтому обязательно выполняйте ее условно в сценариях с несколькими оболочками.

В отличие от bash, $0и ${.sh.file}НЕ гарантируется, что они будут точно идентичными в случае без источников, поскольку это $0может быть относительный путь, хотя ${.sh.file}он всегда является полным путем, поэтому $0перед сравнением должен быть разрешен полный путь.

ЗШ

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

$ZSH_EVAL_CONTEXTсодержит информацию о контексте оценки - вызывайте ее вне функции. Внутри исходного сценария [область верхнего уровня] $ZSH_EVAL_CONTEXT заканчивается на :file.

Оговорка: Внутри команды замены, ЗШ Присоединяет :cmdsubst, поэтому тест $ZSH_EVAL_CONTEXTна :file:cmdsubst$там.

Использование только функций POSIX

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

^{Раздел «Как обрабатывать вызовы из источника» в этом моем ответе обсуждает крайние случаи, которые не могут быть обработаны только с помощью функций POSIX.}

Это зависит от стандартного поведения $0, которое zsh, например, не демонстрирует.

Таким образом, самый безопасный подход состоит в том, чтобы объединить надежные, специфичные для оболочки методы, описанные выше, с запасным решением для всех оставшихся оболочек.

^{Наконечник шляпы Стефану Десне и его ответу за вдохновение (преобразование моего выражения оператора через оболочку в sh-совместимое ifвыражение и добавление обработчика для других оболочек).}

sourced=0
if [ -n "$ZSH_EVAL_CONTEXT" ]; 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|dash) sourced=1;; esac
fi

^{[1] user1902689 обнаружил, что [[ $0 != "$BASH_SOURCE" ]]дает ложное срабатывание, когда вы выполняете скрипт, расположенный в,$PATH путем передачи его простого имени файла в bashдвоичный файл; Например, bash my-scriptпотому что $0тогда справедливо my-script, тогда как $BASH_SOURCEэто полный путь . В то время как вы обычно не использовать этот метод для вызова скриптов в $PATH- вы бы просто ссылаться на них напрямую ( my-script) - это является полезным в сочетании с -xдля отладки .}

После прочтения ответа @ DennisWilliamson, есть некоторые проблемы, см. Ниже:

Как этот вопрос означает КШ и ударесть другая часть в этом ответе, касающаяся КШ... увидеть ниже.

просто удар путь

[ "$0" = "$BASH_SOURCE" ]

Давайте попробуем (на лету, потому что bash может ;-):

source <(echo $'#!/bin/bash
           [ "$0" = "$BASH_SOURCE" ] && v=own || v=sourced;
           echo "process $$ is $v ($0, $BASH_SOURCE)" ')
process 29301 is sourced (bash, /dev/fd/63)

bash <(echo $'#!/bin/bash
           [ "$0" = "$BASH_SOURCE" ] && v=own || v=sourced;
           echo "process $$ is $v ($0, $BASH_SOURCE)" ')
process 16229 is own (/dev/fd/63, /dev/fd/63)

sourceВместо этого я использую .для удобства чтения (как .псевдоним source):

. <(echo $'#!/bin/bash
           [ "$0" = "$BASH_SOURCE" ] && v=own || v=sourced;
           echo "process $$ is $v ($0, $BASH_SOURCE)" ')
process 29301 is sourced (bash, /dev/fd/63)

Обратите внимание, что номер процесса не меняется, пока процесс остается в источнике :

echo $$
29301

Почему бы не использовать $_ == $0сравнение

Для обеспечения многих случаев я начинаю писать настоящий скрипт:

#!/bin/bash

# As $_ could be used only once, uncomment one of two following lines

#printf '_="%s", 0="%s" and BASH_SOURCE="%s"\n' "$_" "$0" "$BASH_SOURCE"
[[ "$_" != "$0" ]] && DW_PURPOSE=sourced || DW_PURPOSE=subshell

[ "$0" = "$BASH_SOURCE" ] && BASH_KIND_ENV=own || BASH_KIND_ENV=sourced;
echo "proc: $$[ppid:$PPID] is $BASH_KIND_ENV (DW purpose: $DW_PURPOSE)"

Скопируйте это в файл с именем testscript:

cat >testscript   
chmod +x testscript

Теперь мы можем проверить:

./testscript 
proc: 25758[ppid:24890] is own (DW purpose: subshell)

Все нормально.

. ./testscript 
proc: 24890[ppid:24885] is sourced (DW purpose: sourced)

source ./testscript 
proc: 24890[ppid:24885] is sourced (DW purpose: sourced)

Все нормально.

Но для тестирования скрипта перед добавлением -xфлага:

bash ./testscript 
proc: 25776[ppid:24890] is own (DW purpose: sourced)

Или использовать предопределенные переменные:

env PATH=/tmp/bintemp:$PATH ./testscript 
proc: 25948[ppid:24890] is own (DW purpose: sourced)

env SOMETHING=PREDEFINED ./testscript 
proc: 25972[ppid:24890] is own (DW purpose: sourced)

Это больше не будет работать.

Перемещение комментария с 5-й строки на 6-ю даст более читаемый ответ:

./testscript 
_="./testscript", 0="./testscript" and BASH_SOURCE="./testscript"
proc: 26256[ppid:24890] is own

. testscript 
_="_filedir", 0="bash" and BASH_SOURCE="testscript"
proc: 24890[ppid:24885] is sourced

source testscript 
_="_filedir", 0="bash" and BASH_SOURCE="testscript"
proc: 24890[ppid:24885] is sourced

bash testscript 
_="/bin/bash", 0="testscript" and BASH_SOURCE="testscript"
proc: 26317[ppid:24890] is own

env FILE=/dev/null ./testscript 
_="/usr/bin/env", 0="./testscript" and BASH_SOURCE="./testscript"
proc: 26336[ppid:24890] is own

Сильнее: КШ сейчас...

Как я не пользуюсь КШ много, после некоторого прочтения на странице руководства, есть мои попытки:

#!/bin/ksh

set >/tmp/ksh-$$.log

Скопируйте это в testfile.ksh:

cat >testfile.ksh
chmod +x testfile.ksh

Чем запустить его два раза:

./testfile.ksh
. ./testfile.ksh

ls -l /tmp/ksh-*.log
-rw-r--r-- 1 user user   2183 avr 11 13:48 /tmp/ksh-9725.log
-rw-r--r-- 1 user user   2140 avr 11 13:48 /tmp/ksh-9781.log

echo $$
9725

и увидеть:

diff /tmp/ksh-{9725,9781}.log | grep ^\> # OWN SUBSHELL:
> HISTCMD=0
> PPID=9725
> RANDOM=1626
> SECONDS=0.001
>   lineno=0
> SHLVL=3

diff /tmp/ksh-{9725,9781}.log | grep ^\< # SOURCED:
< COLUMNS=152
< HISTCMD=117
< LINES=47
< PPID=9163
< PS1='$ '
< RANDOM=29667
< SECONDS=23.652
<   level=1
<   lineno=1
< SHLVL=2

Существует некоторая переменная, унаследованная в исходном цикле, но ничего действительно не связанная ...

Вы могли бы даже проверить, что $SECONDSблизко 0.000, но это гарантирует только ручные источники ...

Вы даже можете попытаться проверить, кто является родителем:

Поместите это в свой testfile.ksh:

ps $PPID

чем:

./testfile.ksh
  PID TTY      STAT   TIME COMMAND
32320 pts/4    Ss     0:00 -ksh

. ./testfile.ksh
  PID TTY      STAT   TIME COMMAND
32319 ?        S      0:00 sshd: user@pts/4

или ps ho cmd $PPID, но эта работа только для одного уровня subsessions ...

Извините, я не мог найти надежный способ сделать это, под КШ,

BASH_SOURCE[]Ответ (Баш-3,0 и выше) кажется простым, хотя BASH_SOURCE[]это не документирован для работы вне тела функции (это в настоящее время происходит на работу, в несогласии со страницей человека).

Самый надежный способ, как предлагает Wirawan Purwanto, - это проверка 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дисциплины и некоторые хитрости для отладки ловушек для эмуляции FUNCNAMEмассива bash .)

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

Ноты:

• Можно создать функции bash с именами «main» и «source» ( переопределяя встроенные функции ), в которых эти имена могут появляться, 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. IE это не удается для bashv3.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).

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

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

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

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

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

  • BASH_SOURCEявляется Баш зарезервирован массив . Но разрешение BASH_SOURCE=".$0"изменить его открыло бы очень опасную банку червей, поэтому я ожидаю, что это не должно иметь никакого эффекта (за исключением, возможно, какого-то ужасного предупреждения, которое появится в какой-то будущей версии bash).
  • Нет документации, которая бы BASH_SOURCEработала вне функций. Однако обратное (то, что он работает только в функциях) не задокументировано. Наблюдение состоит в том, что это работает (протестировано с bashv4.3 и v4.4, к сожалению, у меня больше нет bashv3.x), и что слишком много сценариев сломалось бы, если $BASH_SOURCEперестало работать, как наблюдалось. Следовательно, я ожидаю, что она BASH_SOURCEостанется такой же и для будущих версий bash.
  • В отличие от (хорошая находка, кстати!) Рассмотрим ( return 0 ), что дает, 0если получены и 1если не получены. Это приходит немного неожиданно не только для меня , и (согласно показаниям там) POSIX говорит, что returnот subshell есть неопределенное поведение (а 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__'

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

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

Обеспечивая выполнение сценария /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

или

[ $(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"

потому что [[не распознается (несколько анального удерживающий ИМХО) Debian POSIX совместимой оболочкой, 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

Через ОБОЛОЧКУ :

$ 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

Я закончил с проверкой [[ $_ == "$(type -p "$0")" ]]

if [[ $_ == "$(type -p "$0")" ]]; then
    echo I am invoked from a sub shell
else
    echo I am invoked from a source command
fi

При использовании curl ... | bash -s -- ARGSдля запуска удаленного сценария «на лету», $ 0 будет просто bashвместо обычного /bin/bashпри запуске реального файла сценария, поэтому я использую, type -p "$0"чтобы показать полный путь bash.

тест:

curl -sSL https://github.com/jjqq2013/bash-scripts/raw/master/common/relpath | bash -s -- /a/b/c/d/e /a/b/CC/DD/EE

source <(curl -sSL https://github.com/jjqq2013/bash-scripts/raw/master/common/relpath)
relpath /a/b/c/d/e /a/b/CC/DD/EE

wget https://github.com/jjqq2013/bash-scripts/raw/master/common/relpath
chmod +x relpath
./relpath /a/b/c/d/e /a/b/CC/DD/EE

Это ответ на некоторые другие ответы, касающиеся «универсальной» поддержки кросс-оболочек. По общему признанию это очень похоже на https://stackoverflow.com/a/2942183/3220983 в частности, хотя немного отличается. Недостатком этого является то, что клиентский скрипт должен учитывать, как его использовать (т.е. сначала экспортировать переменную). Сила в том, что это просто и должно работать "где угодно". Вот шаблон для вашего удовольствия:

# NOTE: This script may be used as a standalone executable, or callable library.
# To source this script, add the following *prior* to including it:
# export ENTRY_POINT="$0"

main()
{
    echo "Running in direct executable context!"
}

if [ -z "${ENTRY_POINT}" ]; then main "$@"; fi

Примечание: я использую exportтолько для того, чтобы этот механизм можно было распространить на подпроцессы.