The C Users' Group Library 1994 August

home *** CD-ROM | disk | FTP | other *** search

/ The C Users' Group Library 1994 August / wc-cdrom-cusersgrouplibrary-1994-08.iso / vol_100 / 137_01 / dec83col.ddj < prev next >

Wrap

Text File | 1979-12-31 | 15KB | 304 lines

.pl 60 .po 0 .. .. "The C/Unix Programmer's Notebook" .. .. DDJ Column #2 as of 19-Sep-83 .. (C) 1983 Anthony Skjellum. All rights reserved. .. For publication in DDJ .. .. .. file (DDJCOL2.WS) created: 19-Sep-83 .. updated: 24-Sep-83 .. updated: .. .. completed: 25-Sep-83 .. .he "C/Unix Programmer's Notebook" by Anthony Skjellum. (C) 1983. For December, 1983, DDJ. A Correction In the last column, several references to the book The C Program- ming Language and its authors were made. Through my error, Brian Kernighan's name was misspelled consistently throughout the column. I'm sure that many readers noticed this immediately. Unfortunately, I didn't until I saw the column in DDJ. Introduction In this second Programmer's Notebook, I'll discuss how Unix-type environments can lead to non-interactive, and user-unfriendly software. This is based on experiences I've had with several Unix and Unix-like systems running both standard and Berkeley Unix. .. Last time, I discussed incompatible linkage formats and runtime .. libraries of C compilers in both the eight and sixteen-bit world. This .. time, the discussion will concentrate on problems and difficulties I've .. encountered through in with linkers and C libraries in my work under MS- .. DOS. Skimming through the ads in the October DDJ, I noticed that nearly twenty-five percent of the ads concerned or mentioned C or Unix. Most of them concerned C. This indicates strongly that C and to a lesser extent, Unix, are popular items with DDJ readers. I also hope that reader input will be significant as it has been with other DDJ columns. I also saw an extremely interesting advertisement in the October DDJ. This was a Computer Innovations ad concerning the soon-to-be-released version of their C compiler. As an option, this compiler will produce programs/data exceeding the previous limit of 64K segments imposed by all 8086 compilers (C or otherwise) that I've seen. Look for a review in this column early next year. Unix and non-interactive Software The Unix operating system was designed to reduce repetition of programming effort by permitting modular programs to be combined via pipes and tees. Since input and output are redirectable under Unix, simple programs could use console input and output for one application and be used as part of a pipeline for another. Thus, unmodified programs could be reharnessed for new applications to an extent not possible with previous operating systems. Pipes and input-output redirection are two of the best and well- known features of the Unix system. Microcomputer users have been very interested in adding these capabilities to their own operating environ- ments. In the eight-bit world, this has been done chiefly through special subroutine libraries such as "The Unica," or in C runtime packages. For MS-DOS 2.0 users, the features are built into the operating system. Despite the undisputed usefulness of pipelines and input-output redirection, their presence in Unix has lead to a serious drawback in the system's environment. This drawback is the proclivity to avoid interactive programs and to produce user-unfriendly software. Furthermore, the standard Unix console interface is weaker than under other operating systems. In the remainder of this column I will discuss these weaknesses as I perceive them. Non-interactive Software Because of the availability of pipes and input-output redirection, many Unix programs are designed to act as filters. Filters are programs which require a single sequential input data stream and produce a single output data stream. Such programs are suitable as pipe-fittings. Because of the way they handle data, they don't normally expect to be used interactively. In most cases this doesn't pose a problem for users. However, because such programs do not expect to deal directly with humans, but only with input and output streams, they can often be very unfriendly in the area of error handling. .. The problem in the Unix system is that the same terse philosophy applied to filters also pervades most of the software available. This includes programs which are normally executed sequentially by the user from the console. The problems come in several areas and some of these problem areas are listed in Table I. The following paragraphs will elaborate each of the points listed in that table. ---------------------------------TABLE I.--------------------------------- -----------------------(Unix software Problem Areas)---------------------- 1. terse (hard-to-remember) program names. 2. lack of program sign-on and sign-off messages. 3. lack of interactive mode to alleviate the need to re-execute a program several times to complete a set of operations. 4. inconsistent use of switch (dash options) for controlling the specifics of program execution. 5. lack of descriptive error messages. 6. cryptic, incomplete, and erroneous documentation 7. software bugs: un-documented and documented. 8. cryptic (or missing) internal help features. 9. poor console interface provided by Unix. 10. lack of system for finding program names by the function required. ------------------------------END OF TABLE I.------------------------------ .pa Terse Names Unix program names are usually two or three letters long and tend to be cryptic. While this saves typing for experienced users, its frustrating for new and occasional system users. Also, since the Unix system lacks an on-line indexing system for finding program names by function, it's not easy to find the right program based on the desired function alone. Sign-ons and Sign-offs Sign-on and Sign-off messages are a common courtesy in the computer world. Virtually all standard Unix programs lack these two simple features. While this is understandable for filters, it is completely unnecessary for other programs. For example, if two versions of a program exist on a system, the only easy way to distinguish them is by their sign- on messages. Besides sign-ons/offs, its also nice for a program to give progress reports during execution. This lets the user know how things are proceeding. Standard Unix software doesn't normally include such a feature. Internal Help Features Many programs include a feature summary option to help occasional and new users remind themselves of program operation. Many Unix programs also have this capability, but they are often extremely cryptic and include few English words to supplement the sample command line which they display. Figure I. displays a sample session in which a ficticious program (called fct) is executed from the shell with no arguments. The program responds with a cryptic help summary typical of actual Unix commands. In Figure II. the same fct program session is presented, but this time the program has been designed to provide a user-friendly help feature (and also to sign-on and off). ---------------------------------FIGURE I.-------------------------------- ---------------------------(Cryptic fct Session)-------------------------- $ fct <RETURN> (activate the program with no arguments) usage: fct -abcv file1..fileN (help message) $ (shell prompt) -------------------------------END FIGURE I.------------------------------ .pa --------------------------------FIGURE II.--------------------------------- --------------------------(Friendly fct Session)--------------------------- $ fct <RETURN> (activate the program with no arguments) fct (version x.yz) as of dd-mmm-yy usage: fct [dash options] file1...fileN dash options: -a perform function 'a' on files specified -b perform function 'b' on files specified -c perform function 'c' on files specified -v verify each step before proceeding note: -a, -b are mutually exclusive; -c may be used in conjunction with -b only. End of execution. $ (shell prompt) ------------------------------END FIGURE II.------------------------------ .pa Interactive Modes Interactive program modes provide a friendly environment for the user. When a program is used often, it may be executed several times consecutively. An interactive mode eliminates the need for consecutive execution since the user can enter all the commands in one interactive session. This avoids unnecessary user effort, and is probably more efficient from a system standpoint. One reason that the interactive modes are missing is the lack of support for expanding Unix wildcard filenames from within a program. I found this limitation rather arbitrary and so I wrote a program which solves the problem (see "Expanding Unix Wildcards," DDJ, November, 1982.) The lack of direct support for such a function indicates that the whole Unix philosophy is geared towards non-interactive software tools. Command-line Switches Unix program use command-line switches (dash options) to specify the particulars of program execution. Switches are usually a dash character ('-') followed by a single letter. Unfortunately, Unix programs use these switches inconsistently. For example, the rm command only permits switches before file names on the command line. Some programs permit several switches to be combined after a single dash character (eg -abcdef). Others use the plus ('+') character to activate a program feature and a dash to deactivate it. Generally, it is difficult to remember all the different possibilities, limitations, and defaults imposed by the various programs. The difficulties with command-line switches under Unix lead me to write the ARGUM package published in the August, 1982, issue of DDJ. In that article, I proposed a program which would handle switches in a consistent way. Existing Unix programs could be changed to use ARGUM and thus eliminate one degree of inconsistency from the operating environment. Alternatively, the less powerful Unix III getopts() facility could be used. Lack of Descriptive Error Messages The lack of descriptive error messages is a real problem, especially for inexperienced users. One offender is the eqn/troff system used for equation and text phototypesetting. These programs report errors as "Syntax Error" between two line numbers. They don't echo the erroneous text or equation and the line numbers aren't always useful because header files change the length of the source text. Another problem stems from the way Unix reports failures. Programs which attempt to open a file and fail get an error code. They subsequently report the failure as "Cannot open file." While this is correct, it doesn't tell the user if the file is non-existent or if a file protection violation has occurred. Similarly, when a user tries to change his current directory to one for which he has no read privileges, a "bad directory" message is displayed by the Unix shell. Documentation Documentation is a real problem in the Unix system. Most programs are documented in a standard form which is typically very terse. The examples provided are often very complicated, and don't clearly illustrate how to use the program for simple purposes. Because of the poor documentation, some casual users think of Unix systems as secret-societies since only the indoctrinated can tell them how the system and programs work. Another problem with documentation is that it sometimes doesn't reflect the current state of a program. Most notable on the system I use, are undocumented features of the standard Unix editor ed. The standard form provides no line edit command ('x') while the installed version does. Yet, the documentation does not explain this. Unix documentation is clearly the weak link in the system. It makes some of the mysterious concepts of the system seem impossible to grasp and reduces productivity through its terseness. Software Bugs Another problem which makes a Unix system user-unfriendly (actually user-hostile) is the presence of undocumented bugs in important software packages. For example, bugs exist in the eqn/troff system. These can be circumvented, but the methods are known only to a few experts. No generally available documentation exists for avoiding such problems. Since the Unix system comes with source code, it should be feasible for individual users to change system software to their specific needs. Unfortunately, the source code which accompanies Unix is mostly comment- free and is therefore difficult to understand without significant effort. User Console Interface The user console interface is not extremely good under Unix. For example, when a character is deleted, Unix does not actually remove the character typed but just moves the cursor back one space. There is no standard mechanism for having a line retyped, and backspacing after typing a tab doesn't produce the correct results. Furthermore, When a control character is typed, it is displayed in the form ^CHAR, but when deleted, the cursor moves back only one space (leaving the caret). The weak user interface points again to the philosophy that most software will not be interactive. However, the standard Unix editor makes no attempt to improve the interface for the purpose of interactive editing. It is so unfriendly that most users resort to other editors (usually screen editors). Programmers can only provide their programs with a superior console interface by using the raw terminal mode. Unfortunately, this mode is more expensive in terms of input-output cost. For user-friendly, screen-oriented software, its the only way to go. Conclusion Unix is a powerful operating system. However, the system philosophy has lead to a predilection against interactive software. In this column, I have discussed some of the aspects of Unix which make it user-unfriendly. I look forward to hearing from Unix users on how they perceive the Unix environment.