Support optional flag arguments after positional arguments

[schmichael]

Nomad's CLI has always required positional arguments come after all optional flags:

# Works
$ nomad run foo.nomad
$ nomad run -detach foo.nomad

# Does not work
$ nomad run foo.nomad -detach
This command takes one argument: <path>
For additional help try 'nomad job run -help'

As this causes some ambiguities, such as if there were a file named -detach, we would also need to support -- [positional arguments] syntax at the end of commands:

# Desired
$ nomad run foo.nomad -detach
$ nomad run -- -detach # Runs the file named -detach

It should be noted that the current behavior follows Go and BSD style, and the reordering behavior follows GNU style. I think the usability improvement is worth breaking out of our existing style, but it's definitely up for debate.

[shantanugadgil]

I was going to file an "enhancement" bug around this, but found this. A few thoughts:

My issue with the positional parameters is when I can't append -verbose or -json to the end of an existing command I had just typed. I have to go back on the cmd line and add -json in the middle.

The way I see it possible is if part of the cmdline upto the "action" can be parsed differently than the part of the cmdline after the "action". I think of the "action" verb as run, status, job status, job run, alloc status
*** even though they are two words, they are basically "job-status", "alloc-status" and so on.

*** I can easily imagine this possible in bash, though not sure which golang option parsing library would do this nicely.

Something which comes to mind is that the job name and file name would need to be converted to a parameterized option (-n|--name and -f|--filename)

Allocation would need --id, etc.

BTW, I am not so much for the -- syntax as I haven't felt the need myself yet. (the "-detach" example could be possibly solved using ./-detach, no?)

[mitchellh]

This was just pointed out to me on Twitter so I wanted to share a couple personal points here:

I've typically seen the -- syntax to pass through to some underlying program or something. I can't recall any specific examples right now but for example I think we did vagrant ssh -- foo bar -baz back in the day to execute foo bar -baz. The -- in most flag libs I've seen is the "stop parsing here" indicator.

Due to the ambiguities you pointed out, in Waypoint we opted to add in detection, and we had a couple users that really loved it. They don't love the Go/BSD flag behaviors but I haven't heard any complaints since we implemented this. Solving little paper cuts through safe heuristics: https://github.com/hashicorp/waypoint/pull/1849

Ultimately, I don't care either way what behavior you chose to follow! I was just adding my 2c here.

[mitchellh]

I just remembered a classic Unix example of the double hyphen usage I’m used to. Xargs uses it to stop parsing. https://www.oilshell.org/blog/2021/08/xargs.html

[shantanugadgil]

I have personally used the -- syntax when using rm to remove a file which begins with a - (hyphen)

(such a file has of course been created accidentally)

Anyway, the intent of my comments on this ticket was only with the following request (and the conversation I have had with the Nomad command line)

"Please don't make me figure out where exactly to scroll back to get the position of the -verbose (or -stderr for logs) correctly. Why don't you just accept -verbose at the end-of-line"

Of course, I know the answer to the "why?" question, it is just something I like to do while I am fiddling with CTRL+left arrow etc. :grin: