needing -- before add-on command options is non-obvious

[peti]

[hledger ui --watch does not work] but hledger-ui --watch does. Apparently, hledger doesn't know about that flag and thus refuses to start up.

[simonmichael]

There are some tricks required with options in certain cases. Do you need to insert a -- ?

[peti]

I see. I didn't know about the need to terminate hledger's option parsing explicitly. I understand why that's necessary from the PoV of someone who implements these kinds of things, too, but from a user's PoV this is rather unintuitive. Why do I need that when I call hledger ui but don't when I call hledger bal? The reason is that the ui command is implemented differently, but -- as a user -- I wouldn't really want to know (or think) about that detail.

[simonmichael]

I heartily agree! It's annoying. Any help welcome. The problem, which hledger tries and fails to completely hide, is that cmdargs (last I checked) isn't good at partially parsing the command line (passing though unrecognised options without complaining).

[peti]

As far as I understand it, there are 2 cases hledger has to deal with:

1. The user ran an internal command. In that case, hledger must parse and verify all options.

2. The user ran an external command. In that case, hledger must parse none of the command-line -- everything is just passed through to the backend via exec().

Is that right?

[simonmichael]

That's what we'd like to happen, but AFAIK cmdargs doesn't support it yet. It insists on recognising everything in the command line, up to --. When I looked, I found it hard to see how to fix that, so instead I've tried workarounds like munging the command line before running cmdargs. But these are fragile, because doing that properly requires full knowledge of the options. But some time has passed; maybe cmdargs has changed ? My issue report should be in its tracker.

[peti]

How about dropping all argv elements that begin with a - character, taking the head of the remaining list, and checking that string (which should be the "command" to be run) against a list of known internal commands? If the string is not in that list, then cmdargs never needs to run at all.

[simonmichael]

We do something like that but it breaks down in case of -F VALUE or --FLAG VALUE.

[peti]

Yeah, that's true. And these kind of options can't be handled unless you know which ones take an argument either. So I guess using a separate parsing process is not feasible. 😞