On the etymology of dsw
utzoo!decvax!ucbvax!unix-wizards
utzoo!decvax!ucbvax!unix-wizards
Thu Aug 13 11:11:53 AEST 1981
>From clyde at UTEXAS-11 Thu Aug 13 11:00:59 1981
Date: 12 Aug 1981 07:48:54-PDT
From: CSVAX.uucp at Berkeley
To: rnews at utexas
Subject: network news article
Aresearch.20
NET.general
csvax.mhtsa!research!dmr at Berkeley
Wed Aug 12 00:35:06 1981
etymology &c
I would advise taking uiucdcs!jerry's account of history and
motivations with a healthy dose of salt. However, his heart's in
the right place (unlike some).
A while ago someone asked Ken Thompson what he would do differently
if he were to do Unix again. The answer: "I would have called it
create instead of creat." Well, my answer is that I would have
fixed the stupid dsw manual page. Fortunately, I can atone
by publishing a correct account (not the real 1970 manual page,
but an incredible simulation).
Date: 12 Aug 1981 08:48:54-PDT
From: CSVAX.uucp at Berkeley
To: rnews at utexas
Subject: network news article
Aresearch.19
NET.general
csvax.mhtsa!eagle!research!dmr at Berkeley
Wed Aug 12 00:02:17 1981
dsw manual page (honest)
DSW(1) UNIX Programmer's Manual DSW(1)
NAME
dsw - delete from switches
SYNOPSIS
(put number in console switches)
dsw
core
DESCRIPTION
_d_s_w reads the console switches to obtain a number _n, prints
the name of the _n-th file in the current directory, and
exits, leaving a core image file named _c_o_r_e. If this core
file is executed, the file whose name was last printed is
unlinked (see _u_n_l_i_n_k(2)).
The command is useful for deleting files whose names are
difficult to type.
SEE ALSO
rm(1), unlink(2)
BUGS
This command was written in 2 minutes to delete a particular
file that managed to get an 0200 bit in its name. It should
work by printing the name of each file in a specified direc-
tory and requesting a `y' or `n' answer. Better, it should
be an option of _r_m(1).
The name is mnemonic, but likely to cause trouble in the
future.
Printed 8/11/81 PDP-7 local 1
Date: 11 Aug 1981 19:22:57-PDT
From: CSVAX.uucp at Berkeley
To: rnews at utexas
Subject: network news article
Auiucdcs.125
net.general
csvax.decvax!duke!uiucdcs!jerry at Berkeley
Mon Aug 10 22:11:08 1981
The etymology of dsw
The etymology of dsw has long been a cause of sleepless nights for
persons who read the Unix manual description of the command. A number
of years ago at a Usenix conference before Usenix was called that (the
good old days), I managed to hear a story describing the etymology of
dsw from one of the Unix inner circle.
Dsw is truly a carryover from the ancient past, according to this
story the command originated back in the time when a sequence of PDP 7's
and 9's were the implementation base. At the time dsw was written, no
terminal was available for use so Unix communicated with the developers
via the console switch register. Dsw was one of their tools for manag-
ing the file system since the basic inode structure had been laid out.
Its task, as in version 6, was to delete files. The method of refering
to files was slightly different in that inode numbers were directly used
as file names. To delete a file, dsw was loaded into memory and the
appropriate inode number entered into the switch register. Therefore
dsw stands for Delete via SWitch register.
On a more serious vein, the lack of diagnostics has long been a
problem with Unix systems. The reasons for this are largely historical.
First, Unix originated in the days of the Teletype, ASR 37's were the
original preferred terminal with ASR 33's going to the unfortunate
remainder of the Unix users. Most people who worked for an extended
period with such devices can probably recall the initial pleasure of
their first DECwriter terminal session. At 150 or 110 baud you simply
did not want the noise and time delays caused by lengthy diagnositics.
Secondly, while Ken Thompson and Dennis Ritchie designed Unix and
the system interface, a much larger group developed the user command
interface. Users of the initial Unix system would feel the need for a
particular facility and so they would try to provide it. There was no
project manager to encourage coherence of command structure and a good
novice interface. Accordingly, commands were named by their authors and
typically a command not only provided no diagnostics for the user, it
also contained little or no documentation internally for system program-
mers assigned to maintain the software. Given such a development
environment, it is quite a tribute to the work of Ritchie and Thompson
that it spread outside the initial research group.
A third reason for the poor diagnostics of most Unix commands was
the lack of an easy method to write error messages on the error file
descriptor. No programmer wanted to send extraneous information down
standard output since the command might be used as a filter, and printf
only worked with one file descriptor at a time. A programmer was left
to using the write system call directly and counting the number of char-
acters in the error message that he or she wished to print. The
development of the standard input output library by the people at
Research Unix changed this, and so, version 7 had quite a great deal
more diagnostic information.
We here at the University of Illinois, Department of Computer Sci-
ence have seen much of the problems which Unix provides. For example,
rm * has long been a concern but changing the command to ask for permis-
sion to delete a large quantity of files meet with large scale user
opposition. The system programmer finally answered some of the objec-
tions by allowing each individual user to set an environment string to
indicate whether or not he or she wished to be protected from them-
selves. While our secretaries occasionally have had problems using
Unix, they have tried several times (unsuccessully) to get the depart-
ment to obtain a Unix system for their exclusive use.
Jerry Wall
Unix system administrator
University of Illinois,
Department of Computer Science
-------
-------
More information about the Comp.unix.wizards
mailing list