当出现警告或错误时我应该输出程序的名称吗?

当出现警告或错误时我应该输出程序的名称吗?

如果我正在编写脚本或程序,我是否应该将其名称与警告或错误消息一起输出到 stderr?例如:

./script.sh: Warning! Variable "var" lowered down to 10.

或者:

./prog.py: Error! No such file: "file.cfg".

我知道这通常只是一个品味问题(特别是如果你为自己编写自己的东西),但我想知道这是否有什么传统的东西?我相信大多数 UNIX/Linux 实用程序在发生事情时都会写下它们的名字,所以这似乎是一件好事,但是是否有任何指导方针或潜规则如何做到这一点以及如何不这样做?

例如,不建议将二进制文件安装在 下/usr/bin/,而是安装在/usr/local/bin/或其他位置下。关于输出到 stderr 是否有类似的规则?我应该写名字后跟冒号吗?或者只是“警告!”和“错误!”字?我找不到任何东西,但也许有人可以指出我在哪里可以阅读相关内容。

这个问题有点关于编程实践,但我认为在这里比在上面更合适堆栈溢出,因为它是关于 UNIX/Linux 传统而不是一般的编程。

答案1

通常的做法是保存0号传递给 C 程序的参数并将其用作简单程序main的参数:perror

#include <stdio.h>
#include <stdlib.h>

int main(int argc, char *argv[])
{
    char *foo = malloc(9999999999L);
    if (foo == 0)
        perror(argv[0]);
    return 0;
}

将该程序称为“foo”,并运行它说明了这一点:

> ./foo
./foo: Cannot allocate memory

复杂的程序可能会添加到文本中(或仅使用文件名而不使用路径),但保留程序名称可以让您找到行为不当的程序的来源。

错误消息没有普遍接受的方案,但一些广泛使用的程序(例如 gcc)添加了消息类别,例如“错误”或“警告”。这是我的构建日志之一的示例:

compiling fld_def (obj_s)
../form/fld_def.c: In function '_nc_Copy_Argument':
../form/fld_def.c:164:14: warning: cast discards 'const' qualifier from pointer target type [-Wcast-qual]
        res = (TypeArgument *)argp;
              ^

在此示例中,gcc 使用冒号分隔字段,并在文件名、行号、列号之后以及实际消息之前添加类别“警告”。但有几种变体,使得程序变得复杂(例如类似 vi 的 emacs)来解析信息。

对于编译器,使用类别消息中的内容使得检测致命错误(可能不是立即致命)和警告。如果你的程序因错误而退出,这并不能说明有些是真正的警告,有些是错误。但是,当它的行为不同(或或多或少继续工作)时,该类别有助于诊断遇到的问题。

答案2

如果一个程序作为调用许多其他程序的脚本的一部分被调用,并且如果它不打印其名称,那么用户将很难找出错误来自何处。

(如果错误是一些可能需要调试的意外内部情况,您需要更多信息:不仅仅是程序名称,还有源文件和行号,可能还有回溯。)

相关内容