I am delighted to hear that you will be publishing every month now. While it may be possible to get too much of a good thing, one C Users Journal per month is still a long way from too much (perhaps your staff has a different view).

There are two things in the November issue that cause me to write. First is Jay Martin Anderson's generally excellent overview of the IEEE-488 interface bus. Normally, using "HP-IB" and either "GPIB" or "IEEE-488" as synonyms causes no great confusion. However, I think that Prof. Anderson's article may be an exception to that rule. Let me provide the precise meaning of each term, and then indicate why I believe that the equivocation of these terms has presented a problem in his piece.

"IEEE-488" is the generic way of identifying the standards document, "IEEE Standard Digital Interface for Programmable Instrumentation," produced by the IEEE. The designation "GPIB" (General Purpose Interface Bus) is the generic term for the interface bus. "HP-IB" (Hewlett-Packard Interface Bus) is a term used by Hewlett Packard to designate both the IEEE-488 electronic standard and HP's software protocol for using the interface.

The most serious error in the article that comes from equating HP-IB with IEEE-488 is the assertion that "any instrument which claims adherence to the IEEE-488 standard must be able to respond to a serial poll." (page 29). In fact, the IEEE-488 standard specifies many allowable subsets of the full interface. Included among these are nine "Allowable Subsets to T Interface Function" (table 11 of the IEEE-488 standard.) "T" is the basic talker function. (There is a precisely analogous TE — extended talker — with the same nine subdivisions of that function). Of those allowable functions, five do not support serial polling. However, one is the degenerate case of no talker capability, TO. Obviously, any instrument that cannot talk cannot answer a serial poll. So, after acknowledging that it is legal for an IEEE device to not support talking at all, the more accurate picture is that half of the talker options that "adher[e] to the IEEE-488 standard" do not support serial polling. While it is true that HP-IB uses serial polling, there is no such requirement from the IEEE.

I do not want to exaggerate the significance of Prof. Anderson having elided the HP-IB and the IEEE-488 specifications into one. In general, his article is an excellent introduction to the HP-IB. However, it is worth recognizing that it is not an introduction to the GPIB as such.

The second thing in the November issue that I wanted to respond to was Jeff Saraiva's request in "Q?A!" for programming examples using the Microsoft C v5.1 compiler's graphics library. I am sending a copy of my FTGRAPH, which is a tool kit of FFT functions. It uses the MSC 5.1 graphics library for its screen output (MSC_GRPH.C is the source file). While it is not a particularly extensive graphics application, it does illustrate determining the graphics adapter at runtime, and scaling the output to the actual adapter's resolution. It also shows how to use both text and graphics with the graphics library. You may include it in the C Users Group library if you think that it is suitable. You should note, however, that the front-end (FTGRAPH.C) is quite ragged. The library routines have evolved over the last few years to meet my employer's needs, but the front-end was written on my own time as a way of providing a tool kit to accompany an article on FTs that I wrote for Intelligent Instruments and Computers. I think the library is a reasonably polished, professional product. The front-end is a good example of what you get for nothing. I include a reprint of the article, in case Mr. Saraiva is not familiar with the FT and what it can be used for. I hope it is not too trivial a graphics application to be useful to him.

Sincerely,

Tom Clune
Eye Research Institute
20 Staniford St.
Boston, MA 02114

Thanks for the HPIB/IEEE 488 clarification. We have passed your graphics library on to Kenji for evaluation. We'll also pass a copy immediately to Saraiva. I think "How to determine adapter type at runtime" would be a good article by itself. Any authors? —rlw

Dear Robert,

I just finished reading the Jan 1990 issue of CUJ (again, an excellent job, guys). I want to respond to one of your reader's (Dr. Whitaker of Boston, MA) requests for texts on "grep", "awk", "sed" and "tr" as well as to one of the articles which I found to be most interesting.

First the texts.

1. AT&T UNIX Programmer's Manual Volume 4 titled Document Preparation, edited by Steven V Earhart, a CBS College Publishing by Holt, Rinehart and Winston (HRW), ISBN 0-03-011207-9

2. AT&T UNIX Programmer's Manual Volume 5 titled Languages and Support Tools, edited by Steven V. Earhart, a CBS College Publishing by Holt, Rinehart and Winston (HRW), ISBN 0-03-011204-4

These two texts are probably the most complete descriptions of the utilities in question and describe everything you ever wanted (and never wanted) to know about them, complete with examples and option descriptions.

The next text I would recommend is UNIX Utilities by R. S. Tare published by McGraw-Hill, ISBN 0-07-062884-X

This book is a programmer's reference and makes some assumptions about how much the reader knows about programming in general. This book would probably not be a good teaching guide but it's a great reference.

Lastly, I would recommend the following Bell Laboratories, technical memoranda.

1. SED — A Non-interactive Text Editor, by Lee E. McMahon, dated August 15, 1978.

2. AWK — A Pattern Scanning and Processing Language, by Alfred Aho, Brian Kernighan and Peter Weinberger, dated September 1, 1978.

I realize that these two documents might be more difficult to get ahold of, but they are excellent user guides and no more than 10 pages.

Next I would like to present an "addendum" to a very well written article entitled UNIX 'termcap' Facility Improves Portability by Ronald Florence. I realize that the article was about the 'termcap' facility but since he did mention the 'terminfo' facility, I wanted to present some additional information about it, to you. If after reading this letter you think that a more "in-depth" article or tutorial about it may be of interest to your readers, I would be more than happy to contribute.

First let me say that none of this information applies to any UNIX versions prior to UNIX System v2 but I would strongly recommend upgrading to, at least, UNIX System v3 as soon as possible. The added security measures and bug fixes are well worth it! Well, back to the article.

Mr. Florence stated in his article that "The termcap database is substantially easier to modify..." than the terminfo database. I must disagree with this statement. On most (if not all) UNIX systems that use 'termcap', the database can only be modified by the system administrator (or super user) and rightly so. If you, yourself, are not the super user, experimental (trial and error) modifications to terminal descriptions are impractical to say the least. With 'terminfo', the user is free to experiment with a terminal description that only he or she will use (at least until it's fully tested).

In order to write a 'terminfo' terminal description, you will need at least the following: section 4 of the UNIX programmer's manual (TERMINFO(4)) and the technical reference for the particular terminal you wish to build a description for. Only with this information is it possible to write a terminal description.

In order to use the "new" terminal description, it must be compiled using TIC(1M) the terminfo compiler. The procedure is simple, once the terminal description file is complete, just type

tic filename

In order to make use of this file, the user must define and export the environment variable TERMINFO equal to the directory under which the subdirectories were created. The user must also define and export the TERM variable equal to the appropriate terminal name.

For example, in the users ".profile" file have the following:

# (assuming "termdefs" contains the description file)

TERMINFO=${HOME}/termdefs
TERM= at386
export TERM TERMINFO

Much of this information can be found in the various sections of the UNIX manuals and there are also several books (and memoranda) on the subject. For the convenience of your readers, I have enclosed a couple of sample listings for 'terminfo' descriptions.