SYNOPSIS
ded allows you to navigate through multiple file lists or a
directory tree, viewing or changing file attributes rapidly.
In addition to conventional file information, it
operates on the file's RCS or SCCS archives (or CVS or SVN, etc),
making it useful for source-control as well as system administration.
Curses-based, it runs on UNIX systems.
HISTORY
This is a long-term project.
I originally began in 1984, enhancing a version of dired
(written by Jay Lepreau <lepreau@cs.utah.edu>)
while at the ITT Advanced Technology Center.
There is some dispute over whether that dired is based on the emacs mode
introduced around the same time (1980) or the reverse (since neither
program's documentation at the time credited the other),
but it is indisputable that both
were inspired by an earlier stand-alone program running on Tenex available
in the Stanford AI Lab (SAIL) in 1978.
That early dired had crude display management,
which allowed a user to enter shell commands and see them at the bottom
of the screen - not something that curses was designed to do.
Among other changes, I modified the program to allow the
user to change the fraction of the screen which was devoted to the
command output.
There are later versions of dired.
however I found nothing useful in the later changes since the
most apparent changes were more complicated (and cumbersome) key-binding
for the functions.
Subsequently, I designed and implemented
a series of directory editors including
flist,
and this program (which uses a directory-tree module from an earlier program
written in 1987).
Most of this design dates from 1988, with more recent work being
directed to
- auto-configuring
- handle window-resizing events
- use line-drawing characters in the directory-tree
- use color (influenced by the scheme used on Linux,
but without the limitations imposed by its hard-coded behavior)
- interfaces for other source-control systems including CVS.
The line-drawing, color and other curses features (such as the
management of the non-curses area of the screen)
were why I became involved in
ncurses,
and provided the motivation to make ncurses more than the decaying hack
which it was in early 1995.
Features
I developed ded (and associated programs in
cm_tools)
to manage files stored in RCS/SCCS archives.
Neither tool provided a way to tell which files were modified.
It was a rare feature until the
more elaborate IDEs were produced sometime after 2000.
I built that into these tools, starting in 1986 with SCCS and in 1988 for RCS.
Later, I added support for CVS and SVN (mainly to inspect files maintained
by other developers — I had also written wrappers for the RCS/SCCS
tools which suit my needs better than those other tools).
I use ded for both development and system maintenance.
It, or vile, are the first programs that
I install on a UNIX-style development machine.
This is why:
- ded provides a listing of all of each file's attributes.
- the listing can be sorted by any of the attributes, as well as by
useful relationships between the attributes (25 choices).
- ded commands use (like vi) few keystrokes;
using it is fast.
- file (and directory) attributes can be edited:
- file-permissions can be edited
- filenames can be edited
- file timestamps can be edited
- symbolic link targets can be edited
- multiple files can be selected,
and the results of editing file attributes
will be applied to every selected file.
- ded provides a fast selection of all files which
sort with the same attribute value, e.g., suffix, permissions, size.
- ded provides a directory-tree navigation screen,
but also maintains a ring of active file-listings which the user can
page through.
- piping a list of filenames to ded makes a custom
file-listing which does not have to correspond to a given directory.
- for operations (such as deletion, copying, etc), which are not built
into ded, it provides a shell prompt,
with substitutions from the current and selected file's attributes
such as parts of the filename.
- shell commands are automatically escaped to handle embedded blanks, etc.
- adjacent directory-paths can be referenced in shell commands,
providing a simple way to move or copy files between directories.
Influence
SIGWINCH — Resizing Windows
As noted, working on ded was the reason why I became
involved with ncurses.
I was told about SIGWINCH in 1988, which was a feature of SunOS.
That was a good idea, but curses implementations did not support it.
I found that I could reallocate the memory used in BSD curses,
and make ded respond to it, since that implementation
used a simple scheme for allocating window data.
But BSD curses did not use the line-drawing characters.
SystemV curses did.
But making SystemV curses work with SIGWINCH was a different matter.
I found that reallocating a window was not straightforward due to the
convoluted approach which it used, grouping similar-sized things into
single chunks.
If there had been a way to communicate with the developers of SystemV curses
and make them interested in the problem, that would have solved my problem.
There was no apparent way to do that, so I put the idea aside for a few
years until I noticed an early release of ncurses (which claimed that it
was 100% compatible with SYSV curses, etc. — it was not).
Shortly after, I found the opportunity to send changes to its developers,
starting with fixing the most apparent bugs.
My goal was to get their implementation to be good enough that it
could be used to interest the more established AT&T developers to
use the idea.
As it happens, both groups of developers fell by the wayside.
I've been developing and maintaining ncurses since April 1996.
ncurses does work with SIGWINCH.
Default Colors
Another aspect of ded influenced ncurses.
That is the use of default colors.
Most curses applications fill the background with some color.
Midnight Commander is a well-known example of this.
I had used the Elvis text editor in MS-DOS;
it used (like vile) a blue background.
I used the same scheme for my adding machine.
However, ded divides the display into two parts:
- a list of files and their attributes (size, data, etc),
which is managed by curses.
- a working area, where the results from shell commands can be displayed.
The working area was originally inspired by dired.
I extended that, making the working area resizable.
With some care, it is possible to mix curses updates to the screen
with shell commands that modify the working area.
Some commands require ded to repaint the screen.
There are corresponding commands for doing that.
One big problem was the use of color.
Making the file-listing have a filled background would look ugly when
combined with the plain working area.
The color model used for the Linux console gave a solution to that:
ded would set the terminal's background color to its
default value; curses would be told how to manage text coloring on top
of this.
SYSV curses did not do anything like this.
But I had already (in 1995) become involved with ncurses,
working to prop it up, to prepare it for SIGWINCH support.
ncurses colors did not at that time work properly on Linux console
and similar terminals which used the SGR 39/49 codes for default coloring.
I pointed this out to ESR.
After some resistance (which I overcame through constructing test programs
to prove what SYSV curses did), he implemented a first version of
background color support.
That evolved (mostly by other developers) over the next 2-3 years.
Late in 1995, I noticed the announcement that XFree86 had implemented
color in xterm.
(That was based on an older patch for color_xterm, which had been
improved by two of the XFree86 developers).
I took a look at that, and found that it did not implement the
Linux-style default colors.
So I proposed changes to improve xterm,
mainly aimed at making its colors work as I wanted for ded.
I did that, and have been continuing to develop and maintain xterm
since January 1996.
As with ncurses, it took several months before I was "done" making the
colors work properly.
That fall, I happened to be exchanging email with John Davis
(developer of s-lang),
and mentioned my plans for using the default colors in ncurses.
He stated that he would implement support in s-lang,
based on environment variables.
My response was that I thought the design would be better if it were
explicitly controlled by the application,
rather than allowing environment variables to modify it in unforeseen ways.
While s-lang implemented something first (about a month later),
the changes that I put into ncurses early in 1997 were in my plan for
it since I had started work on xterm.
There are two functions in ncurses which implement this design:
- use_default_colors — tell ncurses to use the terminal's default colors
- assume_default_colors — give ncurses a hint what the default colors are
I persuaded the mutt (mail client) developers to use default colors,
and implemented it in lynx.
But using it in ded is the reason why it exists in ncurses.
Documentation
Download
Download via ftp (you'll need the library):
Related utilities (RCS and SCCS):
Unrelated utilities (using td_lib):
Download via http (you'll need the library):
Related utilities (RCS and SCCS):
Unrelated utilities (using td_lib):
Copyright © 1996-2009-2010 Thomas E. Dickey