Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
The community reviewed whether to reopen this question 2 years ago and left it closed:
Original close reason(s) were not resolved
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
接受
或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论(15)
使用陷阱并不总是一种选择。 例如,如果您正在编写某种需要错误处理并且可以从任何脚本调用的可重用函数(在使用辅助函数获取文件之后),则该函数不能假设有关外部脚本的退出时间的任何信息,这使得使用陷阱变得非常困难。 使用陷阱的另一个缺点是可组合性差,因为您可能会覆盖调用者链中较早设置的先前陷阱。
有一个小技巧可以用来在没有陷阱的情况下进行正确的错误处理。 正如您可能已经从其他答案中知道的那样,如果您在命令后使用
||
运算符,则set -e
无法在命令内工作,即使您在子 shell 中运行它们也是如此; 例如,这不起作用:但是需要
||
运算符来防止在清理之前从外部函数返回。 诀窍是在后台运行内部命令,然后立即等待它。wait
内置函数将返回内部命令的退出代码,现在您在wait
之后使用||
,而不是内部函数,所以set -e
在后者中可以正常工作:这是建立在这个想法之上的通用函数。 如果您删除
local
关键字,即仅用x=y
替换所有local x=y
,它应该可以在所有 POSIX 兼容 shell 中工作:示例用法:
运行示例:
使用此方法时唯一需要注意的是,通过传递给
run
的命令对 Shell 变量进行的所有修改都不会传播到调用函数,因为该命令在子 shell 中运行。Using trap is not always an option. For example, if you're writing some kind of re-usable function that needs error handling and that can be called from any script (after sourcing the file with helper functions), that function cannot assume anything about exit time of the outer script, which makes using traps very difficult. Another disadvantage of using traps is bad composability, as you risk overwriting previous trap that might be set earlier up in the caller chain.
There is a little trick that can be used to do proper error handling without traps. As you may already know from other answers,
set -e
doesn't work inside commands if you use||
operator after them, even if you run them in a subshell; e.g., this wouldn't work:But
||
operator is needed to prevent returning from the outer function before cleanup. The trick is to run the inner command in background, and then immediately wait for it. Thewait
builtin will return the exit code of the inner command, and now you're using||
afterwait
, not the inner function, soset -e
works properly inside the latter:Here is the generic function that builds upon this idea. It should work in all POSIX-compatible shells if you remove
local
keywords, i.e. replace alllocal x=y
with justx=y
:Example of usage:
Running the example:
The only thing that you need to be aware of when using this method is that all modifications of Shell variables done from the command you pass to
run
will not propagate to the calling function, because the command runs in a subshell.这个函数最近对我很有用:
您可以通过将 0 或最后一个返回值附加到要运行的命令的名称来调用它,这样您就可以链接命令而无需检查错误值。 这样,该语句块:
变为:
如果任何命令失败,则错误代码将简单地传递到块的末尾。 我发现当您不希望在前一个命令失败时执行后续命令,但您也不希望脚本立即退出(例如,在循环内)时,它很有用。
This function has been serving me rather well recently:
You call it by appending 0 or the last return value to the name of the command to run, so you can chain commands without having to check for error values. With this, this statement block:
Becomes this:
If any of the commands fail, the error code is simply passed to the end of the block. I find it useful when you don't want subsequent commands to execute if an earlier one failed, but you also don't want the script to exit straight away (for example, inside a loop).
不确定这是否对您有帮助,但我在这里修改了一些建议的函数,以便在其中包含对错误(先前命令的退出代码)的检查。
在每次“检查”时,我还将错误的“消息”作为参数传递以用于记录目的。
则在另一个脚本中调用它),我只需编写函数的名称并传递一条消息作为参数,如下所示:
现在,要在同一个脚本中调用它(如果我使用export -f error_exit , 能够为某些自动化过程创建一个非常强大的 bash 文件,并且在出现错误时它将停止并通知我(
log.sh
会做到这一点)Not sure if this will be helpful to you, but I modified some of the suggested functions here in order to include the check for the error (exit code from prior command) within it.
On each "check" I also pass as a parameter the "message" of what the error is for logging purposes.
Now to call it within the same script (or in another one if I use
export -f error_exit
) I simply write the name of the function and pass a message as parameter, like this:Using this I was able to create a really robust bash file for some automated process and it will stop in case of errors and notify me (
log.sh
will do that)这个技巧对于丢失命令或函数很有用。 缺少的函数(或可执行文件)的名称将在 $_ 中传递
This trick is useful for missing commands or functions. The name of the missing function (or executable) will be passed in $_
有时
set -e
、trap ERR
、set -o
、set -o pipelinefail
和set - o errtrace
无法正常工作,因为它们尝试向 shell 添加自动错误检测。 这在实践中效果并不好。在我看来,您应该编写自己的错误检查代码,而不是使用 set -e 和其他东西。 如果您明智地使用
set -e
,请注意潜在的问题。为了避免运行代码时出现错误,您可以使用
exec 1>/dev/null
或exec 2>/dev/null
Linux中的
/dev/null
是一个空设备文件。 这将丢弃写入其中的任何内容,并在读取时返回 EOF。 您可以在命令末尾使用它对于
try/catch
,您可以使用&&
或||
来实现类似的行为使用可以使用 && 像这样
或者你可以使用
if else
:$?
显示最后一个命令的输出,它返回 1 或 0Sometimes
set -e
,trap ERR
,set -o
,set -o pipefail
andset -o errtrace
not work properly because they attempt to add automatic error detection to the shell. This does not work well in practice.In my opinion, instead of using
set -e
and other stuffs, you should write your own error checking code. If you wise to useset -e
, be aware of potential gotchas.To avoid Error while running the code you can use
exec 1>/dev/null
orexec 2>/dev/null
/dev/null
in Linux is a null device file. This will discard anything written to it and will return EOF on reading. you can use this at end of the commandFor
try/catch
you can use&&
or||
to achieve Similar behaviouruse can use && like this
or you can use
if else
:$?
show output of the last command ,it return 1 or 0这已经为我服务了一段时间了。 它以红色打印错误或警告消息,每个参数一行,并允许可选的退出代码。
This has served me well for a while now. It prints error or warning messages in red, one line per parameter, and allows an optional exit code.
我以前用过
; 我想是因为“退出”由于某种原因对我来说失败了。 不过,上述默认值似乎是个好主意。
I've used
before; i think because 'exit' was failing for me for some reason. The above defaults seem like a good idea, though.
另一个考虑因素是要返回的退出代码。 尽管有一些,但“
1
”是相当标准的bash 本身使用的保留退出代码,同一页面认为用户定义的代码应该在 64-113 范围内以符合 C/C++ 标准。您还可以考虑
mount
用于退出代码的位向量方法:OR
将代码组合在一起允许您的脚本发出多个同时发生的错误信号。Another consideration is the exit code to return. Just "
1
" is pretty standard, although there are a handful of reserved exit codes that bash itself uses, and that same page argues that user-defined codes should be in the range 64-113 to conform to C/C++ standards.You might also consider the bit vector approach that
mount
uses for its exit codes:OR
-ing the codes together allows your script to signal multiple simultaneous errors.我使用以下陷阱代码,它还允许通过管道和“时间”命令跟踪错误
I use the following trap code, it also allows errors to be traced through pipes and 'time' commands
我更喜欢真正容易调用的东西。 所以我用的东西看起来有点复杂,但是很容易使用。 我通常只是将下面的代码复制并粘贴到我的脚本中。 代码后面有解释。
我通常会在 error_exit 函数中调用 cleanup 函数,但这因脚本而异,所以我将其省略。 陷阱捕获常见的终止信号并确保所有内容都得到清理。 别名才是真正的魔力。 我喜欢检查一切是否失败。 所以一般来说我用“if!”来称呼程序。 类型声明。 通过从行号中减去 1,别名将告诉我故障发生在哪里。 调用起来也非常简单,而且几乎是白痴证明。 下面是一个示例(只需将 /bin/false 替换为您要调用的任何内容)。
I prefer something really easy to call. So I use something that looks a little complicated, but is easy to use. I usually just copy-and-paste the code below into my scripts. An explanation follows the code.
I usually put a call to the cleanup function in side the error_exit function, but this varies from script to script so I left it out. The traps catch the common terminating signals and make sure everything gets cleaned up. The alias is what does the real magic. I like to check everything for failure. So in general I call programs in an "if !" type statement. By subtracting 1 from the line number the alias will tell me where the failure occurred. It is also dead simple to call, and pretty much idiot proof. Below is an example (just replace /bin/false with whatever you are going to call).
受到此处提出的想法的启发,我开发了一种可读且方便的方法来处理 中的 bash 脚本中的错误bash 样板项目。
通过简单地获取该库,您可以立即得到以下内容(即,它将在出现任何错误时停止执行,就像使用
set -e
一样,这要归功于trap
上的trap
code>ERR 和一些 bash-fu):还有一些额外的功能可以帮助处理错误,例如 try 和 catch 或 throw 关键字,它们允许您在某个点中断执行以查看回溯。 另外,如果终端支持它,它会输出电力线表情符号,对输出的部分进行着色以提高可读性,并在代码行上下文中强调导致异常的方法。
缺点是 - 它不可移植 - 代码可以在 bash 中运行,可能只能 >= 4 (但我想它可以通过一些努力移植到 bash 3)。
为了更好地处理,代码被分成多个文件,但我受到了 的回溯想法的启发Luca Borrione 的上述答案。
要了解更多信息或查看源代码,请参阅 GitHub:
https://github.com/niieani/bash-oo-framework#error-handling-with-exceptions-and-throw
Inspired by the ideas presented here, I have developed a readable and convenient way to handle errors in bash scripts in my bash boilerplate project.
By simply sourcing the library, you get the following out of the box (i.e. it will halt execution on any error, as if using
set -e
thanks to atrap
onERR
and some bash-fu):There are some extra features that help handle errors, such as try and catch, or the throw keyword, that allows you to break execution at a point to see the backtrace. Plus, if the terminal supports it, it spits out powerline emojis, colors parts of the output for great readability, and underlines the method that caused the exception in the context of the line of code.
The downside is - it's not portable - the code works in bash, probably >= 4 only (but I'd imagine it could be ported with some effort to bash 3).
The code is separated into multiple files for better handling, but I was inspired by the backtrace idea from the answer above by Luca Borrione.
To read more or take a look at the source, see GitHub:
https://github.com/niieani/bash-oo-framework#error-handling-with-exceptions-and-throw
“set -e”的等效替代方法是
它使标志的含义比“-e”更清晰。
随机添加:要暂时禁用该标志,并返回到默认值(无论退出代码如何都继续执行),只需使用
这会排除其他响应中提到的正确错误处理,但速度很快 有效(就像 bash 一样)。
An equivalent alternative to "set -e" is
It makes the meaning of the flag somewhat clearer than just "-e".
Random addition: to temporarily disable the flag, and return to the default (of continuing execution regardless of exit codes), just use
This precludes proper error handling mentioned in other responses, but is quick & effective (just like bash).
使用陷阱!
...然后,每当您创建临时文件时:
和
$temp_foo
将在退出时被删除,并且将打印当前行号。 (set -e
同样会给你错误退出行为,尽管它来了有严重的警告并削弱了代码的可预测性和可移植性)。您可以让陷阱为您调用
error
(在这种情况下,它使用默认退出代码 1 并且没有消息),也可以自己调用它并提供显式值; 例如:将以状态 2 退出,并给出明确的消息。
或者
shopt -s extdebug
并对陷阱的第一行进行一些修改,以全面捕获所有非零退出代码(注意set -e
non-error non -零退出代码):这也与
set -eu
“兼容”。Use a trap!
...then, whenever you create a temporary file:
and
$temp_foo
will be deleted on exit, and the current line number will be printed. (set -e
will likewise give you exit-on-error behavior, though it comes with serious caveats and weakens code's predictability and portability).You can either let the trap call
error
for you (in which case it uses the default exit code of 1 and no message) or call it yourself and provide explicit values; for instance:will exit with status 2, and give an explicit message.
Alternatively
shopt -s extdebug
and give the first lines of the trap a little modification to trap all non-zero exit codes across the board (mindset -e
non-error non-zero exit codes):This then is also "compatible" with
set -eu
.这是一个很好的解决方案。 我只是想添加
一个基本的错误机制。 如果一个简单的命令失败,它将立即停止您的脚本。 我认为这应该是默认行为:因为此类错误几乎总是意味着意外的事情,所以继续执行以下命令并不是真正的“理智”。
That's a fine solution. I just wanted to add
as a rudimentary error mechanism. It will immediately stop your script if a simple command fails. I think this should have been the default behavior: since such errors almost always signify something unexpected, it is not really 'sane' to keep executing the following commands.
阅读本页上的所有答案给了我很多启发。
所以,这是我的提示:
文件内容:lib.trap.sh
使用示例:
文件内容:trap-test.sh
运行:
输出:
正如您从下面的屏幕截图中看到的,输出是彩色的,并且错误消息以所使用的语言显示。
Reading all the answers on this page inspired me a lot.
So, here's my hint:
file content: lib.trap.sh
Example of usage:
file content: trap-test.sh
Running:
Output:
As you can see from the screenshot below, the output is colored and the error message comes in the used language.