Ignoring convention that `--` separate non-flag arguments in bash (apart from last `--` for fire flags)

[jbcdnr]

Beyond the fact that fire uses the last -- to separate flag argument from command arguments, it seems that previous -- are not parsed correctly. At least according to the common convention that a double dash ( -- ) is used in most Bash built-in commands and many other commands to signify the end of command options, after which only positional ("non-option") arguments are accepted (source).

I would like to use this to pass some other commands to a fire command, without the flags targeted to the extra command being parsed by fire. Here is a minimal example test.py:

import fire


def foo(*args: str, flag: int = 2) -> None:
    print(f"{args=} {flag=}")


fire.Fire(foo)

Current behavior:

$ python test.py -- other args 1 2 --flag 3 --
args=('args', 1, 2) flag=3
ERROR: Could not consume arg: --
Usage: test.py -- other args 1 2 -

For detailed information on this command, run:
  test.py -- other args 1 2 - --help

Expected behavior:

python test.py -- other args 1 2 --flag 3 --
args=('args', 1, 2, "--flag", 3) flag=2

Would you be fine with updating the parsing rules in

python-fire/fire/core.py

Line 376 in 6cf45c6

2a. If the current component is a class, instantiate it using args from args.

to consider all remaining args as positional arguments if it encounter a -- ? I could work on a PR if there is no major blocker.

[jbcdnr]

Hello @dbieber,

Could you have a look at this issue? I implemented the feature in this fork with some tests. Happy to open a PR and polish it if you agree that this is following expected behavior in bash (and argparse).

Cheers,

[dbieber]

Thanks for the PR @jbcdnr. It may be a bit before I have a chance to look this over properly. I'll let you know once I do.