如何将 Getopt::Long 选项传递给也是一个选项的子例程?
我正在尝试设置 Getopt::Long 来处理配置脚本中的参数。
这是我的开场白:
#!/usr/bin/perl
use strict;
use warnings;
use Getopt::Long;
my $config_file = '';
GetOptions (
'config|c=s' => \$config_file,
'add|a' => \&add_server,
'del|d' => \&del_server,
);
sub add_server {
print "$config_file\n";
}
sub del_server {
# Left blank for now.
}
奇怪的是,当我使用如下命令运行脚本时,我遇到了问题:
./config.pl -a -c config.xml
它不会打印 < code>-c 选项,但如果我像这样运行它,
./config.pl -c config.xml -a
它会像它应该的那样工作。
我想我明白其中的原因;这与订单执行有关吗?
我该如何修复它?我应该将 Getopt::Long
与 @ARGV
结合使用吗?
最终,我试图将命令行参数传递到我正在调用的子例程中。因此,如果 -a
或 --add
,我希望传递 -c
或 --config
的选项调用时进入子程序。
有什么想法吗?
I am trying to setup Getopt::Long
to handle the arguments from a configuration script.
Here is my starter:
#!/usr/bin/perl
use strict;
use warnings;
use Getopt::Long;
my $config_file = '';
GetOptions (
'config|c=s' => \$config_file,
'add|a' => \&add_server,
'del|d' => \&del_server,
);
sub add_server {
print "$config_file\n";
}
sub del_server {
# Left blank for now.
}
The odd thing is I am running into a problem when I run my script with something like this:
./config.pl -a -c config.xml
It does NOT print the -c
option, but if I run it like this,
./config.pl -c config.xml -a
it works like it should.
I think I understand the reason why; it has to do with the order execution right?
How can I fix it? Should I use Getopt::Long
in conjunction with @ARGV
?
Ultimately, I am trying to make the command line args pass into the subroutine that I am calling. So if -a
or --add
, I want the options of -c
or --config
to pass into the subroutine when it is called.
Any ideas?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
启用 Getopt::Long 上的 pass_through 选项,以便它将忽略未知选项,然后为您的选项调用一次 GetOptions,再次禁用它,然后再次为您的命令使用 GetOptions。
Enable the pass_through option on Getopt::Long so that it will ignore unknown options, then call GetOptions once for your options, disable it again, and then use GetOptions again for your command.
我认为没有必要直接从
GetOptions
调用中调用子例程。像这样控制顺序:I don't see the need to call the subroutine directly from the
GetOptions
call. Control the order like this:将示例稍微简化一下......
并运行
config.pl -c Blug -a
返回输出Got this for a config file:blurg
,并且运行 config.pl -a -c blurg 会返回Got this for a config file:
。所以,我怀疑正在发生的事情是选项是按照给定的顺序分配的。因此,在第一种情况下,
$config_file
被分配给-c
参数,然后调用add_server
子例程(使用正确的参数),而在第二种情况下,add_server
立即被触发,不带任何参数,然后分配$config_file
。除此之外,我建议将
-a
设置为布尔值,并在启用它的情况下执行您想做的任何操作(并且如果提供了-c
的参数)。Boiling the example down a little bit...
... and running
config.pl -c blurg -a
returns the outputGot this for a config file: blurg
, and runningconfig.pl -a -c blurg
returnsGot this for a config file:
.So, what I suspect is happening is that the options are assigned in the order given. So in the first case
$config_file
is assigned to the-c
argument and then theadd_server
subroutine is called (with the correct argument), whereas in the second case,add_server
is immediately fired off with no argument and then$config_file
is assigned.All this aside, I'd recommend making
-a
a boolean and do whatever you want to do if it's enabled (and if an argument for-c
is supplied).遇到选项时会调用回调,因此当您执行操作时,会在遇到
-c
之前调用add_server
根据最新信息,您现在需要:
The callbacks are called as the options are encountered, so
add_server
is being called before-c
has been encountered when you doBased on the latest info, you now want: