Shell：是否可以在非可选参数之后解析可选参数？答案

【问题标题】：Shell: Is it possible to parse optional parameters after non-optional ones?Shell：是否可以在非可选参数之后解析可选参数？
【发布时间】：2013-06-25 16:22:42
【问题描述】：

最近我尝试在这样的 shell 脚本中传递参数：

$./myscript.sh <sourcefile> <destinationfile> -o

脚本应该读入一个源文件和一个目标文件 - 两者都应该是强制性的 - 然后最后检查额外的可选参数。但是，当尝试使用 getopts 解析选项 -o 时 - 它永远找不到它。它总是“假”或“0”。它只识别选项-o当它在其他参数之前传递时！

$./myscript.sh -o <sourcefile> <destinationfile>

这是强制性的，它只能以这种方式工作吗？当我在脚本中搜索规则、约定或实践时，我从来没有找到这些基本信息，只是通过反复试验才发现它，浪费了大量时间……我还想知道复制命令过程是如何工作的，因为它也混合可选参数和非可选参数

【问题讨论】：

在调用 getopts 之前，您始终可以捕获并关闭前 2 个参数。
这最终是有道理的。我之前尝试将它们放在前面，但在调用 getopts 之前忘记将它们移开。所以它没有用。谢谢大佬，我马上试试！

标签： bash optional-parameters

【解决方案1】：

传统上，在 unix 中，可选参数排在第一位，至少对于大多数 shell 实用程序而言，那就是 Posix recommendation 用于编写 shell 实用程序。 bash 内置 getopts 也是为此用例设计的；除非您自己对命令行参数重新排序，否则getopts 将仅适用于先出现的选项参数。

但是，大多数 gnu 实用程序使用 gnu getopt 或 getopt_long C API，默认情况下，这两种 API 都允许可选参数出现在命令行中的任何位置。即使使用 Posix shell 实用程序，标准也有一些例外。

简而言之：

您应该始终安全地将可选参数放在首位，但在某些情况下您可以将它们放在最后
使用内置的bash getopts 编写的实用程序实际上总是需要先出现可选参数
大多数 Gnu 实用程序允许混合可选参数和位置参数

【讨论】：