http://invisible-island.net/
Copyright 1996-2022,2024 by Thomas E. Dickey
Flist (file-list) provides the user with a powerful and versatile interface to VAX/VMS. Flist is a full-screen editor which shows the effects of commands rapidly and naturally. It provides both interfaces to VAX/VMS file management commands (EDIT, COPY, RENAME) as well as extensions to the command interface to better integrate VMS commands, and to augment them
I wrote flist in 1984-1985 while at the ITT Advanced Technology Center. Seeing the original flist program on VM/SP CMS, then dired on BSD 4.1 gave me the inspiration to go and do likewise on VAX/VMS (which really does need a good user interface). At the same time, I wrote a browse program, having used that in conjunction with flist on the VM/SP CMS (aka "VM/CMS") system.
Originally, I was ambivalent about what to call the program,
referring to it as dired or flist (since it was
inspired by both, but a reimplementation on a different operating
system). However, there was a technical reason for deciding on
“flist” only: because I use the VMS foreign
command feature, it was not integrated with the system's
dictionary of commands (and their abbreviations). VMS only cared
about the first four characters of a command name, so that it
could handle abbreviations. Thus,
“dired” did not work well because VMS
had a command named "directory".
When I left ITT in 1985, I took it with me (as it was done on my own time, and I was not paid for it, the program fell outside my employee agreement). Starting with a VMS backup file which I transferred to cartridge tape using my Apollo DN300, I made a 9-track tape at DEC's customer support facility in Hamden. The tape was unused for about two years, before I revisited it at the Software Productivity Consortium (SPC) in 1988.
At the SPC, we had a VAX/VMS system named bebop which
I used for porting some of the prototypes which I developed. Some
of flist's source was useful for this activity,
as well as for other programs such as cproto. For the latter (programs
outside the scope of my work), I started developing a library
named portunix in 1988 (later absorbed into the
library which I use for ded and its
related utilities). As flist's changelog shows,
I made only minor changes to it in this period, aside from
putting all of the files (including the generated documentation)
into RCS (the conversion retained the original file
timestamps).
When I left the SPC in 1994, again there was no issue with
taking flist with me, but I had no VMS
system.
There were other ways to develop and test with VMS:
Early in 1995, Paul Fox told me about DEC's testdrive systems. I used DEC's test-drive system from the end of January 1995 until it went away at the beginning of November 1995.
On the testdrive system, I used the (now defunct) AXP demo
machine axpvms.pa.dec.com to test and upgrade
flist from the original K&R source
(which was what VAX C was in 1984) to ANSI.
I submitted the result for the second and third VMS freeware cdroms (1995 and 1996, respectively). My first submission was merged with Hunter Goatley's "flist" program, due to confusion about the name. My followup submissions appeared as "flist_frontend".
Late in 1998, Terry Kennedy (at St Petersburg College) provided me with a temporary account to build and test my maintenance changes to flist. That appeared in the fourth VMS freeware cdrom (1998).
Early in 2000, Jerry Leslie (and Charles Sandmann, at Rice University) set me up with accounts on VAX workstations, to help with reviving the port of tin to VMS. I used their machines until late in 2003.
Also in 2000, Urs Janßsen told me about Compaq's testdrive. By the time I decided to try that, in mid-2003, it had become HP's testdrive.
I made some fixes for compiling with IA64, but (since flist was very stable) had no need to continue developing it. Rather, I used the testdrive machines mostly for working on lynx and vile.
The HP testdrive was discontinued at the end of September 2008.
Flist is getting a little old, but still quite usable.
See the changelog for details:
In adapting the concept to VMS, I made several tradeoffs which make the program different from the IBM program. For example:
IBM flist is designed for the 3270 synchronous terminals. Users type commands on the screen beside the filename. Then they transmit the screen to the program, which collects the commands from the screen, adds parameters and executes the commands.
While it might be nice to run multiple commands (even without the synchronous terminals), I chose to limit the program to a single command at a time. Aside from this - typing commands and collecting parameters—the programs act much alike.
VM/CMS uses shorter filenames than VMS (two 8-character fields plus a 2-character minidisk location versus two 39-characters and a version number).
I added a command to set the displayed width of the filename- and filetype-fields.
VM/CMS provides only a handful of file attributes, which fit nicely on an 80-column display.
VMS has many interesting file attributes to display (4 types of date, record attributes, etc). The default view of the VMS program looks much like the IBM program. I added a command which is used for select the attributes to display.
The VMS program is strictly hierarchical, with only one list shown at a time.
The IBM program processes an optional user configuration file, e.g., to set a header line and make function-key assignments.
The VMS program does not read a configuration file.
The IBM program allows the user to supply a script which tells it how to sort the items on the screen.
Actually, I do not recall (and do not have contemporary documentation available to verify if this was a difference). The VMS program allows the user to sort by any visible field—in some cases in more than one way.
The IBM program uses in-memory file information which is available to any application in VM/CMS,
The VMS program must read/reread info after invoking editor, etc., which is a significant performance problem. To work around the limitations of VMS, it includes its own command interpreter to infer when a file has been edited (and detect new versions), handle copying of files (again, to handle versions),
To simplify screen updates, I implemented browse both as a standalone program, as well as a built-in command of flist.
VMS's runtime library did not include a command interpreter. I wrote my own, designing, taking care to handle the low-level function status to show error messages in the status line at the bottom of the screen. If I had not done this, the runtime library would write messages where the cursor happened to be.
Later, I developed ded, which is nicer in many ways for UNIX.
There is another flist written by Hunter Goatley with TPU a few years later. The two programs are unrelated (and Hunter Goatley stated that he was unaware of the other programs using the same name).