remove parseopt2 or parseopt

[dom96]

Which one?

@zielmicha?

The primary difference seems to be:

https://github.com/nim-lang/Nim/blob/devel/tests/system/params.nim#L16

For parseopt2: f[2].key == "a=c" and f[2].val == "d"
For parseopt: f[2].key == "a" and f[2].val == "c:d"

[zielmicha]

parseopt2 was meant to replace parseopt (parseopt also has problem with whitespace #726)

[dom96]

relevant #4620

[dom96]

For this example:

import os
import osproc
import parseopt2
import sequtils

let argv = commandLineParams()

if argv == @[]:
  # this won't work with spaces
  assert execShellCmd(getAppFilename() & " \"foo bar\" --path:\"/i like space/projects\" --aa:bar=a --a=c:d --ab -c --a[baz]:doo") == 0
else:
  let f = toSeq(getopt())
  for a in f:
    echo a

With parseopt:

(kind: cmdArgument, key: foo bar, val: )
(kind: cmdLongOption, key: path, val: /i like space/projects)
(kind: cmdLongOption, key: aa, val: bar=a)
(kind: cmdLongOption, key: a, val: c:d) # difference here
(kind: cmdLongOption, key: ab, val: )
(kind: cmdShortOption, key: c, val: )
(kind: cmdLongOption, key: a[baz], val: doo)

With parseopt2:

(kind: cmdArgument, key: foo bar, val: )
(kind: cmdLongOption, key: path, val: /i like space/projects)
(kind: cmdLongOption, key: aa, val: bar=a)
(kind: cmdLongOption, key: a=c, val: d) # difference here
(kind: cmdLongOption, key: ab, val: )
(kind: cmdShortOption, key: c, val: )

I don't see that whitespace issue, the only difference seems to be between handling of --a=c:d. I personally think the way parseopt handles it makes more sense.

[zielmicha]

@dom96 Your example works, but you have yourself linked to issue demonstrating the problem: #4620.

I think the best way to solve this problem is to change parseopt2 to handle --a=c:d the same way as parseopt (the fact it behaves differently was probably my oversight).

[dom96]

Okay, so is #4620 the only issue that parseopt2 solves?

[zielmicha]

Most likely yes.

[c-blake]

I found it necessary for several reasons to do a parseopt3.nim when I did https://github.com/c-blake/cligen. I'm happy to contribute that if people want it. One thing Araq said in the #4620 was he would be ok with breaking changes if we got POSIX compatibility. The approach I took is very gentle on end-user command typers, accepting both the -d:val type syntax as well as POSIX -dval, or -d=val and so on. I feel like the current generated command-line parser's syntax is far more rigid than Nim's actual language syntax.

[dom96]

But then how can you distinguish between -dval meaning (key: "d", value: "val") vs. (key: "dval", value: "")?

[c-blake]

My API lets you/makes you tell the parser which long & short option keys take no arguments. That is analogous to the getopt(3) API where you have to specify such. I didn't see a way to break the ambiguity without that requirement.

[c-blake]

Admittedly, this puts slightly more work on command-authors to require slightly less work on command-typers, but that seems like a good trade off to me.

[c-blake]

Also, I chose the reverse of getopt(3) in having the command-author specify non-argument taking keys. It would be trivial to reverse that logical sense of NoArg vs. some HasArg. It probably wouldn't be so hard to have the API take either NoArg or HasArg lists and let the caller choose the least onerous (but only one per parser object). I'm all for flexibility wherever one can find it, and no other commands I use require me to type all those pesky ":"s.

[Araq]

I feel like the current command-line parsing syntax is far more rigid than Nim's actual language syntax.

Well as you noted, the reason for this is that I love to be able to parse command line arguments without a "symbol table" (without having to define the list of available options) just like Nim's actual language syntax. IMO the right tradeoff was made here and Posix's design is just wrong. If the machine cannot parse it without knowing the available options, neither can the programmer.

It also means that you can reliably forward command line arguments to other processes.

[c-blake]

Well, you seemed a lot more open to being POSIX-y a little over a year ago in #4620 than you do today. If you see a way to be more POSIX-y without a symbol table, that would be cool, too. It doesn't sound like you do, though.

I'm personally in favor of even less work on CLI authors (as per cligen). It just feels wrong to me that CLI users/command-typers lose out. Users probably type the options to commands many more times than CLI authors write parsers. Reasonable folks can differ, though.

In terms of this particular issue of removing one of parseopt and parsopt2, given that in the wider world there is an alternate CLI syntax, it might make sense for the stdlib to support both. It might not, too. I was just trying to be helpful if it was wanted, and #4620 made me think that it might be wanted.

[andreaferretti]

But then how can you distinguish between -dval meaning (key: "d", value: "val") vs. (key: "dval", value: "")?

I would read -dval as -d -v -a -l, --dval as key = dval, and -d val, --d=val, --d:val as key:d, value: val