option processing order

[slymz]

This question was asked before, but perhaps without sufficient justification. It is occasionally a requirement to respect order of options. This is especially useful when imposing precedence relations between command line arguments, directory settings, user settings, systems settings and so on which is pretty common in many applications.

Let's start with a case that is naturally handled by JCommander:

myapp -foo 3 -foo 4 -foo 5

And the behavior requires the last one to win: say in this case, -foo 3, 4 and 5 come from myapp's user home, project dir, and command line parameters, respectively. I could harvest -foo as a list of ints and just pick the last entry. 

However, with boolean's this is not quite clear how to do:

myapp -bar -nobar -bar -bar -nobar

I need -nobar. That is  boolean bar member be false in the end. 

How can I accomplish this (without manually parsing the argument list for order, because, you know, "life is too short to parse command line parameters")?

[Cédric Beust ♔]

myapp -bar -nobar -bar -bar -nobar

How do you know what the user wants when they submit such an ambiguous (and arguably incorrect) command line?

​

-- 

Cédric

--
You received this message because you are subscribed to the Google Groups "jcommander" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jcommander+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[slymz]

On Wednesday, April 26, 2017 at 2:23:23 PM UTC-4, Cédric Beust ♔ wrote:

myapp -bar -nobar -bar -bar -nobar

How do you know what the user wants when they submit such an ambiguous (and arguably incorrect) command line?

​

This isn't ambiguous actually. Quite it contrary, it is pretty common.  Take

git log --decorate --no-decorate --decorate ... --no-decorate

The last one wins, and would be equivalent to single --no-decorate. Most CLI, not just git's, support this naturally, without errors or ambiguity.

The use case for this is many. One is what I attempted to explain in my original post, same option being specified from multiple sources, again say git example: ~/.gitconfig,  $PWD/.git/config, and on the command line. The implemenation would just populate the argument list in deterministic and documented order, and pass to the internal argument parser.

Another use case is allowing users to override aliases etc. Say, in your shell you have aliased:

alias gl="git log --decorate --oneline --graph "

but occasionally want to run:

gl --no-decorate

The application gets two competing arguments in the same command line. Git CLI could adopt one of the following behaviors:

1. error out 

2. pick the first one

3. pick the last one

It is customary in CLI utilities -- git or whatever else in your regular *nix environment, you name it -- to adopt 3rd option.