> On Nov 3, 2014, at 8:16 AM, Bruce Richardson <bruce.richardson at intel.com> > wrote: > > On Mon, Nov 03, 2014 at 02:08:46PM +0000, Wiles, Roger Keith wrote: >> >>> On Nov 3, 2014, at 4:41 AM, Bruce Richardson <bruce.richardson at >>> intel.com> wrote: >>> >>> On Sun, Nov 02, 2014 at 04:28:28PM -0600, Keith Wiles wrote: >>>> Allow for a external parser to handle the command line if the >>>> command is not found and the developer has called the routine >>>> int cmdline_set_external_parser(struct cmdline * cl, >>>> cmdline_external_parser_t parser); >>>> function to set the function pointer. >>>> >>>> The function for the external parser function should return >>>> CMDLINE_PARSE_NOMATCH >>>> if not able to match the command requested or zero is handled. >>>> >>>> Prototype of external routine: >>>> int (*cmdline_external_parser_t)(struct cmdline * cl, const char * buy); >>>> >>>> Signed-off-by: Keith Wiles <keith.wiles at windriver.com> >>> >>> Hi Keith, >>> >>> what is the expected use case for this? Is it for embedding other >>> programming languages alongside the existing DPDK command-line or some >>> other purpose? [Perhaps the use case could be called out in the patch >>> description] >> >> Hi Bruce, >> >> I guess the external parser could be used for other programming languages, >> but the case I was looking at was to provide a default escape from the >> command line parser to allow my application to handle the commands not >> understood by the parser. Now that you point it out I could use something >> like ?%<line-of-script-code>? to execute a single line of script code, which >> is a good idea (thanks). >> >> One case I am looking at is when you want to execute a command and do not >> want to add the support into the commands.c file for every possible command. >> Take the case where you have a bunch of scripts (Lua) in a directory much >> like a bin directory. Then you could type foo.lua or foo on the command line >> and execute the foo.lua having the application detect you want to load and >> run a Lua script after it has finished parsing for the builtin commands. >> >> For Pktgen I had to add a command called ?run <filename> <args?>? to support >> running a script with arguments. I also needed to add a argvlist type to >> cmdline to not error out on that command and split up the args into a argv >> list like format. (Maybe I need to submit that code??) It seemed more >> straight forward to just pass the command line to the application to run the >> command. I understand that seems like a minor point, but it does make it >> easier to use and to support the features I want to support in my PoC. >> >> Using this method you can just type the name instead of something like ?run >> foo.lua? or just ?run foo? and let the code figure out what to run. I have >> more plans for this features as well and have not finished the basic PoC >> yet. If you want a peek I can show you what I am working on currently. >> >> Does this help and do I really need to add all of this to the commit message >> :-) >> > Thanks for the explanation. However, if you are looking to have the > application handle a bunch of commands itself, why does it need to use the > commandline library at all? Why not just have the app handle all the commands > instead of some of them?
I guess that would be reasonable, but then I would have to add support for all of the command line parsing being done in the cmdline code. Think of this as a default case for the parser and to me that makes more sense then just doing my own command line design. In the cmdline code you guys provided is a lot of features like history, control key support, arg parsing (IP, MAC) and many others. I would rather not have to write that code myself. The default case is the same behavior today, with giving a no match error unless they add the external parser. > > /Bruce Keith Wiles, Principal Technologist with CTO office, Wind River mobile 972-213-5533
