Browse Prior Art Database

Command Capture

IP.com Disclosure Number: IPCOM000181700D
Original Publication Date: 2009-Apr-09
Included in the Prior Art Database: 2009-Apr-09
Document File: 3 page(s) / 133K

Publishing Venue

IBM

Abstract

During the process of administering a operating system, there are often a large number of tasks performed on the command line or terminal window. Most system administrators like to keep track of what tasks are performed, and how they were done. There are existing tools which are great for recording command and re-executed those same commands. However, the burden is on the user to filter through this script file and make modifications such as changing the order of the command executed, adding comments reflecting what is getting accomplished by the command, or updating parameters passed to those commands. Here we describe a system which allows the administrator to quickly scroll through a list of commands executed during a particular terminal session, make modification to information relevant to those commands (such as parameters and comments), and change the order of execution of those commands (command B gets executed before command A).

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 54% of the total text.

Page 1 of 3

Command Capture

During the process of administering an operating system, there are often a large number of tasks performed on the command line or terminal window. Most system administrators like to keep track of what tasks are performed, and how they were done.

Keeping track of tasks performed is key in customer support. For example, software vendors who offer product support carry a liability when their customers make support calls. When support representatives instruct customers to make changes to their machines' operating system, drivers or other peripheral firmware or software, they do not record and store these troubleshooting changes. Troubleshooting variability and complexity can stop later attempts by other support agents or the customer to restore the machine to it's original state. This lack of process accountability and documentation can lead to customer satisfaction issues and further complicate future support efforts. The result could lead to excessive use of vendor support or customer attrition lowering the ROI of product sales and subscriptions significantly.

Capturing and storing the changes made at the UI on a machine can resolve these costly sales issues. A log of the changes made to a machine can help to reverse the process or carry on without the need to start from scratch.

Historically there are tools in place for capturing this sort of information. These tools, such as Rational Function Tester, Rational Rose, Segue SilkTest, and Autoit are used for recording and playing back GUI operations, but none of these focus on command line operations to the extent proposed in this disclosure.

For example, there is a system tool in most Unix systems called script, which works as follows:
1. The administrator types script and hits enter.
2. The administrator enters commands in the same terminal window as normal.
3. The administrator types exit.
4. A new file is created called typescript (default name assigned) which contains the commands executed in step 2.

These tools are great for recording command and re-executing those same commands. However, the burden is on the user to filter through this script file...