Less is More: The Orthodox File Manager (OFM) Paradigm

by Dr Nikolai Bezroukov

Content : Foreword : Ch01 : Ch02 : Ch03 : Ch04 : Ch05 : Ch06 : Ch07 : OFM1999 : OFM2004 : OFM2012

Ch. 1: Introduction

• Overview of the OFM implementations

• Ten Commandments ;-)

• Text-based vs. GUI-based interface

• The history of the OFM implementations

• Advantages of OFMs

• Milestones of the OFM paradigm.

The Orthodox File Managers (OFMs), also affectionally (but incorrectly ;-) known as "Commanders" are probably the most influential type of file managers. But the OFMs are more than just a popular type of file managers. It is a cultural phenomenon that we ( lacking more precise definition) will call the OFM interface paradigm or even Orthodox Computer Movement.

They value the keyboard interface (while not rejecting convince and tremendous possibilities introduced by the mouse) and try to implement a novel, more efficient methods of combination of GUI interface with command line. One such innovation is the ability of Orthodox file manager to export certain values from the panels (such as path to left and right panels, the current file, etc) to the environment and then add them to the command line either via shortcuts or via the value of special environment variables. In different forms this value of "peaceful coexistence" of command line and GUI interface is also reflected in Unix administrators devotion to vi and screen, or VM/CMS users love for XEDIT. Those program are also including into Orthodox interface paradigm.

Notion of Orthodox interface

Orthodox interface is the interface that has both command line interface elements and GUI interface elements glued together.  As cynics would say this is a half-baked GUI-interface and this statement definitely has some truth as at least one of them  emerge during attempts to convert previously pure command line tool to GUI (text terminal GUI) mode: this was the case with vi which was text terminal GUI extension of ex editor.  Apple and Microsoft GUI interface attempt to hide from us the internal command that you mouse gestures are generating, while orthodox interface attempts to expose it.

In Orthodox interface there is always a set of commands that exists as a language with text  names for functions and parameters and glued together by control structures. Special keys and key combinations as well as mouse buttons and mouse gestures are just shortcuts to this basic set of commands. So interface is split into two parts:

• Generation of internal commands via GUI

• Execution of generated internal command by internal language processor.

This existence of formal internal language is the most distinctive feature of orthodox interface.

And this idea was invented and reinvented by so many people that it looks like this is a new different type of interface, distinct from Apple-Microsoft interface.

For example this is true for various OFM, for orthodox editors such as vi or XEDIT like of editors (Edit, Kedit, THE, Slickedit), for GNU screen, smith in AIX and many other programs.  Those tools were from the beginning designed is a way that allow coexistence of command line with GUI interface. So in a way Orthodox interface is all about co-existence of two principal forms of computer interfaces in a single program by using command line as the focal point. 

That means that we can look at orthodox interface as a compiler of GUI "gestures" into regular command language with text representation. Those generated statements of this command line language are executed to achieve the desired effect.

We can also introduce idea of channel: each channel forward generated or manually written commands to specific processor. For example we can thing about vi as having two command channels: one is ": channel" (internal commands channel) which process commands directed to editor buffer and another is "! channel" (external commands channel) which direct commands to OS with the possibility of using all or part of editing buffer as input as well as to modify all or part of the editing buffer using output of executed in OS command of complex pipe. 

In OFMs this is implemented differently: there is a single "OS command channel", but there is not distinct "internal command language", althouth some OFMs recently moved in this direction.

All-in-all I am convinced that the notion of Orthodox interface as an interface distinct from and based on different principles then Apple and Windows GUI interfaces (which are actually became much closer with time). As such this is a much wider phenomenon then either OFMs and orthodox editors such as vi and THE (orthodox editors),  windows multiplexers (GNU screen), windows managers (such as ratpoison).

I am still working on refining this notion but as a set of  ideas it definitely includes three following notions:

1. Extensibility and programmability (with shell and/or scripting languages) are key to enhancing productivity of advanced users and as such they should have much higher priority for designers of the interface then chrome.  This "the ability to program as second literacy"  paradigm (see  Ershov1972 ) inherent in orthodox interface is actually radically different design paradigm than the one used in classic Apple-Microsoft GUI with their emphasis on "users" and  multicolor eye candy with gradient colors icons and fancy animations.
    
2. Orthodox GUI is a "visual shell".  Like classic Unix shells, Orthodox GUI should have least one "command channel": ability to type statements in some formal language which, when executed, change the state of GUI. In other words they implement what can be called "command line controlled GUI". It can be just "external" command channel where commands  go directly to OS (like in OFMs), or internal command channel where commands are processed by internal interpreter (for example REXX or Lua) and reflected on the part of editing buffer that is displayed as in orthodox editors, or some combination of both. Commands that are entered into command channel are executed immediately like in shell and the result is immediately reflected in GUI interface. They can be glued into complex scripts by some ad-hoc or (preferably) standard scripting language like REXX or LUA.
    
3. Elements of  automatic program generation with the help of GUI.  Another way of looking on orthodox interface is to assume that GUI "gestures" in it first are compiled into some command line language and that those generated statement are executed by command processor and cause corresponding changes in GUI screen. That means that we can (and probably should) look at orthodox interface as a compiler of GUI "gestures" into regular command language with text representation. Those generated statements of this command line language are executed to achieve the desired effect.

   GUI can also be used in supplementary role to generate part of command line construct that are written by the user on the command line by inserting certain elements via macros or shortcuts like (Ctrl-Enter, Ctrl-[ and Ctrl-] in OFMs) and any other creative way. Generally in OFMs you can "assemble" pretty complex commands from elements of GUI (and freely move within directory tree in a process without destroying it, the capability that was always a desirable part of Unix command interface)

   Recently those ideas related to vi and orthodox editors started cross-pollinated OFM that consider themselves not derivatives of Norton Commander, but derivatives by  vi  See ranger and vifm. have some interesting, distinct from traditional "Norton" line of OFM ideas implemented.

There are also some other common features but they just overlap and extend the three more fundamental features listed above:

1. Tiled, nonoverlapping windows with minimum decorations. Generally both Orthodox editors and Orthodox file manager feather rather Spartan interface.
    
2. Stress on availability of all commands via keyboard, not only via mouse clicks, althouth mouse can be productively used and is widely used in such interface. In this sense claim that such interfaces are "mouse-less" is completely untrue. Simply mouse plays the role of important but supporting instrument, not as the primary instrument as "drag and drop" type of interface. 
    
3. Stress on availability of macrogenerator. This is connected with viewing shortcuts as the means to generate some internal commands.
    
4. Stress on the ability to utilize pipes and external program as a source of gui elements. This is especially visible in vi with its ! and !! commands. Ability to redirect output of commands executed in one window to other windows and processes. That includes the ability of forwarding result of particular command execution into panel in OFMs (panelize command in OFMs, especially external panelize command in Midnight Commander) and capability of ! command to use part of editing buffer as input and pipe the result into selected part of editing buffer in vi. For example, the command:

   :1,$!indent

   will beautify your program using standard Unix beautifier (indent). This is a classic example of using piping in vi.
    

Alterative GUi Interface that Strives Despite Being Far from Mainstream Ideas of Proper Interface

For a typical Windows or Linux user it looks somewhat strange that people continue to use descendants of a character-based file manager called Norton Commander that was initially designed for PC XT in 1986. With interface that definitely looks out of touch with modern trends and Apple-Microsoft GUI, that became dominant force in computing and defines "fashion" (and fashion plays more important role in IT then even in women closing).  Equally strange is that a lot of talented programmers devote considerable time solving intricate problems of designing a modern versions of OFM-style file managers. I believe that many users and even developers never heard about at least half of the implementations discussed in the book, but still can almost instantly recognize any of them as belonging to a special class just after seeing a few screenshots and key bindings. Actually the number of existing OFM implementation was probably the biggest surprise for the readers of the previous two editions of this electronic book (especially the first edition) as I can judge from the number of letters from readers that either contain some variant of the phase "My God, how you dared not to mention XXX -- such a wonderful OFM file manager. Shame on you..." or some variant of the phase "Oh, I never suspect that there are so many of them" ;-).

On the Importance of Standards for Orthodox File Managers

Standards are important for any mature software as they provide a framework that helps new developers "to get to speed" that puts various implementations of this type of file manager into common general computer-science and historical context. The main idea behind the series of standards that I created is to analyze several historically important and influential implementations and refine their best features which supposedly  should be strived to achieved by all implementations.

Currently three standards exists:

1. Orthodox File Managers Standard 1999(OFM1999) - basic OFM requirements This is the   standard that defines the currest state of development of OFMs. The base of this standard are leading implementations such as FAR, Total Commander and Midnight Commander as well as good  good NC line of OFMs which now belong to abandonware.  It is expected to be revised once in five years but in reality is revised less often.  In 2012 version three of the standard was released. It defines 21 test of file manager compatibility with the standard. Here are the scores achieved by different implementations:
    

   OFM1999 v.3 score (average of all 21 tests)		NC	VC	DN	FAR	Total CMD	NCW	MC	FC
   Scores		68	71	73	89	70	68	66	75

    

2. OFM Standard 2004  This is "Advanced OFM" standard, that describes functionality which corresponds to innovations introduced in  "modern" implementations of OFMs. 
    
3. OFM standard 2012 (in the works) This is "Dream OFM features" or, if you wish, cutting edge features ;-). Due to the danger of overcomplexity "excessive zeal" in defining and extending such a standard can backfire. That's why the last 2012 is still contains very few features .  Fighting "excessive zeal" is very important and "cool down period"  after I discover some generalization or new exiting feature and time when I include it in the standard is set to one year... 

I hope that those standards can be useful for the authors of the OFM implementations to ensure interoperability and to avoid reinventing the bicycle in the most incompatible way possible ;-). They also stimulate to spend proper amount of efforts on features that proved to be the most valuable features. For example,  full implementation of shell screen capabilities proved to be extremely valuable but, unfortunately, right now only FAR comes close to proper implementation of this functionality (it provides ability to resize panels both vertically and horizontally). Such otherwise excellent implementations of OFM as MC and Total Commander lagging far behind.  I think that new implementation of OFM managers this represent a viable way to gain market share and "unseat" older implementation that lack this feature.

Another extremely important, but underappreciated feature is the ability to launch scripts with parameters defined in the current panels (the active and passive directory, the current file on the active panel or list of selected files). Those environment variables should be available not only in commands added to user menu (F2), but on the command line too. MC is a pioneer of this feature and I think it deserves the adoption by all OFM developers. 

The role of standard is to unify the field and hopefully to help developers to avoid reinventing the wheel. This is impossible without proper feedback mechanism. I believe that there should be more information exchange on this important type of file managers and more sites devoted to this. I hope that my modest effort will stimulate other people to create similar sites.

Despite the simplicity of the concept OFM functionality contains very rich and well integrated combination of features, so rich that advanced users like myself still are able to discover new possibilities after using OFMs daily for almost twenty years. OFM also contain some non-obvious capabilities the value of which is not apparent without years of experience with the particular file manager and/or good knowledge of the underling shell such as bash.

Why this book was written

This book is based on  my personal experience in OFM usage since 1989 and try to present historical perspective on the development. There was conscious attempt on my side to present things in their historical progression. For full mastery of any tool it is important to know historical roots of features that are deemed important. 

As we discuss multiple examples of OFM for several OSes, we also can demonstrate the level of diversity of the field. This way some cross pollination of ideas also can be achieved as extracting all this information individually, while possible is quite time consuming. Here is presented as a more or less coherent ebook and is based on almost 25 years of experience with this filed by the author as well as his training as a computer scientists. Few books about file managers are written by Ph.D in computer science as the field is looked upon as too low. But I became fascinated with it and don't care what my colleagues think about this :-). As m=some of OFM managers are now belong to open source I consider this book as my modest pro-bono contribution to open source software development, although I do not share all the related ideas. In any case I think that my computer science background might be an asset in my attempts to define the state of the art of the OFM construction both with this ebook and OFMs standards mentioned above. 

For users this ebook might provide an interesting glimpse into the history and major players as well as help to select an implementation most suitable for their needs. As you will see, not all OFM implementation are created equal. 

In both cases the availability of some kind of OFM standard is very important as a benchmark against which to measure existing implementations. As implementation change and new, better implementation arrive on the scene (or developer team changes in old implementations like happened with Midnight Commander) such a standard should be periodically revised. In developing such a standard by analyzing many different OFMs created for different platforms I see the main value of the book and my modest contribution to this field.

Recently there was a new wave of interest in OFM implementations for Unix. Midnight Commander, the development of which was stalled for a couple of years, again shows sign of life. It is now clear that OFMs provide a unique extension of the command like interface provided by typical Unix shells and despite being created initially for DOS environment blend perfectly into Unix command line environment. That's why Midnight Commander and other Unix-based OFMs implementations are considered so important and discussed in such detail on this book. In author opinion they have the lasting value as a new generation of command line interface of Unix shells and may in future blend with bash or other Unix shell (actually one attempt of merge OFM and bash was already made). I also think that at present level Linux console interface is close to elimination of limitations of older Unixes and can emulate most features of classic DOS interface with Ctrl, Alt, Shift and their combinations fully supported. OFM partially depend of the richness of keyboard functionality and it is really stupid not to provide full emulation of capabilities of standard PC keyboard in modern Unixes: the standard PC keyboards now probably constitute 99% of keyboards in active use.

Ten Commandments ;-)

There is a large variety among OFM implementations. Moreover different OFMs are good for different situations and tasks -- there is no and never will be the best OFM for all situations and environments. But they all share same distinctive interface framework and the following basic features:

1. Spartan interface with unique, "non-fashionable" but very functional structure: two symmetrical panels that display files in two directories and a minimized (but extendable to half and full screen)  telnet-style terminal session with local host ( command line ) at the bottom of the screen.  
   • One panel is current (active) and second is passive; they are switchable with the Tab key and identical in functionality. For all "binary" file operations (copy, move, symbolic link, etc) the target by default is the directory of the opposite (passive) panel. 
   • Unique (incompatible with usual Windows assignments) keystrokes assigned to each function. Traditional OFM key assignments are: F1 - help, F2- user menu, F3 file view, F4 - file edit, F5 - file copy, F6 - file move/tree move, F7 - make a directory,  F8 - file delete, F9 - top menu, F10 - exit. Those key assignments are also depicted on the bottom line as buttons clickable by the mouse. And this line also serves as "sheet sheet" as content changes if you press Alt, Ctrl or Shift key.  Although functional key assignments are traditionally preserved in OFM implementations, they are not a part of OFM paradigm. If remapping of the keys is implemented (for example in a way, similar to vim implementation), than any other combinations (including more Windows like) can be used. Again only semantics of the operations is fixed and should be implemented "as is", although consistency of key assignments has value as  "old finger habits die hard" ;-).
   • The ability to perform most functions without mouse which is especially useful on the laptops and now palmtops as well as  for troubleshooting; mouse serves as a useful supplementary, not primary input device in OFMs.
   • Unique help line at the bottom of the screen (below command line) that displays the functions of F-keys and values in which change if you press and hold Ctrl, Alt or Shift keys.  In the latter case it should depict function performed by corresponding shortcut, say for F5 functions performed by Ctrl-F5, Alt-F5 and Shift-F5 shortcuts. The same approach should be implemented (but often is not) in dialogs as one fundamental problem with applications that emphasize usage of keyboard is "too many shortcuts" problem. This OFM feature significantly alleviate the pain and should be treated as fundamental feature of interface, not something superficial that can be implemented or not. 
      
2. Seamless integration with the shell making OFMs a synonym to "Visual shell.". There are two features that are obligatory for orthodox file managers
   • Command line windows can be extended either gradually (expanding/shrinking line by line) or at least in two steps (half screen/full screen)  providing  native shell window like in telnet to the localhost. Any command line OFM should provide perfect emulation of telnet terminal capabilities for supported sizes of command line window with the ability to view more data by expanding the window (with size increasing by line or in larger chunks, for example from one line to half-screen and then to full screen). In all cases where more then one line window is present the user should be able to view (and possibly scroll) the results of execution of commands entered on the command line like in regular telnet client (in this case telnet to localhost).  This command window capability links OFMs with famous Unix program GNU screen and derivative Spartan text-mode windows managers like Ion (with fully documented configuration and scripting interface on top of the lightweight Lua extension language), Ratpoison,  twin, evilwm,  and several other that I forgot to mention.
   • You can insert elements from the panel (such as the current file on active and passive panels, path to active panel, path to passive panel, selected files, etc) in the command line. This capability should be available both using keyboard shortcuts (Ctrl-F for current file. Ctrl-[ and Ctrl-] for path to left and right panels, etc) and using macros (for example "%f" for the current file, "%F" for the current file in the passive panel, "%d" for the current directory name, "%D" for the same on passive panel, "%t" for the currently tagged files and "%T" for the same on passive panel). The ability to  assemble complex commands on the command line using elements visible on the panel is an interesting alternative to drag and drop.  It allows richer functionality, as operation performed is not fixed unlike drag and drop. The same macros (or environmental variables) should be available for scripts in user menu (F2 menu) and in extensions menu. 
      
3. The ability to extend file manager functionality with custom scripts providing users with script library (called user menu and traditionally available via F2). Both command line and GUI-based OFMs should have the ability to create a library of "helpers": simple (or not so simple) shell scripts accessible using F2 . You can invoke them by assigning each of them special hotkey. Scripts should permit macro variables that reflect the current status of both panels (path to active/passive panel, the current file on active/passive panel, selected files , if any, etc).  This simple, ingenious, and very functional  extensibility with custom shell scripts make OFM very attractive for system administrators. They are useful for advanced users as they greatly simplify working with archives, ISO and so on and so forth. Actually in late 80th, early 90th of the last century in the former USSR region many DOS users never suspected that any other DOS interface exists: OFM interface was the standard and the only DOS interface they knew. 
    
4. The availability of scripts associated with file extensions via special file extension menu and invoked by pressing Enter on the file with the particular extension on a panel.  This is another way to extend file manager functionality and file extension associations were pioneered by Norton Commander.  Special customizable extension files that permit context-dependent invocation of scripts and programs on a  file click (execute), F3(view) and in F4(edit). Customizable file extension menu should provides automatic passing of various panel-based parameters to shell scripts via macro variables (or environment variables) that were discussed above (active file, path to left and right panels, list of selected files, etc)
    
5. "History for everything" approach to user input in command line and dialogs.  Starting from Norton Commander all OFMs provided the history of commands. Modern OFMs add to this the history of directories visited, files edited, selections, etc. Some advanced OFMs like Midnight Commander add to this the idea of "file/text completion for everything".
    
6. Integration of application protocols into file manager framework via virtual file systems(VFS). Most popular are  ftp client VFS and archive VFS. Commonly they are implemented as plug-in based on some defined plug-ins API. Less popular, but still very important are Search VFS and "flat tree" VFS. They are all based on the same concept of a virtual file system:
   • FTP virtual file system  -- historically important capability which provides that capability of working with ftp session like with the local filesystems. Perfect for complex ftp operations and as powerful as most standalone GUI FTP clients. Now with the availability of FTP virtual filesystems and ssh is less useful.
   • Archive VFS: Extremely polished VFS-based  interface with archives (gzip, zip, rar, arj) and, in case of Unix OFMs,  installation packages (RPM).   It was historically first VFS implemented in OFMs and dates back to NC3 extensions.
   • Search VFS: This VFS is usually implemented via "panelize command" and permit viewing on a panel as in virtual directory all the files and directories that were found in a particular search operation.
   • XTree or "Flat tree" VFS.  Most modern OFMs provide the possibility of viewing all files in a branch of the tree in a "flat" representation (often bound to Ctrl-B). This representation is extremely important for working with files dispersed into several directories as is often the case in most application installations.
      
7. Tight integration of text files viewer and editor within OFM. An integrated viewer for text files and an integrated editor provide some additional and valuable integrating capabilities
   
   Both editor and viewer should be able to work in full screen mode (default) and "panelized" and should have access to information on both panels (current file, path to the active/passive panel, etc) and ability to treat selections as objects to past into command line (for example for moving to directories). Both editor and viewer should permit pasting information to from the editor to panel (for example, change directory to selected, paste selected into command line, etc) and getting information from panel (names of selected files, etc) and selected parts of the command execution screen back into the editor. 
   • Editor
     • Editor should usually support syntax coloring and regular expressions search (like in MC and FAR).
     • There should also be a possibility of "sequential edit" or viewing of selected files. In this case closing the file switches editor or viewer on the next selected file.
     • The editor should have an information line at the top and key shortcuts buttons at the bottom (similar to the panel view help buttons); the position of cursor and the current letter under the cursor should be visible both in ASCII and hex at the editor information line.
     • Editor should be able to execute script on selected part of the buffer or all the buffer like vi ! command,  providing ability to extend its functionality via editor menu similar to user menu. 
   • Viewer
     • The viewer should has ASCII and hex modes of viewing files. In panelized mode it should allow viewing selected files one by one: closing of one file opens the next selected file in implicit loop. Previous file is deselected (behavior similar to copy and move operations on selected files).  
     • There should be a possibility of switching from the viewer to the editor and back.
8. The ability to add search results to a  browsable virtual panel (panelize command) and a special "directory only" search in a special "find folder" panel. There should be abilities to find an arbitrary file(s) in the filesystem with capabilities equal of better then Unix  find and grep utilities, but with more friendly interface. All panel operations that make sense (view, edit, copy, move, rename, delete) operations should be available from panelized search results:
   • The possibility of  viewing and editing found files using built-in or external viewer or editor any found file.
   • Possibilities to create a panel out of search results or copy them to temporary panel and work with it as with regular directory panel  (panelize command). This is essentially another variant of  search VFS.
   • Ability to search directories only using NCD derived quick search method on directory trees:  In OFMs there are two distinct tree panels:
     • A regular tree panel. Activated by Ctrl-T. In this case tree replaces the passive panel Tree panel should work in three modes:
       • The default mode: The cursor can be moved independently and does not affect the opposite panel. Pressing Enter opens the directory under the cursor in the opposite panel. Copy and Move operations from the opposite panel are targeted to the current directory on the tree. Quick view mode ("dive into the directory mode") should be available via hotkey Ctrl-Q.  No such mode exists.  Navigation is limited to cursor keys and Enter.  Quick search is available but the is no capability to find the next directory with the same prefix.
       • Quick view mode ("dive into the directory mode") Switchable with Ctrl-Q. This mode is similar to the behavior of Windows Explorer movement of the cursor opens the directory under the cursor in the opposite window.  Mostly used for quick traversing of the directory tree in a mode similar to quick view with directories opening as we move the cursor (quick diving into subdirectories). Quick search should be available.
       • Information mode (Ctrl-L). Similar to quick view mode. But in this case the movement of the cursor on the tree panel opens not a listing of files in the directory but the information window should be shown that calculated statistics for the directory (number of the files, total size, number of subfolders, attributes, owners, etc). 
     • The directory search panel. Activated by Alt-F10. Also present in the top Command menu. This panel should instantly provide a quick search window. It should be also accessible from copy/move dialogs  (via F10) and it is often used not only for the "directory completion" and traversing of the tree, but also for the quick selection of the target directory for copy/move operations.
        
9. Client-server connectivity. There should be some kind of client-server connectivity between two instances of OFMs (preferably SSL based TCP/IP connection, or unencrypted TCP/IP connection like in MC, or connection via serial cable like in NC3-NC5, or parallel cable and USB cable like in Total Commander).  This is a fundamental feature because it dictates client-server architecture of OFM with client part and server part separated by some kind of API. Generally one instance OFM should be able to perform as a server (represented by one panel) and second as a slave (represented be the other panel) with the ability to copy files and perform  commands on the remote host. 
10. Extensibility via plug-ins mechanism. System of plug-ins that extends functionality of the OFM (FAR, Total Commander) and corresponding API.  This is important for OFM architecture as it separates panel interface from the rest of OFM.  FAR is now open source and its plug-in API can serve as an inspiration for future developers.

Again those are Commandments and like in everyday life not everybody is observing them ;-). The worst situation is with providing ability to extend command line at the bottom to command line window. Please note that This unique, innovative capability of Norton Commander (the one that makes it a graphical shell) for some reason is rarely implemented correctly if at all. Please remember that the original name of Norton Commander was VDOS -- visual shell for DOS.

Even such leading OFMs like Total Commander and Midnight Commander  do not implement them correctly. For example, in Total Commander  just basic command line functionality is available without ability to extend command line window to half screen of full screen.

In Midnight Commander only full screen command line window available but its functionality is limited (no ability to extend command line window to half screen or expand it line by line as in FAR) and behavior of command line window is different from typical bash shell command line windows which makes it unattractive for power users (compare with  GNU screen "split windows" mode, which should serve as reference implementation of this feature).  In other words MC command window implementation represent example of a cheap hack.  Paradoxically Unix OFMs users (and first of all Unix sysadmins) who would benefit from this functionality most (as culture of using command line is strongest in Unix) need to deal with the weakest in implementation of this feature

Notwithstanding differences and weaknesses of existing implementations three key features stands out and are the key postulates of faith of the "OFM religion":

• Three tiles interface with two upper tiles representing symmetrical panels that display two directories and lower "wide" tile command line windows with shell interface.  Among two upper panels one is called active and it displays the current directory ($PWD in Unix) and the other passive and displays the directory the user navigated to while it was active). Tab changes active panel to passive and vice versa. Each or both can be hidden exposing command line windows. Size of active and passive panels should not be fixed and there should be at least possibility to shrink them to 50% of the screen.
   
• The ability to invoke user scripts with context elements from both active and passive panels such as the current file, path to active panel, path to passive panel, etc.  The latter capability is provided via the set of macro variables representing elements of the active and passive panels. User panel contains small self-contained scripts that expend the functionality of OFM and in advanced OFM can be hierarchical and/or dynamic (only elements that make sense based on the current context are present in the menu). User menu is usually invoked via F2. The same set of macro variables can be used in command line. In addition they can re represented by shortcuts such as Ctrl-Enter (current file), Ctrl-[ path to left panel, Ctrl-] -- path to right panel, etc. The same shortcuts can be used in internal editor, which should have capability to send selections back to command line.
   
• The ability to perform any operation with the keyboard and the ability to assemble complex commands on the command line from elements of the panel (as well as launch scripts that inherit values of elements of panels via macro variables).   Mouse functionality is a nice addition and can be more efficient the keyboard for some operations, but still keyboard alternatives should be provided in each and every case.  Ability to assemble complex commands on the command line using predefined elements of left and right panel actually is step forward in comparison with drag and drop and allow richer functionality, never possible with drag and drop. In can be called drag and drop on steroids.

Complex file operations using mouse is not faster and as cases became more complex are less convenient then performing the same operations using keyboard-based interface using the file manager that implements Orthodox interface paradigm. In a way orthodox means "having the right opinion/following the right practice". And using full power of keyboard (while not rejecting mouse) looks exactly like this. Provided by OFMs unique combination of GUI elements with the preservation of the power of command line is superior to any "mono" interface: either "classic Unix command line" interface or Windows-style GUI interface.  There are several reasons for that. See GUI vs Command line interface.

Text-based vs. GUI-based interface

Another important question that arises is why to use to a text mode file manager when GUI file managers with fancy bars, buttons, drag and drop are standard for Windows and are widely available for Linux. Orthodox File Managers are example of "less is more" and prove that functionality of programs with well developed command line interface can give a run for the money in functionality to any GUI-based file managers. Actually functionality of Volkov Commander, a 64K (sixty four kilobytes!!!) COM program is superior to many file managers twenty time this size. While mouse is a convenient pointing device as we will see later there are certain undisputable advantages of a command line interface-based OFM   because they essentially are a new generation of the command line interface for the operating system shell.

Console interface OFMs  usually have much lower resource requirements: often they are small programs that can be used on different computers without any installation and are loaded instantly. For example one of the famous early implementations of OFM Volkov Commander (VC) is just 64K program that can be downloaded even on a computer over slow modem. They can be carried on small USB solid state disk, CDs or even floppies.

Of course there are some drawbacks as well. But actually the key features of OFMs do not depend on whether it has GUI-based or command line interface. It is the idea of full utilization of keyboard capabilities that really matters. That's why that are so many excellent GUI-based OFMs like Total Commander. Although the OFM paradigm is rooted in the character text interface and command line OFM implementations are text-based, OFMs are not limited to it. It is not a type of GUI per se, it's not keystrokes (if you can reassign them), it's the presence of the command line and the ability to perform them using the keyboard that matter most. Now a lot of OFMs successfully use GUI interface. Some, like Midnight Commander 4.5, have two versions: one text mode based and the second GUI-based.

GUI with it's ability to display different fonts, provides much more capabilities, than restrictive character-based interface. Nevertheless the character interface is really important and considered classic from another point of view. Artists know well the saying "form liberates". In the same way puritan character interface liberates a programmer from spending too much time and effort on unimportant things and thus provides the possibility to spend most of the time implementing richer set of operations. Paying too much attention/time/effort to the "face makeup" is characteristic to Windows developers and often negatively influence the core functionality of the product.

But it is possible to create a very good OFM with GUI-based interface that is as rich in functionality as the best OFMs with shell-style character-based interface. It's actually nice to have both keyboard interface capabilities and mouse-based drag and drop capabilities. I found more then a dozen pretty advanced GUI-based OFM implementations on both Windows and Unix platforms. Among them:

• Total Commander by Christian Ghisler (http://www.ghisler.com/). Probably the best GUI-bases OFM for Windows.
• Norton Commander 2.0 for Windows from Symantec.
• Frigat 3 by Helmsman Ltd
• WinNC by R. Speets and C.Hamers
• WinNavigator by WnSoft Inc
• Nico Commander by Nico Cuppen
• Altar Salamander by Peter Solin.
• Northern Capitan by Leonid Khramov
• X WinCommander (XWC) by Maxim Baramov
• FileRunner
• Tk Commander

The history of the OFM implementations

The first OFM was written by John Socha in 1985-1986. He started developing Norton Commander before joining the company called Peter Norton Computing started to sell them commercially. Later when he became the first director of research and development for now defunct Peter Norton Computing. It was this  company which released the first version of the product under the name of Norton Commander in 1986, and where it it established name.  Peter Norton who wrote the initial version of Norton Utilities but AFAIK was not involved in writing Norton Commander. He was one of the pioneer entrepreneurs in PC software development and his company was among the first wave of successful PC software development startups that includes such names as Borland, Lotus and, of course, Microsoft. Now he is known mainly due to his role as a photo model on the boxes of Norton Utilities and other Symantec products belonging to a "Norton line" ;-).

After the first version of Norton Commander was released in 1986 it instantly became a dominant file manager for DOS. Version 2 was released in 1988 and version 3 followed the next year in 1989. In 1986-1991 more then a million copies were sold.

In 1990 Peter Norton sold his company to Symantec to pursue his interests outside programming. John Socha left the company after the merger and created his own company, which was letter acquired by Asymetrix. He no longer participated in the development of Norton Commander and this line of products experienced a fast decline. He continued cooperation with the Norton division of Symantec in other areas and wrote for them several good computer books including classic introductory assembler textbook Peter Norton's Assembly Language Book for the IBM PC . Symantec first displayed some lukewarm support for this cash cow and released version 4 (1992) and 5 (1994), but with the introduction of Windows 95 killed it and other DOS products (XtreeGold) that it acquired. Later they understood the mistake they made and in 1996 there was a reincarnation attempt in the form of a GUI-based version. Norton Commander for Windows 1.0 was launched in 1997, three year after NC5. But that was "too little, too late" and after one upgrade (version 2.0, 1998) it died again (still as of January 2003 you can buy Norton Commander for Windows 2.0 in Europe, especially in Eastern Europe).

But it was Europe where this type of file managers found new home after being abandoned by Symantec. Although originated in the USA, since early 90th of the last century the OFMs became mostly a European phenomenon with a very strong following in Eastern Europe (especially in former USSR countries), Scandinavian countries and Germany. I believe that the total number of the OFM implementations (including discontinued) is close to a hundred and more then two-third of them belong to developers from Eastern Europe and xUSSR area.  This figure alone says a lot about the phenomenon. No other type of file managers ever managed to get such a strong following. The concept migrated to Amiga and considered by many Amiga fans as a native -- some of OFMs listed below are continuations of the Amiga line, but I am not familiar with Amiga -- other that it pioneered usage of REXX both as an external (shell) and internal (macro) scripting language and was a very nice OS, so this avenue of OFM development is underrepresented in the book. Actually Amiga managed to integrate several great concepts into its environment and was probably the first OS where both shell and application macro language was the same (REXX).

OFM usage is also part of the hacker culture, especially East European hacker culture -- for example in Russia it is a must to any self-respected hacker to impress his friends by performing blazingly fast file operations on a favorite OFM (in old days it was usually VC). Later it migrated in Unix administration and most Linux and FreeBSD administrators in Eastern Europe used this type of managers in their daily work (Deco and Midnight Commander are probably the most popular but many others are used).

We will distinguish between command line character-based interface OFM implementations that use text interface and GUI-based OFM implementations. As with any popular product along with mainstream (orthodox) implementations there are various non-conformant/alternative implementation which deviate in some ways from the orthodox set of features and key bindings. Still most command line OFMs are quite compatible and users have no problems with switching from one to another.

One of the first attempt to generalize Norton Commander functionality was probably PIE Commander by Valentin Chernyak (Moscow). It has had four independent panels instead of two. The first Unix-based implementation was probably deco  (Demos Commander) by Sergey Vakulenko. It was also written in Moscow in 1989.

Four major DOS-based OFM implementations (VC, DN, FAR and CN ) are from Ukraine, Moldavia, Russia and, again, Ukraine. There are several Unix-based OFM implementations from this region as well (deco, Northern Capitan, etc.). In the former USSR countries OFMs are often taught at introductory university courses and books describing techniques of working with this type of file manager has been published in several millions of copies. Moreover from the late eighties till the early nineties for entry level users in the former USSR countries OFM interface was a synonym to the DOS interface. Many users never ever suspected that the OFM is not a part of DOS or that regular command-line DOS interface exists :-).

In other European countries OFMs are very popular as well. There are many implementations of OFMs in that region (probably at least three for each European country, I just do not know all of them and would appreciate additional information from the readers; also attribution to country in the list below might be wrong). Here is the list that I compiled from my Orthodox File Managers Bulletin:

• Several Czech implementations
  • Portos Commander (Pcmm) by Tom Potrusil QT-based file manager for Linux for KDE.
  • Altar Salamander by Peter Solin, GUI-based implementation; actively maintained)
• A Dutch implementation (Nico Commander by Nico Cuppen, shareware GUI-based implementation; actively maintained);
• A Denmark implementation (Crash Commander by Martin Rasmussen);
• Several Finnish implementations:
  • Adrenal Manager
  • X-Files - The Ultimate File Organizer
  • XWC-X WinCommander-International version
• Several French implementations
  • F: Freeware Multi-platform File Manager (with mainframe version !)
  • muCommander a cross-platform file manager by Maxence Bernard
  • X File Explorer - A file manager for X by Roland Baudin (based on XWin Commander by Maxim Baranov)
• Several German implementations
  • EFC be Emil Fickel,
  • Just Another Commander by Alexander Klappert
  • Jet Commander by Frank Klosek,
  • KCommander (for KDE)
  • UFO by Hansmann/Wildgrube/Yoran GbR, (Deus Ex Machina Communications));
• A Greek Implementation: 2xExplorer by Nikos Bozinis,
• Several Hungarian implementations
  • Star Commander by Joe Forster/STA. although can be used as a decent DOS-based command line OFM, it has additional Commodore-related capabilities. It understands Commodore file formats (and file formats of the C64 Software Emulator) and can actually access a Commodore drive attached to the PC.
  • Byte Manager see Official Byte Manager Homepage -- small, DOS-based file manager
• An Italian implementation (Ramsete Commander by Marco Varagnolo);
• A Netherlands implementation (WinNC by Ramon Speets & Kuno Hamers. A GUI-based implementation. Shareware from Dunes MultiMedia http://www.dunesmm.nl/winnce. Actively maintained);
• Several Polish implementations
  • GUI-based Foltyn Commander Foltyn Software, Warszawa, e-mail: [email protected]
  • Patryk Commander by Patryk Wozniak (for Win 95/NT)).
• Spain implementation Last File Manager
• Several Swiss implementations:
  • Total Commander by Christian Ghisler, shareware, GUI-based implementation; probably the best GUI-based OFM implementation (actively maintained).
  • Obsession Development's Gentoo -- a very interesting TK+ based implementation.
  • Linux Commander -- Linux Commander is a project started by Per Holmфng in 2000.
• Several UK implementations

Other continents also joined the race :-). Among them

• Australia: The high quality Australian implementation -- File Commander (FC) by Brian Havard is very popular in the OS/2 environment. It is available for Win95 and NT too (both OS/2 and Win95/NT versions support long file names and a virtual file systems for archives). No doubt OFMs are well known in Australia too and anti-establishment spirit of Australian programmers provide a good soil for creating various OFM implementations.
• Africa: South African implementation Gram's Commander v3.3 by Graham Wheeler (the author now lives in the USA). Gram's Commander was the first scriptable OFM (~1991).

The remaining part of this book provides the following information:

• An overview of several historically important command line based (DN, FAR, NC, FC, JC , etc) OFM implementations for DOS and some OS/2 implementations (unfortunately both OSes are dead now)
• An overview of several Unix-based implementations (deco, MC, Northern Capitan (the latter being X-based beast))
• An overview of several Windows 32-based implementations: one for the command line interface (FAR) and two GUI-based Windows Implementation (Windows Commander and Norton Commander for Windows 95).
• An overview of several scripting languages based implementations
• An overview of several Web-based and Java-based OFMs

Unique Portability of OFMs

I would like to stress that OFMs are truly portable file managers that can be used on PalmPilot and on mainframes with PC and Unix computers in between. Although OFMs originated in DOS, they proved to be very natural to Unix environment and more than a dozen OFM implementations exist for UNIX. The first UNIX implementation of OFM was released in 1989. It was deco  (Demos Commander) by Sergey Vakulenko. The development continued till 1993 and currently the source resides on Sourceforge. It is still widely used in FreeBSD administrators. Currently the most popular in the UNIX environment is Midnight Commander.

Right now OFM development is slightly biased toward GUI-based implementations. As I mentioned above it is perfectly possible to create a very good OFM with GUI-based interface (especially in scripting language like Perl, Python or TCL). It's actually nice to have both keyboard interface capabilities and mouse-based drag and drop capabilities. While I have found more then a dozen of pretty advanced GUI-based OFM implementations on both Windows and Unix platforms, only TCL-based implementation are fully scriptable OFMs in existence.

Among GUI-based OFMs I would like to mention the following (in alphabetic order, in bold are those that are discussed in the book):

• FileRunner (TCL-based manager that because it is scriptable in TCL is in some areas a far ahead of others GUI implementation)
• Frigat 3 by Helmsman Ltd
• emelFM2 -- a very interesting GUI-based Linux OFM based of GTK+. 
• Nico Commander by Nico Cuppen
• Northern Capitan by Leonid Khramov (Probably the best OFM for X Windows; actually this is a very apt name, because OFMs are all about navigation in extreme conditions much like in Arctic and Antarctic)
• Norton Commander 2.0 for Windows from Symantec.
• Portos Commander (Pcmm) by Tom Potrusil
• Altap Salamander by Peter Solin.
• Total Commander by Christian Ghisler. Probably the best GUI-based OFM for Windows.
• X WinCommander (XWC) by Maxim Baramov
• WinNC by R. Speets and C.Hamers
• WinNavigator by WnSoft Inc

OFMs used to be popular among OS/2 users. I have found almost a dozen of implementation of OFMs for OS/2 in Hobbes archive. Probably we should double this number to get a reasonable approximation of total number of implementations for OS/2. It's not surprising because OS/2 users represented the most advanced part of PC-users. Technically OS/2 was superior to both Windows 95 and Linux and has two unique, still unmatched, advantages:

• It was the second (after Amiga) mainstream OS that used the same scripting language (REXX) for both external (shell) and internal (macro, application level) scripting.
• OS/2 file systems had very interesting concept of file attributes -- extended attributes. Extended attributes like .SUBJECT, .COMMENT and .KEYPHRASES can be used for storing description for the file -- much cleaner implementation of descriptors than hacks like descript.ion  in 4DOS or treeinfo.

But unfortunately this nice OS is dead and we will discuss only one OS/2 implementation -- FC (BTW it has a very good Windows95/NT ports) in the third chapter of the book. Just because it also has Windows and Linux ports. It does not support REXX as a macro language.

Sometimes OFM-style managers are incorrectly called NC clones. The truth is that the latest incarnation of OFMs represented by FAR, Midnight Commander (MC) and Total Commander (as well as many other contemporary implementation) others are far from being clones and contain important original ideas. Moreover, from the historical point of view many new features in NC 4 and especially NC 5 were implemented in other OFMs at least a year before, so actually it was the attempt of Symantec to catch independent developers (that failed in NC4 but was pretty successful in NC5) that can be called cloning :-)

IMHO Symantec served as a graveyard for several very interesting programs and utility packages. Norton commander was one of the first such victim and Symantec lost interest in it soon after version 3.0 of NC was released. Or, more correctly, Symantec tried to close this product line after acquisition of Peter Norton Computing in 1991 (Norton Utilities v.6 that were released in 1991 had been the first product from Norton Computing that was copyrighted by Symantec). Anyway, with the introduction of Windows 3.0 the firm jumped into GUI bandwagon and never looked back. It realized that it made a huge mistake and that NC has its place in GUI environment only when it was too late. After 1993 independent developers were the only source of innovation in the OFM area.

Advantages of OFMs

Much like Johann Sebastian Bach's music OFMs simultaneously belong both to the previous century and to the next century. The DOS-style character based interface is more than 25 years old and is somewhat archaic. Some key assignments have no rational explanation from the point of view of a typical Windows user (but that deficiency can be easily cured by providing a key-mapping mechanism, see below).

At the same time OFMs offer a unique blend of simplicity and power. They provide a very efficient paradigm (a way of thinking about performing these operation - that's why the word paradigm appears in the title of this book) for operations on a large collections of file dispersed in a complex tree directory structures. Advanced users that start using OFMs seldom switch to any other file manager. There are a lot of users (including the author) with more that ten years of experience in one or several OFM implementations. This is a rare level of loyalty in the fast paced software world.

I see the following major advantages of OFMs:

1. A better file manipulation paradigm than implemented in other file manages including File Explorer and other "windows-style" GUI-based file managers.
2. Richer variety and more flexible semantics of file operations.
3. Productivity of power users.
4. Unique suitability to system administration tasks.
5. Portability.
6. "Small is beautiful".
7. Dynamic development.
8. "Form liberates".

Let's discuss them one by one.

A Better File-manipulation Paradigm

OFM idea of two absolutely symmetrical interchangeable panels (similar to the text editor with two text windows, actually OFMs have strong links with editors ) is not only more powerful model that asymmetrical model (the directory tree at the left, list of files to at the right) used in Windows-style GUI-based managers. It's also more natural. The tree in the left panel and the file list in the right with the possibility of drag and drop from one panel to the other permits only selection of files on the right panel, while OFM permit selection of the files in both panels and file operation can be performed simultaneously from left to the right and from right to the left panels.

Also command interface string at the bottom of two panels provides a kind of generalization of "drag and drop" -- the very thing that Windows users are craving for but this implementation is more flexible that "drag and drop" can ever be: MS Windows style "drag and drop" is convenient only for simple operations. For example if you need to supply a program with just one argument it's really convenient to drop file on the program icon on the desktop. But if you need to supply more complex string of parameters drag and drop simply does not work. GUI-based drag and drop is by nature a limited although simple and elegant interface. It's great for introducing simplicity and consistency to applications that perform a simple non-repetitive set of tasks. But it's not that impressive at handling huge, complicated, and unpredictable administrative operations that step outside the nice, neat boundaries of coping one or several files to other directory or dropping a file into application icon.

As Don  Gentner  and  Jakob Nielsen noted in their very interesting paper Anti-Mac Interface:

Using direct manipulation, users interact directly with objects in the interface [17]. The archetypal example is to move a file from one directory to another by opening the original folder and using the mouse pointer to drag the file icon to the destination folder. This procedure works well for simple actions with a small number of objects, but as the number of actions or objects increases, direct manipulation quickly becomes repetitive drudgery. The dark side of a direct manipulation interface is that you have to directly manipulate everything. Instead of an executive who gives high-level instructions, the user is reduced to an assembly line worker who must carry out the same task over and over.

Direct manipulation also means that users must always operate at the atomic level. They cannot group a related series of basic actions into one high-level action or use conditionals. Suppose we have a group of images and want to convert all of the PICT files into icons (see Figure 2). If the conversion requires several steps, this will be a very tedious process with direct manipulation, but a simple scripting language provides a natural means for specifying this task. Direct manipulation also limits the precision of our actions to the precision achieved with eye-hand-mouse coordination. Language and mathematics can be more precise ("Place the bottom of the triangle level with the middle of the circle") and more dynamic ("Maintain the height of this histogram bar at 37% of that of the bar to its left"). Finally, direct manipulation requires the user to be involved in every action, but sometimes the user may not know what to do....

At the same time the idea of assembling a command line from the program name and file name(s) in a special area (OFM command line) does work and is flexible enough to be useful both in command-line environment and GUI environment.

From this point of view I consider OFM operations Ctrl-Enter, Ctrl-[, Ctrl-] (or, better, using macros like %fn, %lp for the left panel path, %fn, %rp for the right panel path, etc. as in MC) to be a generalization of drag and drop. Again my assumption here is that drag and drop is just a special case that works well only in simple cases but deteriorates and quickly became a nuisance when you need to perform complex and/or repetitive manipulation on files.

Presence of explicit command line or more correctly command assembly line also provide possibility to add arbitrary strings to the argument list -- Achilles part of simple drag and drop where one needs to provide different icon for that purpose.

Richer variety and more flexible semantics of file operations

OFMs have richer variety and more flexible semantics of file operations that often permit performing tasks with fewer keystrokes and fewer mistakes. A simple example is a very common operation of moving file from the current directory to a subdirectory that exists in it. In OFM that can be done with the following sequence:

1. Select files to be moved/copied (not necessary for one file -- in this case positioning panel file cursor on this file is enough);
2. Invoke file tree with the F10 button
3. Select the target directory (not necessary if there only one directory or you want to move file(s) into the first directory in the list)
4. Press Enter

This sequence for a long time OFM user is performed automatically as a single operation and is blazingly fast, probably ten times faster than similar mouse-based operation (despite the fact that it is a perfectly suitable for mouse drag and drop example).

An advanced OFM users have some internal "patterns" for typical operations that he/she performs and can invoke those patterns each type the situation arise. Richness of semantics of file operations permits rather complex operations to be completed with a few keystrokes. For example to FTP selected files from the current directory to a known FTP server (that exists as a bookmark in a particular OFT, be it FAR or Total Commander) can be accomplished with just a half-dozen keystrokes. Any Unix sysadmin can appreciate this as ftping files is probably one of the most unpleasant operations in pure command line environment. Amazing power of OFM interface is most evident with the operations that on different "virtual file systems" (FTP is just one an example of such a filesystem, see below).

The OFM concept of multiple associations -- any extension in OFM (for example .txt) can be associated not with a single program, but with multiple programs. this is a more flexible approach then an approach used in Windows. Also the process of selection of group of files is more flexible and power of operations on groups is much bigger than in any known to be Windows Explorer-style manager.

At the same time OFM paradigm is flexible enough to successfully integrate useful concepts from other important families of file managers (Xtree and Windows-style) as well as ideas originated in WEB-browsers (directory favorites or bookmarks, back operation, etc.).

Now best OFMs (for example FAR) provide history support on the level that surpassed XTree implementations. And for the power users the history is a big productivity enhancement tool -- I would like to say uniquely powerful and useful tool.

Some very advanced concept, for example the concept of bookmarks were present in rudimentary, provincial form in OFMs from the beginning (traditionally user menu items were often used as bookmarks for directories in a file system) and several OFM implementations tried to develop it further (directory favorite lists), but recently WEB-browser semantics provide a unified framework for implementing this feature and it fits OFM paradigm quite naturally.

Productivity of power users

One of the most distinctive advantages of OFMs is that the productivity of the power users is really amazing, especially in the command-line environment. To the uninitiated it often looks like a magic -- the speed with which an advanced user can perform complex file operations. It looks much like playing piano. Advanced user probably have "motor maps" for typical operations that are executed on subconscious level much like a good piano player can instantly recognized specific accords in music notation.

Command line work well not only for file operations, but for a typical "administration mix" in windows and Unix environments. It is not sexy, but it work better that GUI based application is probably 80% of typical Unix administrator jobs. It also much more efficient than GUI for any remote applications and troubleshooting.

Established motor skills of power OFM users means that different key assignments kill an "deviant' OFM implementation almost instantly due to inability of users to apply already existing motor skills. Implementation can be better, but it just feels foreign like piano with different number of keys or without black keys would feel for a decent piano player. I still remember pain of mastering MC with it (obscure for me) Unix-culture induced key assignments -- I cursed designers a lot for their apparent inability to understand that some of the MC users would have established Dos-based OFM motor skills. Not everybody even in Unix world love Vi or Emacs ;-). Even today I hate to press Ctrl-S (or Alt-S) to invoke fast search on the MC panel.

Availability of virtual file systems (VFS) make some complex operations much simpler. Generally it seems that for complex file operations the OFM paradigm of symmetrical interchangeable panels with emphases on keyboard is more productive then Windows-style GUI interface with asymmetrical windows and strong emphases on mouse based operations (drag and drop). Here OFMs traditionally were great with search panel available from early versions (although only recently search panel became close to regular panels in best OFM implementations). Neat trick that power users of old versions of OFMs (that does not support Xtree VFS -- flat directory tree representation) used to use was to search files with mask *.* in a subtree staring from the current directory. That produced simulated Xtree view -- all files in the subtree that you can (in a limited way) manipulate. Now in best OFMs functionality of a search panel is very similar to the functionality of regular panels with the ability to view files, edit files, manipulate files, etc. In this sense Xtree VFS and search panel merged in functionality, but still I am waiting for Xtree level implementation of this idea.

The idea of Alt-F10 as a instant third panel with the tree view of the current disk (or mountable filesystem) is a very powerful and useful solution for a lot of typical file manipulation problems. The key word here is that it should be instant. Any scanning as in MC kill the idea. For example I almost never use tree representation of the second panel to navigate the tree, I use it for mainly for quick browsing. To navigate the tree I automatically invoke tree view of the current panel with Alt-F10 and navigate to the necessary directory on it.

Dynamic toolbar provides for user instant picture of available functions. OFM are very convenient for using with script languages and command line utilities -- user menu, extension menu and execution menu provide a very powerful integrating mechanisms for shell scripts and command line utilities.

Unique suitability to system administration tasks

OFMs are a very powerful tool for system administrators, and using them can considerably cut time needed to perform usual system administration tasks. I think that OFMs provide a cure for Unix-style command line perversions while preserving command line flexibility and richness.

As humans tend to understand filesystems better with graphical clues, OFMs are very useful for troubleshooting.

Many command line implementation of OFMs (Volkov Commander is a famous example) are small programs that can be used from the floppy. They are immensely useful in troubleshooting.

I believe that an OFM should be a part of the toolbox of any decent system administrator. Sysops of FIDO BBS were probably the most active OFM adopters and some features in OFMs are generalizations of BBS maintenance experience (4DOS file description support is one such feature). Most OFMs (FAR, NC5, Norton Commander for Windows, Windows commander, etc.) provide additional system administration tools for NetWare (drive mapping, etc.). MC provides additional UNIX management tools and good integration with Unix shells.

Portability

With its simple character-based interface OFM is the only portable file manager. OFMs managed to migrate to almost any other OS (including palmtops OSes, all flavors of UNIX, OS/2, Amiga and even IBM mainframe VM/CMS operation system). It can be implemented on black and white screen with limited number of shades of gray or even no shades at all. OFM is probably one of two types of file managers (the second is Xtree and its derivatives) with implementations on all five (or more, it depends on how you count them ;-) major Microsoft operating systems (DOS 2.0-6.22, Windows 3.xx, Windows CE, Windows 9x and Windows NT).

What is even more important is that OFMs provide unique possibility of having similar (although never identical) sets of skills dealing with command line and GUI. A very common observation about power Unix users is that they are usually command line jockeys and underutilized GUI interface. Often even if power Unix user works in GUI environment half of open windows are just terminal emulators. And sadly enough it's true because of long training in plain vanilla command line interface produce skills that although provide very powerful problem solving capabilities, are not directly transferable to the GUI environment.

"Small is beautiful"

OFMs are rather small programs that efficiently utilize system resources and can be developed by a single author. Now famous Volkov Commander 4.01 is an extreme case - it's a 64K program that was blazingly fast even on the most primitive and underpowered PCs of DOS era. At the same time the functionality of this 64K program beats the functionality of many Windows file managers that have a size of more than a hundred megabytes.

Dynamic development

OFM field is not static with well known players. It is a rapidly developing culture with a lot of innovation from newcomers. For example FAR -- current leader among command line OFM implementations -- is a recent introduction to the OFM family with v.1.0 released in 1996. Competition in the field of OFMs is really strong with several dozen talented programmers working on their products. The functionality of the latest generation of OFMs ("made in 1997" OFMs) is vastly superior to their predecessors made in 1993 or 1990. Also important are attempts to understand OFMs from the academic point of view (this book is probably just a humble beginning of the trend; more should follow).

"Form liberates"

The character based interface of command line OFMs is easy to implement, so most of the developer efforts can be spend of the semantic aspects of the file manager and polishing the set of operations instead of a series of cosmetic upgrades of the face ;-). That is probably also true if you are using TCL/Tk for implementation of a GUI-based OFM, but still it take more effort to implement GUI even in this much more comfortable environment.

It's not accidental that the revolutionary concept of plug-ins was first implemented in FAR -- a command line text-based OFM. I essentially do not know any other file manager that implement this very powerful and elegant concept.

Here is one interesting comment from LinuxToday discussion The Role of the Modern GUI

zerblat - Subject: Keep it simple, stupid! ( Jul 5, 2000, 19:39:12 )

Oh no, not another nostalgic article about old text based DOS apps! For the record, I do spend most of my time in the console, since a have a rather old computer, and there are lots of good console apps for Linux. (Who needs a wordprocessor when we have TeX?) However, it's important to realize that there is no fundamental difference between character based interfaces and graphical interfaces. The only real differences are WYSIWYG and displaying graphics. OTOH there's nothing you can't do with a GUI that you can do in textmode. But you still have the same principles -- buttons, text entry boxes, chechboxes, windows, menus etc. The difference is the bandwidth of the interface. A typical console can display 80x25 characters; how many characters can you display on a 1600x1200 X display? In GUIs you can clutter the screen with enormous amounts of icons, buttons, toolbars and whatever; character based apps can only display a limited amount of information at a time, so the interface can't be as complex. It's the forced simplicity -- the limitations -- of the text mode, that makes many textmode interfaces "better" than GUIs. Also, you can't expect console users to have a mouse, so the interface has to be completely keyboard based, the mouse is just a complement (the way it should be IMHO). So, the old console doesn't really have any inherent advantages over the GUI (except when you on an old box or telnetting). But, many GUI apps could learn a thing or two from many text apps -- keep the interface simple and uncluttered, and only use the mouse as a complement to the keyboard. Of course, there are also lots of examples of bad character interfaces. . .

Milestones of the OFM paradigm.

OFM paradigm is now more then 25 years old. BTW NC 1.0 stills works in Windows XP and there are still users of this version; this is an amazing, probably unsurpassed in Windows world, longevity of a program ;-). Here is the letter that I got in October 2005:

Norton Commander 1.0

Hi,

I'm still using Norton Commander version 1.00 (1986) in Windows 98SE,
even in Windows 2000 Professional and Windows XP.

I prefer it's small size and fast, and I can write with it small batch programs.

Bye

Alvaro Alonso
From: Bogota, Colombia (South America)

During this time it has substantially changed and now support much richer set of operations and functionality. Some important events in OFMs development are shown in the Table 1:

Table 1

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater�s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March, 12, 2019