Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Automated parsing of commands entered into a command line interface

IP.com Disclosure Number: IPCOM000184991D
Original Publication Date: 2009-Jul-07
Included in the Prior Art Database: 2009-Jul-07
Document File: 4 page(s) / 63K

Publishing Venue

IBM

Abstract

Applications that provide a command line interface (CLI) have traditionally written code to parse commands in a way that is often hard coded and usually highly dependent on the syntax of the supported commands. The supported commands are usually independently documented. This article describes the automatic parsing of CLI commands against syntax definitions defined in an XML schema that provides a high level of abstraction so that syntax changes do not mandate code changes. It also describes how user documentation and command usage summaries may be automatically generated from the XML command definitions.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 29% of the total text.

Page 1 of 4

Automated parsing of commands entered into a command line interface

Applications that provide a command line interface (CLI) may support a rich set of commands, each of which has its own syntax with options, option values and arguments. When a user enters a command, the application has to parse the command, validate it against the correct syntax for the command, and determine what options and values are to be provided as inputs to the operation to be performed. Product documentation is expected to accurately document the syntax and usage of CLI commands supported by the application. There is often a requirement for the application to show accurate usage information that summarizes the syntax of a command.

Currently, there are two approaches commonly used by applications:
1. Hard coding - the application has specific code to parse each command. This requires significant implementation effort to develop and maintain. Changes to syntax of command always require coding changes. Keeping the parsing implementation, syntax description in the product documentation, and usage summaries of commands all consistent relies upon a lot of manual and error-prone work. Over time, all three tend to diverge leading to a poorly documented product and one that may have inconsistent behaviors across its commands.
2. Use of parsing definitions in application source code. In this approach, source code is written that contains the implementation of commands and the syntax of the command. Examples of prior art here include args4

j

ava.net/)*

and Ray Hayes's CLI project (http://www.codeproject.com/KB/recipes/commandlineparser.aspx). These are based on the idea of annotated source code from which a CLI parser can be generated. In some cases, it is possible to generate syntax descriptions from the automatically generated parser. However, the definition of the command syntax is still embedded within the code and more structured fragments for inclusion into product documentation is not possible.

  Neither of these approaches provide solutions to the following requirements: Abstraction and separation of the definition of the syntax of a command from the

a.

code that implements the command. This allows the syntax of a command to be changed without impacting the source code of the command that executes the command. It also allows a single command implementation to be used with several different command syntaxes. This results in greater reuse of code and consistency across the commands supported by the application.

Command syntax should be defined as pure data, preferably in an appropriate

b.

XML schema. This allows syntax changes to be made without the need to modify or regenerate source code.

It should be possible to define the syntax of multiple commands.

c.

It should be possible to define the types of values that are inputs to the command

d.

and how these shall be validated and, if appropriate, transformed.

It should be poss...