EARLIER FEATURES

FEATURES CONTENTS

LATER FEATURES

SOFTWARE TOOLS

Don Skene

The following article is reprinted from the ICPUGSE Newsletter, (Numbers 167, 168), with the permission of ICPUGSE and the author.

ICPUGSE can be found at: http://www.icpug.org.uk/se

In 1976 Kernighan and Plauger published a book called Software Tools. At that time the programming languages commonly available were assemblers and Fortran plus Cobol for business and Basic, but Basic was very basic.

The main thrust behind Software Tools is that programs should be written to be as simple as possible and to do just one thing. As such they are more likely to be reliable and produce the correct answer. As an example they demonstrated a sequence of programmes that could be put together to make a spelling checker. The first, words, reads a text file and outputs a file with each word on a single line, with no punctuation or extra spaces. This output is read by lc, which converts all the text to lower case, and whose output is read by sort to put them in alphabetical order. Finally, unique, deletes all sequences of multiple words, thus creating a file of the unique words in the original text. The odds are that these are spelling mistakes.

Such a spell checker is easy to write and doesn’t require a dictionary. It is not much good for chronic miss-spellers who don't remember "i before e except after c" and always spell "their" as "thier" (as I finally got Word to do). But, with their approach, you could write mistakes, which reads the output of sort and a similarly prepared file containing a list of common spelling mistakes. If mistakes finds a match then it removes any duplicate entries so that unique will treat the remaining one as a mistake. Thus you can gradually refine a process without altering the steps you have taken so far, so avoiding the risk of introducing errors.

I have recently written scrubbit to overwrite the contents of a file prior to deleting it. All it does is open a file in read/write mode, fill it with x’s and then close it. If I then open the file in Wordpad, it does indeed consist only of x’s. The tool was very simple to write. The problem is making it easy to run under Windows or other GUI environment.

In Windows you can set up a terminal and run programmes as we did in the days of MS DOS. I don’t do it very often and I’m out of practice. Secondly, we tend to have many more folders, often with long names containing embedded spaces that have to be included in quotes. This results in a lot of typing and spelling mistakes. One way round this problem is to use the Windows SendTo folder.

To see the SendTo folder, run "Windows Explorer" and right click on any file or folder. Up pops a menu with a list of items, including one named "Send To". Click on Send To and up pops another menu. Mine contains a list of 12 items. In Windows XP you can find SendTo under "C:\Documents and Settings". You will find it under your user name. It is more difficult in Vista. Click on the C drive, Users and then your user name. Then search for SendTo. You will have to use an advanced search and tell it to include windows and system folders. However you find your SendTo folder, open it as a small explorer window and put it into a corner of your screen where you can get at it easily. Note that each user has their own SendTo folder.

To show how the SendTo folder works, create a folder called Toolbox somewhere convenient and in it create a text file called Path.bat containing the following code:

Now create a short cut to Path.bat, put it in your SendTo folder and rename the short cut to GetPath. Now comes the magic. Using Windows Explorer, right click on any file or folder, select SendTo and double click on GetPath. A command window will appear displaying the complete path to the folder or file you selected. Now edit Path.bat and change the echo command to:

Repeat the right click performance and you should be able to double click on paths.txt to display the complete path again. This time, however, you can highlight the path and press Ctrl-C to copy it to the clipboard. The double chevrons mean that each time you run the command it adds another path to paths.txt.

For scrubbit I created the following text file called Scrubbit.bat in my Toolbox folder:

Now, if I ever want to overwrite a file, all I have to do is right click on it, select Send To and double click on scrubbit. I delete the file separately. I’m afraid that if I programme scrubbit to do so, Windows will decide that overwriting the file is unnecessary because it is going to be deleted anyway.

Obviously we can go on adding any tools we want to use, but could end up with a long list. An alternative is to put your Toolbox folder in the SendTo folder. The Toolbox folder then appears as a menu item with all the tools in discrete submenu, which can have subfolders (ad infinitum?). This means that my batch files have a working directory in:

"C:\Documents and Settings\Don\SendTo\Toolbox"

I find this a nuisance so all my batch files set a working directory explicitly:

where E:\Don is the special Windows folder "My Documents".

While using the SendTo folder resolved the problem of having to type long file paths I dreamed of a better approach. I would develop a graphical user interface application that would be a flexible way of running any number of tools. After a few experiments I found that it could be done quite easily. I call the program Toolbox and I have written it using Microsoft Visual Basic 2008 Express Edition based on .NET Framework Version 3.5 SP1 , both free downloads. You can also use Visual Basic to write tools, which Microsoft describe as console applications.

Stripped to its bare essentials, ToolBox is a dialog box containing two controls: a list box displaying a list of tools and a text box for entering their arguments. ToolBox sits in a folder I call ToolBox with a sub-folder called Tools. Its current state is illustrated below.

When you start it, ToolBox loads the list box with the names of the files it finds in its Tools folder. Enter any arguments you want into the text box. If you want to specify a file you can drag and drop or copy and paste from Windows Explorer.

When you are satisfied, double click on your chosen tool to run it. In the illustration I had selected ShowArgs.exe, clicked on Name to generate a file name for its output, added the redirection and then clicked on Show Me to generate the output on the status line. This output is the text of the argument that would be sent to the Shell function.

A tool is run by calling the Visual Basic Shell function:

Shell(prefix & tool & arguments)

In this form, the Shell function takes one string argument that I have shown as three concatenated components.

• Prefix is "cmd.exe /K ". This causes a tool to be run in its own window that remains open when it terminates, so that you can see the output and any error messages. Cmd.exe also processes short cuts, opens files for stdin and stdout on redirection, and processes file associations (essential when running scripts such a PHP, Python, etc).
• Tool is the path to the selected tool.
• Arguments is built from the text in the arguments box, with any new line characters replaced by spaces. If you have selected (highlighted) any text, then only that text will be used.

A tool is anything that can be used at a command prompt and must be in the Tools subfolder. The only rule I impose is that it must have an extension. Files without an extension are ignored. If you use a short cut or a batch file, then the actual program used can be stored anywhere in the computer. With a batch file you can also build in options and other arguments. I also decided to allow ini files with the following structure:

If you include more than one tool entry in the Toolbox section, the last one is used. There can be any number of argument and file entries in any order. They are copied to the arguments box in the order of entry. All entries in the Toolbox section have leading and trailing spaces trimmed. No quotes are needed if tool and file entries have embedded spaces because they will be added automatically. Tool and file can have relative or absolute paths. If there is more than one Help section, the first one is used. The text is copied to a textbox for display.

Ini files and batch files both allow you to store your programmes away from the Tools folder. An ini file allows you to copy the file and argument entries to the arguments box before running the tool, so that they can be edited to suit the particular occasion. With a batch file you would have to edit that file, with the risk you will never be quite sure what the state of the file will be when you want to use it again.

Toolbox.exe and its source code are available for download from the following zip file:

toolbox090.zip

There are a few general points worth making.

For those not familiar with the command line it can be important to know the working folder, which may not always be what you expect. In the past I found that, when running batch files, the working folder was the one containing the batch file but this is not always the case when using ToolBox. You can avoid this problem by using complete paths but this means that Toolbox is not readily re-locatable. I include ShowArgs.exe with ToolBox. It lists its current working folder and command line arguments, useful for debugging.

Unexpectedly, I sometimes found Microsoft Word and Excel to be handy tools for viewing output. Word can be faster than Wordpad at loading large text files because Wordpad loads the whole file before displaying anything, while Word only loads enough to get going. Excel can be useful for displaying test files with lots of tab characters in each line and you want to do calculations on numerical data.

TOP