Browse Prior Art Database

Method for rule-based analysis of command-line tool output to enable integration

IP.com Disclosure Number: IPCOM000016436D
Original Publication Date: 2001-Dec-10
Included in the Prior Art Database: 2003-Jun-21
Document File: 4 page(s) / 53K

Publishing Venue

IBM

Abstract

Published December 10, 2001 in a public open source project.

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

Page 1 of 4

Method for rule-based analysis of command-line tool output to enable integration

This invention is a method for integration of arbitrary command-line tools into an object-based model, typically driving (but not limited to) a graphical system such as an IDE (Integrated Development Environment ).

Background

There is at least one design decision that is almost guaranteed to arise during the development of any IDE: "How do we handle integration of command-line tools?" The reason this decision is so important is obvious: There are many users who simply can't live without their favorite command line tools. These tools can range from simple file-system browse&search utilities like ls, dir, find,or grep all the way to full-blown applications such as compilers or debuggers.

Problem & Invention

Typically command-line tools such as compilers (gcc, xlc), debuggers (gdb, dbx), system utilities (grep, find) or even command-line games (chess, blackjack) have structured output that can be analyzed to provide some graphical support in an IDE. While it is fairly straightforward for IDE designers to provide the user with an integrated console to launch the command-line tools, it is not nearly so easy to do something clever with the output (and without some value-add for running the commands inside the IDE, the command-line user will likely resort to just using their favorite shell, which could then impede adoption of the IDE).

In most cases when IDEs make the decision to support command-line tools, it is done by pattern-matching the command output from a limited set of tools such as compilers, linkers or makefiles, and is intended to serve a single purpose in the IDE: to find references in the command output to source locations and then make these locations "clickable". Clicking on these lines takes the user to the corresponding source location in an editor. Some IDEs add a few more patterns to graphically distinguish between various types of source locations such as errors, warnings or informationals.

This invention supports the type of functionality described above, but also goes much further and introduces several new concepts. Before we go any further let's consider a very simple example of support that the current invention supports that is beyond the scope of other related support.

Simple Example

Let's consider the Linux\Unix system-utility nm. It is a command-line tool that takes a object file as an argument and then displays the list of symbols contained in that object file. Here is how it is typically used:

$ nm main.o
080494fc ? _DYNAMIC
080494dc ? _GLOBAL_OFFSET_TABLE_
080484b4 R _IO_stdin_used
080494d0 ? main
080494cc ? doubleIt
080494d8 ? tripleIt
080494d4 ? quadrupleIt
....

output continues
....

1

Page 2 of 4

Now imagine that after running the "nm main.o" command from a console view in an IDE, the output above was analyzed using the appropriate pattern definitions for the nm command and based on those patterns Objects were created that appeare...