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, written in 1987, from an earlier program).

Although dired used BSD curses, my intervening programs did not. flist uses VMS's SMG$ calls. The program for which I originally wrote the directory-tree module used a wrapper for termcap which I wrote when I found that the curses library on the Sperry PC (late 1985) did not work. The wrapper (like the one which I wrote for tin in the mid-1990s) provides an interface use curses's function names, but like other low-level interfaces (such as conio and s-lang) did not provide optimization.

Most of this design dates from 1988, with more recent work being directed to

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:

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:

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:

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