Browse Prior Art Database

A Technique for Creating a Syntax Free Command Line Disclosure Number: IPCOM000242420D
Publication Date: 2015-Jul-14
Document File: 4 page(s) / 57K

Publishing Venue

The Prior Art Database


Creating a Command Line Interface (CLI) for a program or a product is a common task. Throught CLI the user can give commands to the program, that can react accordingly. In order to correctly understand the command, the user cannot express it in a natural language, because often natural language is ambiguous and complex to interpret. So, CLIs like shells for operating systems, always define a syntax that allows to give commands in a formal way/non ambiguous way, but that is far away from the way the user would like to express the command in a natural way. Moreover, CLI syntax, always use separators which are non-letters : "," or "@" or "$" are commonly used to label token to give a particular semantic. Especially, when using mobile devices, CLIs are difficult to use, for mainly two reasons: - syntax must be known and remembered by the user. But it is easily forgotten, due to the distance from the natural language. - using complex syntax is more difficult when using a small size - mobile device. Tokens are also less accurately; e.g. to say kill, user will often fail writing koll due to virtual keyboard. Here is disclosed a method for creating a command line interface which is syntax free, the command being interpreted by trying to understand the semantic of each token, and how the tokens can be combined together. The article provides a way to create a simple command line parser, that can act effectively as a natural language recognitor for commands, but without having the complexity of a native language parser, allowing to create commands that are more similar to the natural languages.

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

Page 01 of 4

A Txchnique for Creating a Syntax Free Command Line

    A simple command line paxser, that can act effectively as a natural language rxxognitor for commands allxwing to creaxe commands that xre more similar tx the natural languaxes can be illustrated, taking as example the comxaxd line of a product or an xperating systems that deals with jobs or processes. An example command is the "xill" action to a Job.

Supposx that the XXX interfxce, the commaxd to xill a job is: xill





The positiox of the strxngs inside the command line, it defines the xole of txe tokxn.

    In the solutxon proposed, eacx command is supposed to be a trxple

which A is the action, O is (one or moxe) object anx P are the parameters of the action.

    The action can be, for example, the "kilx" action. Associated tx an action there are xne or more "synonym" worxs that can represent it. For example to the kill action, the list of synonyms may be "kxll", "stox", "end process".

    But actions cannot be performed on any objects; action can be performed only on such clxss of objecx that we call "ObjecxTyxe". So a valid cxmmand is a triple

where the action X can be xerformed on the class of object O.

    Fxr example, the action "xill" is defined on objext of type "JobInPlan". Suppoxinx to have a command

where A is the "kill" action, the command is a valid command only if "O" is xf one ox the type sxpported by the action "kill".

    A valid action, is a command that can be really performed on the system; one way to execute the command can be to translate into a command of another CLI and execute it.

    To transform a command expressxd in a natuxal language like (e.g. kill the job MYJOB) into a valid command, the system acts this way:

1. Splits the origxnal string into tokens 2. Searches into the tokens for one or morx action (xet's call them XX). For each action search also for parameter P 3. Searches into the tokens for any object known (let's call them OO)

4. Examxnes the tokenx that could not be cxassified bx steps 2 and 3, and classifies them according to additional criteria lixe for example:


Page 02 of 4

· the sxt OO is empty: relax mxtching cxiterix (x.g. incrxase string distance by 1) and scan unclassified tokens

· the set AA is emptx: relax matching criteria (e.g. increase string distance by 1) and scan unclassified tokens

· txken may xotentially belong to both sets (AA and OO): see how the xhrase is constructed and pick the best match between action axd object

Then for xach action X in AA, and fox each object O in OO

If X is defined for the objecx txpe of O, produce the command

, where P has been obtained one step before.

    The searcxes for actions and for objects are not related to a particular syntax, so axy command can...