1. LiSA Cli Components +------------+ +--------------+ +------+ +----------+ | | | Readline | | LiSA | | LiSA | | CLI Parser |<-->| CLI |<-->| Menu |<-->| Command | | | | Abstraction | | Tree | | Handlers | +------------+ +--------------+ +------+ +----------+ ^ | | ^ | `..............+.............' `..................................' 1.1. CLI Parser - API for parsing Cisco-like commands; provides basic tokenizing functions and validation against menu tree structures. 1.2. Readline CLI abstraction - Integrates the CLI Parser with readline library, providing Cisco-like CLI behavior. 1.3. LiSA Menu Tree - Data structures for all LiSA CLI commands. 1.4. LiSA Command Handlers - Functions that actually execute the CLI commands. 2. CLI Parser Implementation Details (rest of) menu node array command to to lookup subnodes in parse (context) | | | const char *buf | struct menu_node *tree | | \|/ \|/ +-----------------------------------------------------------+ | | | Tokenizer Function | | | +-----------------------------------------------------------+ | | | | (struct | int | int | int | menu_node *) | | out->offset | out->len | out->matches | | | | \|/ \|/ \|/ \|/ status token token matching offset length subnodes array The tokenizing function is initially called with the whole command as input and the root menu tree node as context. As it extracts the first token from the input, it is iteratively called on the remaindering input (buffer). For each extracted token, the context (subnodes list) descends in the menu tree. The tokenizing function skips initial whitespace and returns the offset of the actual token within the given buffer, and the token length. Therefore, it is appropriate to increase the buffer by the sum of out->offset and out->len prior to the next call. 2.1 Command help examples In the following table, size means the number of (non-null) components in the matching subnodes array (by convention, the list ends at the first null component) and status is the return value of the tokenizer. Command Output on Cisco CLI size status ----------------------------------------------------------------- "is a?" access-group address 2 0 "is a ?" % Ambiguous command: "ip a " 2 1 "ip addr 192.168?" A.B.C.D 1 0 "ip addr 192.168 ?" % Unrecognized command 0 1 "sh ver?" version 1 0 "sh ver ?" 1 1 "sh jjj" % Unrecognized command 0 0 "sh jjj " % Unrecognized command 0 1 For size, there are 3 possible cases: 0 No match (syntax error) 1 Correct or unfinished command larger than 1 Ambiguity For status, there are only 2 possible cases: 0 Buffer ends with this token and there is nothing more to parse 1 There is more input to parse The actual case is determined by both size and status. The logic to iteratively call the tokenizer and determine the case is implemented at the next layer (CLI Abstraction). Parsing patterns (such as ip addresses in the example above) is accomplished through custom tokenizing functions (that do more than just looking up the token in the subnodes array). There are 2 more possible conditions: Condition size status ----------------------------------------------------------------- Empty buffer (or only whitespace in buffer) 0 0 Trailing whitespace at end of buffer 0 0 Distinguishing between the two conditions is done in the next layer logic, by counting the tokens: the first happens when there is no previous token, the second happens when there is at least one previous token. The second condition happens because the tokenizing function skips whitespace at the beginning of the buffer and stops at the first whitespace character after the token. Therefore, a subsequent call to the function will happen after getting the last token. To distinguish between a non-existing command (such as "sh jjj") and the two whitespace condition (both return size = 0, status = 0), the next layer must look at out->len, which is 0 for whitespace and non-zero for erroneous commands.