unexpected `Unexpected non-option` message value

[disruptek]

My dispatched proc doesn't take non-options. The message field of my ClParse looks like maybe it's missing a renderer?

Unexpected non-option (cmd: @["asdf"], pos: 1, off: 0, optsDone: false, shortNoVal: {'\x00', 'a', 'c', 'd', 'h', 'i', 'j', 'r', 'w'}, longNoVal: (root: ..., count: 15), stopWords: (root: ..., count: 0), requireSep: false, sepChars: {':', '='}, opChars: {'#', '$', '%', '&', '*', '+', ',', '-', '.', '/', '<', '>', '?', '@', '^', '|', '~'}, sep: "", message: "", kind: cmdArgument, key: "asdf", val: "")

[c-blake]

That is really weird. The .message should be "Unexpected non-option asdf" and looking at the code in cligen.nim, I do

let msg = "Unexpected non-option " & $`pId`

and then I populate .message with that msg.

It may take more context in your program to really know, but this could be a bug in the Nim compiler. I mean, I'm not even sure how you're getting that output...echo on elements of the seq passed to setByParse, I expect.

You may have to add the -d:printDispatch define to debug the situation. I don't think I have enough to go on here.

[disruptek]

Here's where I'm outputting the error messages that get nicely formatted in the ClParse sequence: https://github.com/disruptek/gully/blob/master/src/gully.nim#L557

If I change your code to the following, it works as expected:

let msg = "Unexpected non-option " & $`pId`.key

Any downside to this change? Does it work for you currently? I'm on this compiler:

Nim Compiler Version 1.0.99 [Linux: amd64]
Compiled at 2019-10-22
Copyright (c) 2006-2019 by Andreas Rumpf

git hash: 38b3590e40b7267195c65168e6ff064775de4339
active boot switches: -d:danger

[c-blake]

That was just a lame mistake. Thanks for catching & reporting.

[disruptek]

This seems to have exposed another such instance, or should I be catching the exception and rendering it?

gully does not expect non-option arguments.  Got
(cmd: @["foobar"], pos: 1, off: 0, optsDone: false, shortNoVal: {'\x00', 'a', 'c', 'd', 'h', 'i', 'j', 'r', 'w'}, longNoVal: (root: ..., count: 15), stopWords: (root: ..., count: 0), requireSep: false, sepChars: {':', '='}, opChars: {'#', '$', '%', '&', '*', '+', ',', '-', '.', '/', '<', '>', '?', '@', '^', '|', '~'}, sep: "", message: "", kind: cmdArgument, key: "foobar", val: "")
Run with --help for full usage.

[c-blake]

That looks like a legitmate incorrect usage report to the CL user to me. cmd line is @["foobar"] which does not begin with - and you mentioned before there were no non-option params. You can catch the exception and do something different if you don't like my default actions, though.

[disruptek]

It's incorrect usage, of course, but I don't think it's very friendly to a normal user -- you might have to scroll horizontally to see how verbose it is. Are you sure you don't want to change line 571 to also use the key field (as you've just done on 566):

$`pId`.key & "\nRun with --help for full usage.\n")
#     ^^^^

...so the output becomes the following instead?

gully does not expect non-option arguments.  Got
foobar
Run with --help for full usage.

Then the developer can merely discard the exception and cligen will render the error correctly (and succinctly!)

[c-blake]

Ok. Pushed something maybe more indicative to a user...should print something like:

gully does not expect non-option arguments at "foobar".
Run with --help for full usage.

Seem good?

[disruptek]

Perfect, thanks again. :smile: