Softpanorama (slightly skeptical) Open Source Software Educational Society

May the source be with you, but remember the KISS principle ;-) Softpanorama Search

Softpanorama University Library

The Orthodox File Manager (OFM) Paradigm

by Dr Nikolai Bezroukov

Ch. 2: The Current Status and the Directions of the Development of the OFM Paradigm

• Introduction

• The essence of OFM paradigm: OFMs as a new command line interface for the Unix shells

• What enhancement we can expect  in the next generation of OFMs?

• Importance of history: those who cannot remember the past are condemned to repeat it

• The importance of Virtual File Systems (VFS)

• Selections, filters and FindFile integration

• Future Directions: Content Based Access in Hierarchical File Systems

• Epilog: complexity versus features. The importance of statistics

Introduction

This chapter is largely based on all the content of the book, therefore, although it is important to read it in order to be able better compare different OFM implementations, some features might not be clear from the first reading and I recommend to reread it after reading the other chapters of the book. 

In order to evaluate the current generation of OFMs and see the future trends one needs to understand the driving force behind OFM development and its potential.  There are two questions here:

• Does OFMs still have a driving force behind them ? 
• What we can expect from the next generation of OFMs

In the past the driving force behind OFM development were needs of system administrators, especially BBS sysops, Unix, Linux and FreeBSD administrators as well as all categories of programmers. Their job contains a large doze of file manipulations and they are often qualified enough to implement software themselves.

Currently BBS are almost extinct and are replaced by much bigger number of WEB administrators. That means that social base of OFM recently increased.

That probably explain why there are so many implementations of OFMs.  My feeling is that that fact also explains why OFM proved to be so important tool for sysops and sysadmins as well as advanced users: they substantially increase the productivity of complex file  manipulations. I also believe that there are some important limitations of  GUI tools in the environment were one need to manipulate filesystems with a large number of files dispersed in many directories like is that case in large WEB-sites or BBS. Some of the servers that sysadmin need to support are remote and it is not accidental that most OFMs now support FTP virtual file system (VFS). Now it's a standard feature of any decent OFM.

I am less convinced for the users who do not perform a lot of file operations on daily basis. For them a standard file manager maybe quite adequate. But if they do, OFM might be a big improvement. 

There is a significant mortality among OFMs and leaders periodically change. The table below tries to catch more or less current snapshot of the field.

The essence of OFM paradigm: OFMs as a new command line interface for the Unix shells

Although originated in DOS, in my view OFMs can and should be considered as a new generation of Unix shells command line interface, the interface that simplifies working with the command line shell environment. I would say that this is essentially a breakthrough in the creation of the shell command line interface. The only thing that is lacking is a component model and the integration with a suitable scripting language as a macro languages (for example, scripting host in Windows, TCL in Unix). That means that the importance of OFMs is closely related to the importance of shell environment. As David Korn aptly said (bold italic is mine  - BNN):

There are many people who use UNIX or Linux who IMHO do not understand UNIX. UNIX is not just an operating system, it is a way of doing things, and the shell plays a key role by providing the glue that makes it work. The UNIX methodology relies heavily on reuse of a set of tools rather than on building monolithic applications. Even Perl programmers often miss the point, writing the heart and soul of the application as Perl script without making use of the UNIX toolkit.

Paradoxically that means that Unix is a better environment for OFMs then Windows.

I  think that OFMs is still have a long way to maturity and that OFM paradigm is currently in a rather early stage of development. There is still a lot of space for improvement of OFM-style manipulation of files and directories that users should request from the developers. Among them:

• Better remote administration via TCP/IP. The original Norton Commander provided the capability of remote connection via serial cable. This feature is now almost forgotten but still it's immensely important to reimplement it in full scale via TCP/IP.  Architecturally any OFM can be structures as a server/client with the server performing actual tasks and client handling display and keyboard functions. That means that Client can be installed on a different computer and connected with the server part via TCP/IP. In such incarnation OFM represent a unique blend of telnet and ftp capabilities unmatched by any current product. 
• The panel view enhancements and new VFS. The most  and rater simple to implement panel enhancement is to introduce "extended attributes" in the panel view. For example UNIX file attributes, or the  <title>  tag as a description for all HTML documents (can be done by generating Descript.ion file on the fly even with the current version of OFMs). One can view a panel view as an HTML Table. that mean that user can specify name of the columns, column order and percentage they occupy on the screen to get a view that he/she needs. Each view should have a name and selection of view can be based on the name. This is more flexible and at the same time simpler implementation that currently exist in FAR, DN, or any other OFM. In consol mode it might make sense to distinguish single width (half-screen) and full width columns (that were fist introduced, I believe, by NCW). Full width columns are just a special panel type that is useful for certain operations like search or for long file name plus all attributes visibility. On the console implementations the most flexible solution is currently implemented in DN and FAR where you can change width of the panel as you wish having for example asymmetrical panels (Ctrl-Left, Ctrl-Right in FAR).
   
• The navigational enhancements. Ctrl-Enter in Dos/Windows implementations can be used as a universal key for transmitting information from the built-in editor, viewer, or dialog box to a command line. Reverse mechanism for entering information from a command line to the editor would be beneficial too (for example via  a clipboard). Actually elements of it were implemented in FAR, but still Far cannot import the current command line to editor. With Web browser as an important tool for any programmer there is a possibility to implement some of the Netscape Navigator-style navigation capabilities. For example getting to the previous directory from the history list using backspace key.  Netscape style implementation of directory favorite list and file favorite lists also might further improve the productivity.  Generally I think the ideas, connected with a unified paradigm for browsing files and Web will be the driving force behind future developments of OFMs.

  Another possible navigational enhancement is the ability to use a selected document (index) as a filter to display all referenced documents in the panel. Even now this can be achieved in MC and DN by writing simple preprocessor that converts HTML document into the file list and then viewing this list. In essence it is similar to viewing an archive and can be called a virtual HTML file system. The second useful enhancement would be to display a tree view of references from the HTML document as a specialized tree-view and navigating this tree in a usual OFM style.
   

• User menu enhancements. The capabilities of the user menu in all compiled OFMs remains rather primitive. Access to the objects in the panels is limited to a few exposed via macros (the current file name, the current directory, list of highlighted files, etc) s. Macros names are often too obscure to use (like in FAR. Can you, for example guess what does !#!\ means ? ).
   
• The viewer enhancements. Integration of  grep style filters into viewer would be really beneficial and is very simple to implement. Also badly needed is the ability to jump from the text view to the panel view for a particular directory (jump to the directory selected in viewer or editor will probably be enough and is not that difficult to implement).
   
• The editor integration. More close integration of built-in editor and OFM can provide a lot of interesting capabilities. For example "quickedit mode" might be useful. Currently we cannot preserve one panel while editing files in another like in "Quick view" mode (although many OFMS provide the possibility of switching form the viewer to the editor in the view mode). The editor itself can be more complex and powerful. All dialog boxes are essentially an editor windows with the input line as the first line and history list as (hidden) body of the document. So reasonable set of edit operations should be available uniformly across the board. Among them quick search in history, select and cut and paste operations. I strongly believe that the editor can be structured in such a way that its routines can be used for support of the dialog boxes so that total complexity of implementation can be substantially reduced.

  Panel are also very similar to the editor windows. Most  problems of implementing a decent panel could be reduced to an editor window implementation problems.

  Note: In case of using a uniform editor command history and user menu will able to interact so that commands from command history can be moved to the user menu -- semantically the user menu can be considered as a favorite list for the command history. 
   

• Scripting language. Introduction of a scripting language is probably the most important avenue of OFM development. I believe that TCL is probably the primary candidate for the incorporation into Unix OFMs. This can be a side effect of writing OFM in TCL, that's why I feel that GUI-based OFMs have an edge if they are written in scripting languages. VBscript or JavaScript might be a viable option for Windows OFMs.

  Scripting permit easy generalization of functions recorded via macrorecoder and break the vicious cycle when the user is reinventing the bicycle again and again for common operations. For example if you have TCL or PERL or REXX as your scripting language, then the command line became essentially the OFM command line that interpret internal command language and passes to the shell only things that cannot be recognized or are marked explicitly as shell commands. Also it is possible to create new hotkeys like:

  Ctrl-F:
     pleft ftp "my_page";
     pright "d:\my_page";
     paneldiff "*.html";
     shell "pkzip" updated||date()||".txt" selected_list
     copy tagged;
     copy "*.zip g:\my_page\archive"

  Quite decent scripting language implementation is possible in less that 100K (early AWK interpreters and some Rexx implementations were even less than 64K). Moreover introduction of scripting probably can reduce complexity of other parts of the implementation due to common routines required. So it is not the question of overloading the boat.

  Scripting is an essential feature without which further development of OFM will probably stagnate. Important question here is portability, so TCL or Perl are probably much better solution than Microsoft VBScript. At the same time I understand that VBScript is probably the easiest to integrate in Win95/NT implementations and freely available for NT (I am not sure about Windows 95).

  Without scripting introduction of new features into OFM can lead to a complex environment with too many bell whistles. IMHO top OFMs already achieved a maximum number of features that application can have without scripting. See also my Perl and TCL/Tk links.
   

• The flexibility of key assignments. The last, but not least of the problems facing OFMs is the problem of hot-key assignment. Currently OFMs have more or less consistent framework for hotkeys for the major operations. Assignment of keys for minor operations is different for almost all OFM implementations. Sometimes (in best OFM tradition ;-) key assignment are so arbitrary, that they defy any reasonable explanation.  That creates kind of mess that is well known to power editor users. Switching from one OFM to another now is so difficult, that it slow down the pace of innovations.

  Question of key assignment is a lot more complex issue for  UNIX-based OFMs. OS induced limitations on key usage on the regular PC keyboard make UNIX-based implementation not very compatible with DOS/Windows/OS2 implementations.

  Importance of preserving the same key assignment also depends on the frequency of key usage.  The frequency of usage of each key is different. For example usage of different binding for F3..F8, Gray+ and Gray- will instantly create problems for long-time OFM users. But changing of semantics of F1, F9 and F10 probably will not harm much as they are used less frequently.

  As unification by the "Supreme Committee of OFMs Designers" resolutions is not feasible ;-), implementers should make at least some (even primitive) key reassignment mechanism available ASAP. Minimum solution would be to have for each operation main hot-key and alternative hot-key like in MultiEdit. It should be flexible enough to permit, for example,  some novice users to use Ctrl-C/Ctrl-X/Ctrl-V mechanism for coping group of files as an alternative to the orthodox hotkeys F5,F6, F8. Users should demand this in order to get all benefits of using the best OFM for a particular environment.
   

• Bottom Toolbar Generalization Bottom toolbar should change in any panel to show set of available operations. That provides for additional flexibility, so that F1-F10 keys can be used for options in each dialog box.
   

• Plug-ins and  API The concept of plug-ins first implemented in Netscape and then in FAR is also very useful cross-pollination feature that give OFM a completely new ways to extend basic functionality. One of the problems that current generation of OFMs face is that they are not extendable and not customizable enough. This is connected first of all with the fact that most OFMs (here only FAR is a class of its own) completely lack API and scripting. Presence of API permit creation of plug-ins successfully implemented in FAR. If we assume that there is an API we can move to the important next step in OFM development --  introduction of a scripting language. Mozilla source code is now available and although pretty complex, can still can serve as at least as a conceptual prototype for new features in OFMs.

The importance of history:
those who cannot remember the past
are condemned to repeat it

The famous quotation by  George Santayana "Those who cannot remember the past are condemned to repeat it" has a very literate meaning in file managers. You really need to retype things that OFM does not remember for you. In this sense the amount of history that a particular OFM can remember can be a crude, but important measure of a particular OFM quality. A bare (and unsatisfactory) minimum is the history of command line. More optimal is the addition of at least:

• History of directories visited.

• History files viewed and edited.

• History of masks (regex) used in selection of files or in panels. 

But generally for each operation history is an extremely useful add on that greatly enhance the usability.  Best OFMs like FAR remember even history of F5 and F6 operations.

Another important idea that OFM introduced is that history of viewed and edited files can be considered a special kind of a panel and most file operation are applicable to it.  In a sense it's additional temporary panel like DN or FAR temporary panels.

Other not so obvious interaction is that command history and user menu are interconnected in a sense that semantically user menu can be considered as a favorite list for the command history. That mean that one should have the ability to directly move entries form command history to the user menu and that command history probably should have a hidden field -- frequency count and be able to sort entries by this field.

The importance of  Virtual File Systems (VFS)

One of the main challenges in creating a good file manager is to provide access to vast amount of information about files in a particular file system. Filesystem today use the same paradigm as Unix in early 70th: hierarchical naming system in which files are contained within directories. This paradigm does not scale well for multi-gigabyte filesystem with hundreds of directories and thousands of files. For example a typical Windows installation contains almost 50K files on the drive C:  The main OFM innovation in this area is addition of semantic directories that in rudimentary form were results of some search. Ctrl-R proved to be a very natural key for reevaluating a query.

Virtual file systems are filesystems than provide regular local drive/file/directory style access to things that are not located locally or not in one directory or not a files at all.  The best OFMS have several of them implemented. Almost all are implementing at least one (usually archive VFS). A rich variety of VFS in OFM were introduced by DN and further (independently) developed by MC, FAR and Total Commander.

There are several such VFS

• Archive VFS were first implemented as add-ons to Norton Commander 3. That were the first VFS were designed for access various archives and they usually have a possibility to view documents and extract files using a familiar OFM interface(F3 to view, F5 to extract, etc). The first OFM that integrate is into the core functionality was probably DN. Now archive VFS is an established feature and most OFM support it. Xtree flat VFS was not so lucky :-(.
   

• Search VFS was first introduced as a panelize option in File Find screen of NC5. Regrettably it provided much less following although its generalization and extension by MC now became an essential requirement for any advanced OFM.
   

• FTP VFS. Provides a panel view of the directory on the remote computer. Now can be pretty sophisticated and support wide range of operations (like in FAR and Total Commander).  The first FTP VFS was probably Alex FTP filesystem that lets users access files in FTP sites around the world just like they access local files. Alex pathnames are composed of 3 parts. First is /alex. Second is a reversed hostname. Last is the path on that host. For example, /alex/edu/berkeley/pub/virus.patch is a file at berkeley.edu. For most OFM VFS implementations the refresh command (Ctrl-R) provides the update of the panel view. Automatic synchronization of panel view and directory content as in regular panels in implemented by some OFMs (Far, AMC -- Advanced Midnight Commander -- a fork of Midnight Commander 4.1 codebase).
   

• Briefcase VFS. Briefcase VFS is a virtual flat filesystem somewhat similar to Xtree VFS, but that contains only the most  recently used files. In can be implemented as a real directory with links to those files (Documents in Windows) or completely virtually. they are different from plain vanilla file access history in that each files is entered in it only once, but other then that they are pretty similar. The criteria for adding files into this folder can be specified in a special option file (for example extensions of the files that should be added.

  One can implement a limited version of this folder by using F2 menu for launching the most important  programs and redefining the starting script so that it adds a file to the folder.  Entries should be deleted after certain amount of days of inactivity.

  Xtree VFS

Xtree VFS is just a special (but very important) case of search VFS and it gives to the user the ability to view a directory with all subdirectories as a single virtual directory. Any subtree can then be viewed as a flat list of  files as if no directories exist. This way for example duplicates are instantly visible. This idea was pioneered in Xtree file manager around 1987 and is a natural and very important special case of the OFM search VFS paradigm.

As I mentioned before, filters on subtree are essentially a search function for subtree and in future implementations this two functions should be merged.

This flat directory tree VFS was first introduced in Xtree (as early as in 1987) and this capability probably was the single most important reason of  XTree popularity. As a limited imitation of the Xtree VFS exists in all DOS OFMs as result of the search for the file mask *.* (which actually can be panelized in NC5) but I am convinced than because of importance this VFS should be a standard in all modern OFMs.

Such a VFS provides really important functionality not fount in any known to me Windows-style file manager. With Xtree-line of file managers discontinued (by the way by Symantec ;-), it can became a distinctive mark of OFMs. Separate implementation is warranted based just on importance of this feature for understanding and manipulating subtree content.

Search VFS

The idea of search VFS was discovered by many authors, but were fist introduced on mass scale in NC5 via panelize command.  It provides possibility to view results of search in a special panel -- essentially virtual directory. Using DOS tradition this directories were not mounted at all and they existed as a new type of virtual disk with links instead of files (please remember that DOS file system does not support links).  

Search capabilities are usually quite powerful and include at least grep-like capabilities including search for regular expressions. Some advanced OFMs (DN, FAR) are capable to search in archives too.

At the same time FindFile panel in OFMs can in reality be considered just a double width regular panel. The main problem here is that on a regular panel path is not necessary, while on a search panel it's often really helpful. That means that there should be two modes of displaying files in search VFS panel (with and without full path) and those modes can probably be useful for regular panels too. The possibility of  the transformation of this panel to a half screen panel as in NC5 in an interesting possibility, but it should not be required in order to be able to perform all (other than View and Edit) operations of files on the Search VFS panel.

On Unix a search panel can be implemented by linking all found file to some temp directory, so its easier than in Windows environment.

One additional operation that was introduced in Search VFS is go (or zoom) operation when one can open a new panel using the full path of particular file.

It's important to understand that file filters are a special and very limited case of search VFS applied to the current directory.

Briefcase VFS

Briefcase VFS provide a possibility that was present in Unix from day one -- links to files and directories on existing drives can point into single (virtual or real) directory (or drive in DOS world).

Although semantically it is very close to UNIX link,  briefcase was first introduced in windows 95 as a Document folder.

Now it probably should be a standard feature in all UNIX implementations of OFMs. But the idea of briefcase has an additional important feature -- file could get into briefcase not only manually but automatically, based on some criteria -- usually recent usage. For example each recently opened file that is not an executable. The second feature of briefcase that files should disappear from briefcase if they were not used for a certain about of time (for example one month).

Now let's discuss operations. It is possible to copy files from different directories to the briefcase drive (directory) and then work with this links as if they are were stored on this drive. All file operations should be supported.  .

Script-based VFS -- generalization of NC5 panelize option introduced in MC

The idea of ScriptVFS is to provide a user with the possibility to view in the panel the result of execution of any script that produce a list of fully qualified file names. The only restriction is that each line of script output should be a fully qualified file name. Other than that script can of arbitrary complexity. Currently it is supported in two major OFM implementations -- DN (DN idea was based on files.bbs concept) and MC -- the first OFM that implement this VFS correctly. BTW MC preserved the name of NC5 option (panelize) and we can call this type of VFS  a "PanelizeVFS".

ScriptVFS is the most general case and several other OFM features can be considered as a special cases of this VFS:

• If we limit ScriptVFS to just current directory then we will get a well known panel filters. Panel filters as currently implemented are not very useful and few users use them on daily basis.
• If we will use script "dir *.* /s /b /l" in DOS and "ls -l -r" in Unix we will get XtreeVFS
• If we will use find or other search program that we will have a Search VFS.

Again I would like to stress that OFM implementers probably just need to generalize filters to have Script-based VFS -- an old and not widely used concept can be extended into new and much more useful domain.

FTP VFS

The first FTP VFS was probably Alex FTP filesystem that lets users access files in FTP sites around the world just like they access local files. Alex pathnames are composed of 3 parts. First is /alex. Second is a reversed hostname. Last is the path on that host. For example, /alex/edu/berkeley/pub/virus.patch is a file at berkeley.edu. See also

It was implemented as a part of OS in Plan 9. See Plan 9 -sys-man--4-ftpfs. Gnu Hurd also included it as a part of design (see Towards a New Strategy of OS Design). Unfortunately Linux does not implement it at all :-(.

In Windows  environment the best implementation is probably WebDrive FTP Client Software by RiverFront Software -- a  autonomous FTP VFS subsystem that essentially makes a separate FTP VFS implementation in OFMs redundant. This was probably the most important breakthrough in OFM for the 1999 and paradoxically it was produced by the company that has nothing to do with OFM development. Currently limited to Windows 9x and NT  environments.

WebDrive is a Windows 95/98 FTP software client  that allows you to map an Internet FTP site to a local drive utilizing the standard FTP protocol. This enables you to connect to an FTP site and perform familiar file operations like copy, xcopy, and directory functions with the Windows explorer,  a DOS box, or any other application like Microsoft Word, Excel, etc. WebDrive instantly FTP enables any application that reads or writes files by allowing the application to read files from or write files to the FTP site.

Until now, in order to upload or download files from an FTP site, you needed to run a client FTP utility that presented a user interface to manually select the files to transfer. The WebDrive FTP client makes the FTP site an extension of the file system which enables you to use any application to upload or download files to the FTP site transparently.  For more details, click here

The same idea can be extended to HTTP. HTTP VFS client was implemented by Oleg Kiselyov for MC  on several OSes (Linux 2.0.27, HP-UX 9000/7xx, Sun Ultra-2/Solaris 2.6) and  WinNT/Win95. This is an open source implementation http://pobox.com/~oleg/ftp/packages/http-vfs.tar.gz [86,492 bytes]

• Note the package includes an implementation of TCP streams, and C++ code to parse (multi-part) MIME entities, HTTP headers and configuration files of several flavors. The latter are built on an efficient implementation of dictionaries and collections of strings (also included, along with the validation code).

The main drawback is that the client requires a separate VFS server.
 http://pobox.com/~oleg/ftp/packages/VFS-server-pl.tar.gz [8532 bytes]

• http://pobox.com/~oleg/ftp/packages/http-vfs.tar.gz

Selections, Filters, FindFile and Panelize Operations

As we already seen the development of OFMs reveals that some of features that are present in OFM from NC2 days after generalizations in subsequent generations of OFMs tend to overlap. I would like to suggest a new paradigm of understanding of the selections, filters and Find File operation.   That does not mean that this is an optimal way to implement this features, but it does provide an additional light on their interaction.

I would like to suggest generalizing selections, filters and Find File operation via concepts of selection level (slevel) and visibility.

Historically sets of operations for filters, selections and Find File operations in OFMs were quite distinct. For example one can select a single file, but cannot hide a single file (you can hide a group of file with same extension, though). There is a possibility to perform an operation on all selected files, but not on all visible (non-filtered) files after applying some filter.

Logically there is no difference between selections and filters. Selections are just a specialized filter that does not hide filtered files and changes the color of selected files.

I would like to decouple the question of what is visible on the screen from the question of what file meets a specified criteria.

The idea is to introduce a slevel for each file/directory. Slevel is a small integer (byte) and thus slevel can vary from 0 (everything is hidden) to 255 (all files selected). Bit operations should also be possible for additional flexibility, e.g. slevel & '00001011'

To implement filters, selections and FileFind VFS we should have just two operations:

• to assign the slevel to the file(s) and/or directory in FileFind
• to specify slevels range that should be visible on the screen.

That mean that the usual filter in OFMs can be understood as some kind of macro operation. In pseudocode it can be something like:

set slevel N for "*.exe

view N as "normal"

or

set slevel N for subtree "*.exe"

view N as "normal"

Selection can have the highest slevel (255). Selecting the group of files via mask now can be viewed as a macro operation as well:

set slevel 0 for "*.*"

set slevel 255 for "*.exe view 0 as normal, 255 as "highlighted"

In other words filter operation is essentially the operation of hiding all files that have slevel different from the slevel of other files and selection operation is viewing the files with slevel 255 without hiding all other files.

That approach provides additional flexibility -- dynamical switching of views by changing the list of displayed slevels is possible. For example from *.exe to "*.html" if they have different slevels, etc.

Other interesting possibilities: it's now possible to assign backup and temporary files the lowest slevel, then files older that month higher slevel and files modified today the highest slevel and change this views.

Slevel essentially introduce some virtual tree on top of existing directory tree, so operations of expand and collapse are also possible.

Similarly FindFile operation should be considered as a filter as it displays only files meeting some criteria. It's like assigning a special slevel to these files. For example

set slevel N for subtree "*.html" && age() <  7

view N as "normal"

From this point of view the view of results of FileFind operation should be displayed as a regular double sized panel (full screen panel) but traditionally it should have a different color that regular panels in order to stress it different nature -- a set of links in a temporary directory

If you consider FindFile operation as an interface to grep then next generalization is easy -- we just permit underling command to be different. This way we get panelize operation that is present in MC.

Future Directions:
Content Based Access in Hierarchical File Systems

The need of built in into OFM some kind of  search engine is now quite apparent. Several implementations exist, with  Glimpse is probably one of the well known examples in this area. It is a powerful indexing and query system that allows you to search through all your files quickly. It can be used by individuals for their personal file systems as well as by organizations for large data collections. Glimpse is the default search engine in Harvest. The Glimpse package contains several programs, the most important of which are glimpse, glimpseindex, agrep (that was ported to DOS and Windows), and glimpseserver. To index all files in the a directory tree rooted at DIR, you simply say

	glimpseindex DIR 

(E.g., glimpseindex ~ indexes all your files.) Afterwards, glimpse can search through all these files much the same way as agrep (or any other grep), except that you don't have to specify file names and the search is faster.  For example,

	 glimpse -1 unbelievable 

will find all occurrences (in all your files!) of "unbelievable" allowing one spelling error;

	 glimpse -F mail arizona 

will find all occurrences of "arizona" in all files with "mail" somewhere in their name;

	 glimpse  'Arizona desert;windsurfing' 

will find all lines that contain both "Arizona desert" and "windsurfing".

	 glimpse  -W 'Arizona;~football' 

will find all lines containing "Arizona" in files that do not contain the word "football".

Glimpse supports three types of indexes: a tiny one (2-3% of the size of all files), a small one (7-9%), and a medium one (20-30%). The larger the index the faster the search. For most applications, the small index (glimpseindex -o) is the best choice. Glimpse supports most of agrep's options (agrep is our powerful version of grep, and it is part of glimpse) including approximate matching (e.g., finding misspelled words), Boolean queries, and regular expressions. In some form those ideas might be beneficial for future OFMs.

Epilog: complexity versus features;
The importance of statistics.

Quick growth of functionality of OFM managers lead to an additional complexity that became the major problem.  For example Total Commander implementation consists of approximatly 100K  lines of code. That is a medium size application at least. A typical OFM now support hundreds of commands with the functionality that sometimes overlap. That means that without the statistics of usage it's almost impossible to understand if a given feature worth the implementation effort, should it be incorporated to the core or left as a plug-in. 

But there is something more is any good program than just a rich feature set. This is a level of integration of features and it is usually called architectural integrity. For any given the total lines of code and number of modules or classes some OFM architectures provide better architectural integrity that the others.

Famous "the effect of second system" law in software engineering described by Frederick Brooks Jr. stated that the second system of the same developer is usually a failure, because the developer fail to recognize the difference between essential features and cosmetic enhancements and assigning priorities properly.

I would like to stress again that the key to further OFM development is not so much an addition of features for the sake of features. It is about integration of existing features on a new level and an introduction of abilities to adapt to changes in environment, in particular to the arrival of those 100G harddrives, the wide use of  WEB-servers, etc.

Integration-related enhancements are probably more essential than adding new functionality. That means that the introduction of macrorecoding, scripting language and key mapping should have a higher priority than anything else.

There is also the question of size. What is the optimal size for OFM, if such thing exist? Small is beautiful and smaller OFM are preferable in certain environment, for example for troubleshooting. Part of the appeal of Volkov Commander(VC) was and still is the fact that no other OFM can beat VC as a troubleshooting tool.

As for a regular usage the question of size became more convoluted. As features add complexity and size, should we distinguish the categories of OFMs like in wresting for the comparison to be fair ?  For example is VC better than DN as the number of advanced features it implements divided by size is probably much higher that in DN ?

Should we like in wrestling consider size as a limit for fair competition, so that only programs of approximately the same size should be considered as belonging to the same category (say, under 0.1M, under 0.5M, under 1M and over 1M)?

The similar question is "To what extent additional features are beneficial to the user?".  This is the most difficult question. I use OFMs since approximately 1988 and still I cannot master all the features in a classic feature set and periodically discover (or rediscover ;-) something new and interesting while I was writing this book. As Windows software development has shown adding more and more features is not always  better.  At the same time for professional it is nice to have all features the money can buy (as MS Office popularity demonstrates quite clearly :-) even if some will never be used.

The usage of scripting language (for example Python) and the concept of plugins as used in Netscape and in FAR seems to be one possible solution to the complexity and size issue. FAR was the first to implements Netscape-style plugins in OFMs. It was following by Total Commander. I think that his is a healthy trend: if user do not need feature or group of features, he can uninstall or never install a particular plug-in.

Without plugins it is very difficult to remove a feature once it was implemented even if it is somewhat redundant. So I would like to stress that like in Web servers there should be a log subsystem that can be used by both implementer and user for tuning application.

This question of complexity currently is not addressed properly in the OFM standard. What we need is some reliable statistics to see how the particular features are used in at least most popular OFM implementations and if the particular feature provides sufficient return on investment to implement it in order to be included in the standard feature list.  Some features in current implementations are definitely depreciated and probably can be deleted from the part 1 of the OFM standard. But it is difficult to do without studying the statistics of actual usage.