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.