☰

接受截断的长命令行选项背后的原因是什么？

tag-icon • tag-icon command-line options user-experience
接受截断的长命令行选项背后的原因是什么？

许多命令行实用程序接受长（“GNU 风格”，根据 [1]）选项，例如--version.令我惊讶的是，截断的版本通常被解释为完整的选项。例如，dfGNU Coreutils 给出

user@computer ~ $ df --version
df (GNU coreutils) 8.32
Packaged by Gentoo (8.32-r1 (p0))
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Torbjorn Granlund, David MacKenzie, and Paul Eggert.

--version通过替换为任何截断变体--v、--ve、--ver、--vers和--versi，可以获得相同的输出--versio。然而，当我向选项添加额外的字母时，它突然意识到该选项无效：

user@computer ~ $ df --versionn
df: unrecognized option '--versionn'
Try 'df --help' for more information.

这种行为是故意的吗？其背后的原因是什么？我的理解是，大多数实用程序都依赖于getoptsor getopt（或类似的），因此我查看了他们的联机帮助页以寻找线索，但没有找到任何解释。

[1]ES雷蒙德。UNIX 编程的艺术。培生教育公司，2004 年

答案1

重点是节省打字。例如，您可以键入ls --col|less -R而不必拼写出来ls --color。

（不，我找不到参考资料。令人惊讶的是，在getopt_long文档也不GNU 编码标准。我声称这是民间传说。）

现在通用 shell 支持长选项的补全已经不太有用了，但是对命令的自定义补全支持不是自动的，并且 bash（GNU shell）中对自定义补全的支持是在getopt_long实现大约二十年后（20世纪 80 年代初到 1990 年代末 IIRC） ）。

答案2

我怀疑除了相关功能试图提供帮助之外，还涉及其他任何事情。在交互式使用中，实用程序接受缩写可能是有益的，这样用户就可以偷懒。

这是一个问题波斯特尔定律（即“对你所接受的要宽容，但对你输出的要严格”），而宽容是不是始终是一个值得遵循的好规则，因为人们习惯的行为会影响未来变革的可能性。在这种情况下，未来的选项可能会使之前的有效缩写无效，但只要脚本作者花时间完整拼写选项，出现问题的风险就不大。交互式用户可以更轻松地使用缩写，因为如果他们在升级后遇到错误，可以认为他们能够轻松修复命令。

使用缩写的脚本确实可能是一个问题，并且避免出现这些问题将会有争论不是对输入宽松。但显然在这种情况下，图书馆作者已经选择接受缩写是可以的。

相关内容