我正在为一个命令行程序编写一些代码,并且我正在使用getopt()
函数。有人能解释一下options / long_options的语法吗?
getopt.getopt(args, options[, long_options])
我的问题是:
为什么列表在参数之间是碎片化的?为什么是options[而不是options?
发布于 2013-06-13 02:31:30
该函数有两个必需的参数(args
和options
)和一个非必需的选项(long_options
)。args
、options
和long_options
的确切含义都可以在documentation中找到
基本上,如果您希望命令行被解析为:
myprogram --foo=bar
然后,您需要有一个类似于['--foo=']
的long_options
列表,但如果您希望将其解析为:
myprogram -f bar
然后将options
设置为'f:'
。当然,您可以随意混合和匹配。
不管它有什么价值,我永远不会建议任何人在使用optparse
或(甚至更好) argparse
时使用getopt
。后面的两个模块让使用getopt
的感觉就像是用锤子给自己造了一台新电脑……
发布于 2013-06-13 02:31:55
您应该使用argparse
而不是getopt
,后者现在已被弃用。关于解释,文档确实是可以访问的:
关于你的具体问题,我想你已经有了答案:
(请阅读有关this和that的文章,了解为什么应该使用argparse
;甚至getopt
文档也声明(原文如此)“不熟悉C getopt()函数的用户,或者希望编写更少代码并获得更好帮助和错误消息的用户,应该考虑改用argparse
模块。”)
在最后一次编辑之后:根据惯例,当你在文档中看到被方括号包围的原型的一部分时,这意味着该部分是可选的,而之前的部分是必需的。当你想调用getopt.getopt()
时,应该赋值 args
和options`。
现在,它不是python,因为这意味着最后一个逗号也是必需的,尽管如果调用getopt.getopt(args, options,)
,它不是有效的getopt.getopt(args, options, [long_options])
表达式。
在上一条评论之后:嗯,这种语法是unix平台上几乎所有工具都使用的约定……我不知道它是否在某个地方定义过,但如果它比POSIX规范本身更早,我也不会感到惊讶!我能找到的唯一的“文档”是下面的维基百科页面,但它缺少参考:
我在caltech找到了一门课程(查找部分“用法语句中的可选参数”),它告诉可选参数使用方括号:
最后,你不是第一个在堆栈溢出上问这个问题的人,至少还有两个关于相同主题的问题:
如果你查看系统上的手册页,你会发现它们都使用这种语法,方括号中的所有参数都是可选的,例如:ls
manpage,cat
manpage,甚至macos的open
manpage都使用这种约定!
我希望这次我确实回答了你的问题!
发布于 2013-06-13 02:35:19
参数args
和options
是强制参数,long_options是函数的可选参数,即可以提供也可以不提供。如果您打算支持像--format
和-f
这样的长选项,您可以在命令行实用程序中提供它。
Linux ls
实用程序示例,显示以--
开头的选项和长选项
LS(1) User Commands LS(1)
NAME
ls - list directory contents
SYNOPSIS
ls [OPTION]... [FILE]...
DESCRIPTION
List information about the FILEs (the current directory by default). Sort entries alphabeti‐
cally if none of -cftuvSUX nor --sort is specified.
Mandatory arguments to long options are mandatory for short options too.
-a, --all
do not ignore entries starting with .
-A, --almost-all
do not list implied . and ..
--author <--- LONG OPTIONS OF COMMAND LINE
with -l, print the author of each file
https://stackoverflow.com/questions/17072697
复制相似问题