Question

在以下示例中，我预计错误消息来自getopt，而不是来自/tmp> getopt --name xyz --options "xyz:" -- -x -x -- /tmp> getopt --name xyz --options "xyz:" -- -x -z getopt: option requires an argument -- z -x --。我做错了什么？

xyz: option requires an argument -- z

如何说出--name;那不是$ getopt --version getopt from util-linux 2.25.2的意思吗？

更新

似乎是一个错误。我的getopt来自cygwin

android:layout_height="match_parent"

Answer 1

在某些版本的程序中似乎是错误。

它适用于Centos 7.3和Fedora 19

[vps1 ~]$ cat /etc/redhat-release
CentOS Linux release 7.3.1611 (Core)
[vps1 ~]$ getopt  --name xyz --options "xyz:" -- -x -z
xyz: option requires an argument -- 'z'
 -x --
[vps1 ~]$  getopt -V
getopt from util-linux 2.23.2

但它不在我的MinGW shell中（来自Git for Windows）

$ getopt  --name xyz --options "xyz:" -- -x -z
getopt: option requires an argument -- z
-x --
$  getopt -V
getopt from util-linux 2.26.2

更新：它也适用于Linux中的2.27.1。并且它在（至少某些版本的）Cygwin中不起作用。所以问题似乎出现在Windows端口（Mingw和Cygwin，有趣的是）。

我会疯狂猜测（击中目标的概率不大）： getopt程序，因为this commit试图处理某些环境（特别是BSD; 不是 Linux），它们使用getprogname/setprogname来获取/设置＆＃34;当前＆＃34;程序名称（而不是依赖于argv[0]）。

#if defined (HAVE_SETPROGNAME) && !defined (__linux__)
        setprogname(name);

现在，让我们想象一下

Cygwin和MinGW / Msis都支持这些功能。
但是，他们缺少HAVE_SETPROGNAME define
此外，他们的getopt函数（请注意，而不是程序），就像BSD版本一样，使用getprogname代替argv[0]

在这种情况下，将解释问题。但是，我特别怀疑 - 第3点。

Answer 2

这是一个错误（或只是一个不可移植性问题），已在bash -c 'exec -a "XYZ" getopt --options "xyz:" -- -x -z'中由commit 30fbf2f6修复。在此修复之前，它仅适用于Linux，OSX和一些BSD风格，但不适用于WIN32或GNU-Hurd。

如果你无法升级--name（可能很难在Windows上构建），那么你可以使用这个shell解决方法：

getopt

请注意，如果getopt将在某一天更新，那么仍然使用{{1}}选项会再次覆盖此技巧。

当然，您也可以简单地将{{1}}程序复制/链接/重命名为您想要的任何名称。

如何使用--name参数getopt？

2 个答案: