如何定义要获取的Shell脚本无法运行

我正在定义用户应该source而不是执行的shell脚本。

是否有常规或智能的方式来提示用户这种情况，例如通过文件扩展名？

我是否可以在文件本身中编写外壳代码，这将导致该文件回显消息并在执行而不是源代码时退出，以便我可以帮助用户避免这一明显的错误？

假设您正在运行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]}将包含shell正在读取的当前文件的名称，而不管它是源文件还是执行文件。

相反，$0是正在执行的当前文件的名称。

-ef测试这两个文件是否为同一文件。如果是这样，我们会提醒用户并退出。

无论是-ef也不BASH_SOURCE是POSIX。虽然-ef由ksh，yash，zsh和Dash支持，但BASH_SOURCE需要bash。 在zsh，然而，${BASH_SOURCE[0]}可能被替换${(%):-%N}。

不可执行的文件可以被获取但不能执行，因此，作为第一道防线，不设置可执行标志应该是一个很好的提示...

编辑：我偶然发现的把戏：使shebang成为不是shell解释器的任何可执行文件，/bin/false使脚本返回错误（rc！= 0）

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

此Stack Overflow帖子中建议了几种方法，其中，我最喜欢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除非正在获取文件，否则函数外部的退出代码为非零。

当您获取shell脚本时，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行有助于编辑器中的文件类型检测并指定shell脚本方言，因此甚至有好处）。不利之处是有些不清楚的错误消息，或者（一次性）添加了另一个shell脚本。

但是，它不会阻止通过显式调用bash path/to/script.sh（感谢@muru！）。