Steve, Am 01.01.21 um 02:34 schrieb Stephen Casner:
Regarding command options: for my latest command addition (obdii requests) I checked if we can use getopt_r(). Problems are a) it's not in the newlib included in esp-idf, and b) we also would need to change all handler signatures to allow getopt to modify the argv array. I also checked if some clever C++ getopt class is available but found none. Another option (pun intended) would be to stick more with the original parser design with trailing positional optional parameters rather than prefix option flags. Option flags are familiar to many of us developers, but that might not be the best choice for implementation here.
Positional optional parameters don't grow well for multiple options, force users to a fixed argument scheme and tend to produce hardly readable commands. I also think command options are for experienced/advanced users, and those are familiar with the concept. Extending the parser to support command argument templates would be an option, but I had the impression that would add a lot of complexity, and would only benefit a small set of (advanced) commands. (Side note: regarding command templates, I really liked the AmigaOS template scheme, IMO a shame it didn't get adopted more widely.)
Now, I'll admit that the obdii command has complex options that may need to be implemented as you have done. However, let me cite one counterexample:
Usage: event raise [-d<delay_ms>] <event>
This could have been done like homelink:
Usage: homelink <homelink> [<duration=1000ms>]
The latter form would be cleaner in that you wouldn't have to type the -d prefix. Also, the tab completion that I implemented before you added the delay option is now broken, although it would not be hard to fix.
Agreed for the case of a single option and a command that's not supposed to grow any new features. I did so on some of the CANopen commands. But imagine we need to add another numerical option to "event raise": nice and clean by prefix options, a usability nightmare with positional args. I wasn't aware of the tab completion on "event raise"… I normally use the command to raise custom events only. I'll fix that.
With the flexibility to have intermediate parameters now, using the validate function, it may fit reasonably to have the options handled by a subtree.
-- Steve
Do you mean a secondary option subtree triggered by the "-" prefix, inherited to the regular command subtree? That would allow simple tab completion on options as well… sounds like a nice idea. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26