Closed SirNickolas closed 3 years ago
I think 1
(or maybe 255/-1
) is the most common unsuccessful error code, which is often used only as a true-false thing by higher levels. I agree more detail can be nice, and I do sometimes do that myself.
However, among those programs who want that detail, I disagree there is some common "many programs" convention like 2 = CLI parse error
. I think there is no common convention { I do not doubt you have seen >=2 programs with that convention :-) I just disagree a broad, realistic survey would find a better default than 1
. }. That said, I am fine having some variable/ClCfg field to specify the code. I'm working on your other request first, though.
If you are in a hurry, I think you can write your own cligenQuit
template between import and dispatch to override all that behavior if you want. It's only a 20 line template...
So..there are several different situations where there is a parse error (basic 1-proc dispatch, subcommands, init object from CL), but all situations are really invalid/unparsable user input. So, I just called them all cgParseErrorExitCode
. If you just set that integer variable (anywhere between import & dispatch) to whatever you want, e.g. 2
, then that should work.
That was fast. Thanks.
As far as I can see,
cligen
quits with code1
if the user made a mistake in calling the CL interface:https://github.com/c-blake/cligen/blob/34b21db967a1a24d700e101ee1f30cc6db862d63/cligen.nim#L1142-L1146
However, exit code
1
is commonly used as an “unsuccessful” return code, and the program would likely want to emit it itself rather than afforing it to the CLI framework. Many programs return2
when their interface is misused. It would be nice to have an ability to do so as well. (Perhaps, even change the default to promote such practice?)An article about a cute language that does error handling the right way.