Allow -- to come just before the jq program

[danfuzz]

Describe the bug
jq has the somewhat surprising behavior of recognizing additional options after a non-option argument has been encountered. While I won't suggest changing that behavior (due to compatibility concerns), it would be nice if jq at least recognized -- as an indication to stop attempting to parse options. This is a pretty commonly-implemented feature of commandline tools.

Given that it's currently an error to pass -- in a context where options are recognized, I don't think it would introduce a compatibility issue.

To Reproduce
Expected to remain the same:

$ jq --null-input --args '$ARGS' foo bar baz --zorch
jq: Unknown option --zorch
Use jq --help for help with command-line options,
or see the jq manpage, or online docs  at https://jqlang.github.io/jq

Current behavior of --:

$ jq --null-input --args -- '$ARGS' foo bar baz --zorch
jq - commandline JSON processor [version 1.7]

Usage:	jq [options] <jq filter> [file...]
...

Expected behavior
Suggested behavior of --:

$ jq --null-input --args -- '$ARGS' foo bar baz --zorch
{
  "positional": [
    "foo",
    "bar",
    "baz",
    "--zorch"
  ],
  "named": {}
}

Environment (please complete the following information):

• OS and Version: N/A (FWIW I use macOS and various Linuxes)
• jq version: 1.7

Additional context
N/A

[nicowilliams]

There is a workaround: add a -- after the program:

: ; jq -cn --args '$ARGS.positional' -- a b c -X -- -foo
["a","b","c","-X","--","-foo"]

vs.

: ; jq -cn --args '$ARGS.positional' a b c -X -- -foo
jq: Unknown option -X
...

[nicowilliams]

While I won't suggest changing that behavior (due to compatibility concerns), it would be nice if jq at least recognized -- as an indication to stop attempting to parse options.

But it does stop parsing options after --, it's just that -- has to come after the program.

[danfuzz]

TIL, thanks! I see that it's even documented (which I missed when I skimmed it before). My apologies for the noise.

[nicowilliams]

I think the fix would be to not parse options after finding the program (if it's not given as -f FILE anyways), but then should we parse the -- that might follow the program? If not then we'd cause a backwards incompatibility, but if yes then that would be surprising. So I think the best we can do is document this more carefully than we do now. We should accept -- just before the program argument.

[nicowilliams]

TIL, thanks! I see that it's even documented (which I missed when I skimmed it before). My apologies for the noise.

But it's an interesting report! It's interesting because the program argument is not an option argument, so why is it that we only accept -- after the program? I think we should accept it before too. That we only accept -- after the first positional argument is surprising, and surprise! it surprised you. I.e., this is a bug, so I'm reopening it. Thanks for the report!

[emanuele6]

@nicowilliams What you are proposing would be a feature request, not a bug. Also I don't think it is very related to the OP. Creating a new issue would be better.

[emanuele6]

Actually, I guess it could be considered a bug. I already knew about this quirk of jq option parsing, we had discussed it in the past, and @danfuzz said it was documented so I assumed, so I thought changing it would be a feature request.

I think Dan was referring to:

--:

       Terminates argument processing. Remaining  arguments  are  positional,
       either strings, JSON texts, or input filenames, according to whether --args
       or --jsonargs were given.

That is not really documenting it much, it's probably just bad wording; anyway #2919 now fixes it.

[emanuele6]

I reverted the name change; sorry for the noise, I can't brain in the morning ^^