Как определить сценарий оболочки, который не запускается

Я определяю сценарий оболочки, который пользователь должен sourceвыполнять, а не выполнять.

Есть ли обычный или интеллектуальный способ намека пользователю, что это так, например, с помощью расширения файла?

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

Предполагая, что вы запускаете bash, поместите следующий код в начало скрипта, который вы хотите получить, но не выполняете:

if [ "${BASH_SOURCE[0]}" -ef "$0" ]
then
    echo "Hey, you should source this script, not execute it!"
    exit 1
fi

В разделе bash ${BASH_SOURCE[0]}будет содержаться имя текущего файла, который читает оболочка, независимо от того, был ли он получен или выполнен.

Напротив, $0это имя текущего исполняемого файла.

-efпроверяет, являются ли эти два файла одним файлом Если они есть, мы предупреждаем пользователя и завершаем работу.

Ни POSIX, -efни BASH_SOURCEесть. Хотя -efподдерживается ksh, yash, zsh и Dash, BASH_SOURCEтребуется bash. Вzsh , однако, ${BASH_SOURCE[0]}может быть заменено на ${(%):-%N}.

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

Edit: трюк, на который я только что наткнулся: сделать shebang любым исполняемым файлом, который не является интерпретатором оболочки, /bin/falseзаставляет скрипт возвращать ошибку (rc! = 0)

#!/bin/false "This script should be sourced in a shell, not executed directly"

В этом сообщении о переполнении стека предлагается несколько методов , из которых мне больше всего понравился метод на основе функций, предложенный Wirawan Purwanto и mr.spuratic :

Самый надежный способ, как предлагает 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 check()
{
    if [[ ${FUNCNAME[-1]} != "source" ]]   # bash 4.2+, use ${FUNCNAME[@]: -1} for older
    then
        printf "Usage: source %s\n" "$0"
        exit 1
    fi
}
check

Предполагая, что выполнение сценария просто бесполезно, а не вредно, вы можете добавить

return 0 || printf 'Must be sourced, not executed\n' >&2

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

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

#!/bin/bash source-this-script
# ...

Сообщение об ошибке будет таким:

/bin/bash: source-this-script: No such file or directory

(Произвольное) имя аргумента уже дает строгую подсказку, но сообщение об ошибке все еще не ясно на 100%. Мы можем исправить это с помощью служебного скрипта, source-this-scriptкоторый находится где-то в вашем PATH:

#!/bin/sh
echo >&2 "This script must be sourced, not executed${1:+: }${1:-!}"
exit 1

Теперь сообщение об ошибке будет таким:

This script must be sourced, not executed: path/to/script.sh

Сравнение с другими подходами

По сравнению с другими ответами этот подход требует лишь минимальных изменений в каждом сценарии (а наличие строки shebang помогает в обнаружении типа файла в редакторах и определяет диалект сценария оболочки, так что есть даже преимущества). Недостатком является несколько неясное сообщение об ошибке или (одноразовое) добавление другого сценария оболочки.

Это не мешает явному вызову через bash path/to/script.sh, хотя (спасибо @muru!).