当几个命令行实例“工作”时可能副作用。在注释类的同一实例上？

发布于 2025-01-26 18:49:35 字数 1774 浏览 2 评论 0原文

Picocli的 @-File机制几乎是我需要的，但不是完全。原因是我要控制解析的其他文件的确切位置 - 具体取决于以前的选项值。

示例：与选项打电话时 srcfolder =/a/a/b optionfile = of.txt，我的程序应查看从/a/b/of.txt中读取的其他选项，但是当使用srcfolder = ../c optionfile = of.txt ，它应该从../ c/of.txt中看到那些。

@-file机制无法做到这一点，因为它在处理任何选项值之前会扩展所有选项文件（始终相对于当前文件夹，如果它们相对）。

因此，我想拥有picocli ...

处理选项“从左到右”，
在optionfile选项中提到的选项文件时，递归解析了一个选项，
然后继续以下选项。

我也许可以通过从注释的设置器方法中递归开始解析来解决此问题：

...
Config cfg = new Config();
CommandLine cmd = new CommandLine(cfg);
cmd.parseArgs(a);
...

public class Config {
    @Option(names="srcfolder")
    public void setSrcfolder(String path) {
        this.srcfolder=path;
    }
    @Option(names="optionfile")
    public void parseOptionFile(String pathAndName) {
        // validate path, do some other housekeeping...
        CommandLine cmd = new CommandLine(this /* same Config instance! */ );
        cmd.parseArgs(new String[] { "@"+this.srcfolder + pathAndName });
    }
...

这样，几个commandline实例将在相同的config> config> config实例上调用setter方法，递归递归”互相打断。现在是实际的问题：这是一个问题吗？

当然，我的config类具有状态。但是，如果其他consemline实例还修改cfg“在选项之间”，则conderline实例也可能会弄乱状态？

感谢您的任何见解！

编辑要添加：我尝试过，并且我在 @-File选项上获得了nmutchedArgumentException：

Exception in thread "main" picocli.CommandLine$UnmatchedArgumentException: Unmatched argument at index 0: '@/path/to/configfile'
    at picocli.CommandLine$Interpreter.validateConstraints(CommandLine.java:13490)
...

首先我必须解决这个问题：显然Picocli没有扩展@-file选项除非从命令行直接直接。

原文

picoCLI's @-file mechanism is almost what I need, but not exactly. The reason is that I want to control the exact location of additional files parsed -- depending on previous option values.

Example: When called with the options
srcfolder=/a/b optionfile=of.txt, my program should see the additional options read from /a/b/of.txt, but when called with srcfolder=../c optionfile=of.txt, it should see those from ../c/of.txt.

The @-file mechanism can't do that, because it expands ALL the option files (always relative to the current folder, if they're relative) prior to processing ANY option values.

So I'd like to have picoCLI...

process options "from left to right",
recursively parse an option file when it's mentioned in an optionfile option,
and after that continue with the following options.

I might be able to solve this by recursively starting to parse from within the annotated setter method:

...
Config cfg = new Config();
CommandLine cmd = new CommandLine(cfg);
cmd.parseArgs(a);
...

public class Config {
    @Option(names="srcfolder")
    public void setSrcfolder(String path) {
        this.srcfolder=path;
    }
    @Option(names="optionfile")
    public void parseOptionFile(String pathAndName) {
        // validate path, do some other housekeeping...
        CommandLine cmd = new CommandLine(this /* same Config instance! */ );
        cmd.parseArgs(new String[] { "@"+this.srcfolder + pathAndName });
    }
...

This way several CommandLine instances would call setter methods on the same Config instance, recursively "interrupting" each other. Now comes the actual question: Is that a problem?

Of course my Config class has state. But do CommandLine instances also have state that might get messed up if other CommandLine instances also modify cfg "in between options"?

Thanks for any insights!

Edited to add: I tried, and I'm getting an UnmatchedArgumentException on the @-file option:

Exception in thread "main" picocli.CommandLine$UnmatchedArgumentException: Unmatched argument at index 0: '@/path/to/configfile'
    at picocli.CommandLine$Interpreter.validateConstraints(CommandLine.java:13490)
...

So first I have to get around this: Obviously picoCLI doesn't expand the @-file option unless it's coming directly from the command line.

分享到QQ

分享到微博