我有一个脚本,我不希望它调用退出,如果它是来源。
我想检查是否$0 == bash,但这有问题,如果脚本是从另一个脚本,或者如果用户从不同的shell,如ksh源。
是否有一种可靠的方法来检测脚本是否被引用?
我有一个脚本,我不希望它调用退出,如果它是来源。
我想检查是否$0 == bash,但这有问题,如果脚本是从另一个脚本,或者如果用户从不同的shell,如ksh源。
是否有一种可靠的方法来检测脚本是否被引用?
当前回答
bash, ksh, zsh的健壮解决方案,包括一个跨shell解决方案,以及一个相当健壮的posix兼容解决方案:
给出的版本号是验证功能的版本号——很可能,这些解决方案也适用于更早的版本——欢迎反馈。 仅使用POSIX特性(例如在dash中,它在Ubuntu中充当/bin/sh),没有可靠的方法来确定脚本是否被引用-请参阅下面的最佳近似方法。
重要的是:
The solutions determine whether the script is being sourced by its caller, which may be a shell itself or another script (which may or may not be sourced itself): Also detecting the latter case adds complexity; if you do not need to detect the case when your script is being sourced by another script, you can use the following, relatively simple POSIX-compliant solution: # Helper function is_sourced() { if [ -n "$ZSH_VERSION" ]; then case $ZSH_EVAL_CONTEXT in *:file:*) return 0;; esac else # Add additional POSIX-compatible shell names here, if needed. case ${0##*/} in dash|-dash|bash|-bash|ksh|-ksh|sh|-sh) return 0;; esac fi return 1 # NOT sourced. } # Sample call. is_sourced && sourced=1 || sourced=0 All solutions below must run in the top-level scope of your script, not inside functions.
下面是一行程序——解释如下;跨shell版本是复杂的,但它应该可以健壮地工作:
Bash(在3.57、4.4.19和5.1.16上验证)
(return 0 2>/dev/null) && sourced=1 || sourced=0
KSH(在93u+上验证)
[[ "$(cd -- "$(dirname -- "$0")" && pwd -P)/$(basename -- "$0")" != "$(cd -- "$(dirname -- "${.sh.file}")" && pwd -P)/$(basename -- "${.sh.file}")" ]] && sourced=1 || sourced=0
ZSH(5.0.5验证)
[[ $ZSH_EVAL_CONTEXT =~ :file$ ]] && sourced=1 || sourced=0
交叉shell (bash, ksh, zsh)
(
[[ -n $ZSH_VERSION && $ZSH_EVAL_CONTEXT =~ :file$ ]] ||
[[ -n $KSH_VERSION && "$(cd -- "$(dirname -- "$0")" && pwd -P)/$(basename -- "$0")" != "$(cd -- "$(dirname -- "${.sh.file}")" && pwd -P)/$(basename -- "${.sh.file}")" ]] ||
[[ -n $BASH_VERSION ]] && (return 0 2>/dev/null)
) && sourced=1 || sourced=0
posix兼容;由于技术原因,不是一行程序(单一管道),并且不完全健壮(见底部):
sourced=0
if [ -n "$ZSH_VERSION" ]; 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|-sh|dash|-dash) sourced=1;; esac
fi
解释
bash
(return 0 2>/dev/null) && sourced=1 || sourced=0
注意:该技术改编自user5754163的答案,因为它比原来的解决方案更健壮,[[$0 != "$BASH_SOURCE"]] && sourced=1 || sourced=0[1]
Bash allows return statements only from functions and, in a script's top-level scope, only if the script is sourced. If return is used in the top-level scope of a non-sourced script, an error message is emitted, and the exit code is set to 1. (return 0 2>/dev/null) executes return in a subshell and suppresses the error message; afterwards the exit code indicates whether the script was sourced (0) or not (1), which is used with the && and || operators to set the sourced variable accordingly. Use of a subshell is necessary, because executing return in the top-level scope of a sourced script would exit the script. Tip of the hat to @Haozhun, who made the command more robust by explicitly using 0 as the return operand; he notes: per bash help of return [N]: "If N is omitted, the return status is that of the last command." As a result, the earlier version [which used just return, without an operand] produces incorrect result if the last command on the user's shell has a non-zero return value.
ksh
[[ "$(cd -- "$(dirname -- "$0")" && pwd -P)/$(basename -- "$0")" != "$(cd -- "$(dirname -- "${.sh.file}")" && pwd -P)/$(basename -- "${.sh.file}")" ]] && sourced=1 || sourced=0
特殊变量${.sh。file}有点类似于$BASH_SOURCE;注意${.sh。File}会在bash、zsh和dash中导致语法错误,所以一定要在多shell脚本中有条件地执行它。
与bash不同,$0和${.sh。file}不能保证是相同的-在不同的时候,一个可能是相对路径或仅仅是文件名,而另一个可能是完整的文件名;因此,$0和${.sh。File}在比较之前必须解析为全路径。如果完整路径不同,则隐含了源。
zsh
[[ $ZSH_EVAL_CONTEXT =~ :file$) ]] && sourced=1 || sourced=0
$ZSH_EVAL_CONTEXT包含关于计算上下文:子字符串文件的信息,用:分隔,只有在脚本被引用时才会出现。
在源脚本的顶级作用域中,$ZSH_EVAL_CONTEXT以:file结尾,这就是这个测试的限制。在函数内部,:shfunc被追加到:file;在命令替换中追加:cmdsubst。
仅使用POSIX特性
如果您愿意做出某些假设,那么您可以根据可能正在执行脚本的shell的二进制文件名,对脚本是否被引用做出合理但并非万无一错的猜测。 值得注意的是,这意味着当您的脚本被另一个脚本引用时,这种方法不会检测到这种情况。
本回答中的“如何处理源调用”一节只详细讨论了POSIX特性无法处理的边缘情况。
检查二进制文件名依赖于$0的标准行为,例如,zsh就没有这种行为。
因此,最安全的方法是将上述健壮的、特定于shell的方法(不依赖于$0)与所有剩余shell的基于$0的回退解决方案结合起来。
简而言之:解决方案如下:
在包含特定于shell的测试的shell中:稳定地工作。 在所有其他shell中:仅当脚本直接来自这样的shell(而不是来自另一个脚本)时才能正常工作。
向Stéphane Desneux和他的灵感答案致敬(将我的跨shell语句表达式转换为sh兼容的if语句,并为其他shell添加一个处理程序)。
sourced=0
if [ -n "$ZSH_VERSION" ]; 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|-sh|dash|-dash) sourced=1;; esac
fi
注意,为了健壮性,每个shell二进制文件名(例如sh)都表示了两次——一次是原样,第二次是,前缀是-。这是为了考虑诸如macOS这样的环境,其中交互式shell作为登录shell启动,其自定义值为$0,该值是前缀为-的(无路径)shell文件名。谢谢,t7e。 (虽然sh和dash可能不太可能用作交互式shell,但您可能需要将其他shell添加到列表中。)
[1] user1902689发现[[$0 != "$BASH_SOURCE"]]在通过将其文件名传递给bash二进制文件执行位于$PATH中的脚本时,会产生假阳性;例如,bash my-script,因为$0只是my-script,而$BASH_SOURCE是完整路径。虽然您通常不会使用这种技术来调用$PATH中的脚本—您只会直接调用它们(my-script)—当与-x结合使用时,它对调试很有帮助。
其他回答
我最终检查[[$_ == "$(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运行实际的脚本文件,所以我使用-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
这似乎在Bash和Korn之间是可移植的:
[[ $_ != $0 ]] && echo "Script is being sourced" || echo "Script is a subshell"
与此类似的行或赋值语句如pathname="$_"(带有稍后的测试和操作)必须位于脚本的第一行或shebang之后的行(如果使用了shebang,则应该用于ksh,以便它在大多数情况下工作)。
我认为在ksh和bash中没有任何可移植的方法来做到这一点。在bash中,您可以使用调用器输出来检测它,但我认为ksh中不存在等效的输出。
看了@DennisWilliamson的回答后,有一些问题,如下所示:
因为这个问题代表ksh和bash,所以这个答案中还有一个关于ksh的部分…见下文。
简单的bash方式
[ "$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代替off。对于可读性(如。是源的别名):
. <(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
更难:ksh现在…
由于我不经常使用ksh,在阅读了一些手册页后,有我的尝试:
#!/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,但这是为了确保只有手工来源的情况……
你甚至可以试着检查parent是什么:
把它放在你的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,但这只适用于一个级别的子会话…
对不起,我找不到一个可靠的方法来做,在ksh下。
BASH_SOURCE[]的答案(bash-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")'
This is the equivalent to checking the output of caller, the values main and source distinguish the caller's context. Using FUNCNAME[] saves you capturing and parsing caller output. You need to know or calculate your local call depth to be correct though. Cases like a script being sourced from within another function or script will cause the array (stack) to be deeper. (FUNCNAME is a special bash array variable, it should have contiguous indexes corresponding to the call stack, as long as it is never unset.)
function issourced() {
[[ ${FUNCNAME[@]: -1} == "source" ]]
}
(在bash-4.2及以后版本中,可以使用更简单的形式${FUNCNAME[-1]}来代替数组中的最后一项。感谢Dennis Williamson下面的评论,改进和简化了。)
然而,你的问题如所述是“我有一个脚本,我不希望它调用'退出',如果它是来源”。这种情况下常见的bash习惯用法是:
return 2>/dev/null || exit
如果脚本是源脚本,则return将终止源脚本并返回给调用者。
如果脚本正在执行,那么return将返回一个错误(重定向),exit将正常终止脚本。如果需要,return和exit都可以使用退出码。
遗憾的是,这在ksh中不起作用(至少在我这里的AT&T派生版本中不起作用),如果在函数或点源脚本外部调用return,它将return视为等同于exit。
更新:在当前版本的ksh中,您可以检查特殊变量.sh。设置为函数调用深度的级别。对于一个被调用的脚本,它最初将被取消设置,对于一个点源脚本,它将被设置为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还提供了$-作为shell状态的另一个指示器(尽管并不完善)。
注:
可以创建名为“main”和“source”的bash函数(覆盖内置),这些名称可能出现在FUNCNAME[]中,但只要只测试该数组中的最后一项,就不会有歧义。 我对pdksh没有一个好的答案。我能找到的最接近的方法只适用于pdksh,其中脚本的每个源都打开一个新的文件描述符(原始脚本从10开始)。几乎肯定不是你想要依靠的东西……