Less is More: A rich functionality behind Spartan interface of Orthodox File Managers

Introduction to Orthodox File Managers (OFM)

Dr Nikolai Bezroukov

Version 1.6, November, 2012

Copyright 2012, Dr. Nikolai Bezroukov. This is a copyrighted unpublished work. All rights reserved.

Note: Version 1.5 of this paper was published in Softpanorama Bulletin Vol.24, No.3 (2012)

• Introduction
• The history of the term
• Notion of Orthodox interface
• Members of the OFM family and their properties
• Comparison Table
• Understanding OFMs as sysadmin IDE
• Ten OFM Commandments
• Recommendations for Users

• Some recommendations for Orthodox file managers designers

• Conclusions

Abstract

The Orthodox File Managers (OFMs) that are also known as "Commanders" are remote descendants of  Norton Commander (NC) written by John Socha and first released in 1986 for MS DOS. Despite Spartan interface (or, more correctly, due to it) Orthodox file managers provide an extremely rich functionality, unsurpassed by any other type of file managers. Including a unique way of shell and file manager integration via user menu with a set of macrovariables as well as shell terminal window, making them natural sysadmin IDE. Due to unique blend of power, flexibility and portability they became the tool of choice for system administrators, especially in xUSSR region, Eastern Europe, Germany and Scandinavian countries. Those regions were place of birth of the most impressive OFM implementations such as Far, Total Commander, deco, Volkov Commander, Dos Navigator, Altap Salamander and many others.

There are three fundamental properties of Orthodox file managers:

1. Conservative (as in "far from being fancy"),  very stable (25 years without major changes) interface with two symmetrical windows (called panels, with trademark white on blue letters, by default) that hides behind Spartan interface very rich functionality. It really teaches us that "less is more"
2. One "terminal style" window that initially is minimized to a single line at the bottom of panels, but can be expanded to full screen, half-screen or any number of lines. The user can work in this window like with regular console screen.
3. Additional way of integration with the underling OS shell via so called User menu and extension menu using the same set of macro variables that are available for command line, which is also used in the built-in editor, providing an opportunity to pipe results of the shell script execution to the place after the cursor or pipe a selected block as input of some script.

At the same time they represent just one instance of a larger category that can be called Orthodox interface. This category includes editors such as vi and THE (orthodox editors), windows multiplexers (GNU screen), windows managers (such as ratpoison) and probably some other that I just don't yet discovered. I am still working on refining this notion but as a set of raw ideas it includes:

1. Distinct command set layer with commands that can be entered from the command line and reflected in GUI interface. In this sense vi is a reference implementation and OFM inspired by vi have some interesting, distinct from traditional line of OFM ideas implemented. See ranger and vifm.
2. Tiled, nonoverlapping windows with minimum decorations
3. Stress on availability of all commands via keyboard, not only via mouse clicks, although mouse can be productively used and is used in such interface.
4. Ability to redirect output of commands executed in one window to other windows and processes.
5. Usage of GUI elements to generate commands on command line (macrovariables and such commands as Ctrl-Enter, Ctrl-[ and Ctrl-] in OFM. )
6. Accent of extensibility and programmability (with shell and/or scripting languages) instead of eye candy.
   
    

Introduction

The Orthodox File Managers (OFMs) also known as "Commanders" are remote descendants of  Norton Commander (NC) written by John Socha. The latter was first released in 1986 for MS DOS but later replicated in multiple free, shareware and open source clones, which, essentially, created the "brand". 

Orthodox file managers provide a unique way of shell and file manager integration making them a natural sysadmin IDE. Due to power, flexibility and portability they became the tool of choice for many system administrators both on Unix and Windows, especially in xUSSR region, Eastern Europe, Germany and Scandinavian countries. Those regions were place of birth of the most impressive OFM implementations such as Far, Total Commander, deco, Volkov Commander, Dos Navigator,   Altap Salamander and many others.

The word "Orthodox" comes from Greek orthos ("right", "true", "straight") + doxa ("opinion" or "belief", related to dokein, "to think"). And OFMs are really in my humble opinion  "true way of thinking" about complex file management operations. As a former editor of Softpanorama bulletin, a ezine which was published on floppies from 1989 till 2006, I was amazed by tremendous enhancement of my productivity they provided.

It goes without saying that publishing of it would be impossible, if I did not learn how to use Norton Commander 2.0 in early 1989 (at the end of the year I switched to NC 3.0 and in 1992 to Volkov Commander).  Provided by user menu simple extensibility proved for me to be an indispensable tool. Later FAR added the concert of plug-ins which make extensibility of this type of managers even more impressive and then implemented LUA extension -- adding a scripting language programmability which is very natural for this  type of applications, as significant percentage of end users are system administrators, who by definition, would know programming at least on scripting languages level (there is an MC fork that also implement LUA extensibility).  Even without writing your own plug-in you can configure a set of custom scripts that provides more critical for you functions and  enhances your productivity. Some custom plug-in are also very useful.  For example, for me such an indispensable thing proved to be WinSCP plug-in.

While many sysadmin/webmaster tasks can be accomplished in many different ways, I think high level of mastery of OFM provides one of the best approaches, as it stimulated "macro thinking": thinking in bigger chunks similar to the process of writing a script in Unix shell. but it's more then that it is also similar to playing on such instrument as piano, when you learn some standard tunes or "musical phases" and then can repeat then almost subconsciously. Some users who use those file managers for a decade or more have pretty rich repertoire, and sometimes can amaze friends and accidental observer performing then on the keyboard with amazing for untrained observer speed and precision.

In other words OFM functionality tends to organizes your thinking (and kinesthetic memory) along the notion of complex file operation which serve as a chunks or statements of some abstract language designed to simplify typical sysadmin tasks, especially connected with operations of one or several files. As such it really represents "true way of thinking".  That's why I called by eBook about those file managers The Orthodox File Manager(OFM) Paradigm.  

OFMs provide a unique integration of three components critical for sysadmin IDE -- file manager, file viewer and file editor. Advanced OFMs has extensibility via two major mechanisms:

• user menu with a set of script typically written in shell (but shell can serve as just envelope for passing "internal" variables into scripts written in other languages)
• Plugins. For more advanced OFM (FAR, MC) they can be written in a scripting language (typically LUA)

The most promising from the point of view of extensibility are OFMs written in Python or other scripting language, but there are very few such OFMs. See  Scripting Language based OFMs

The history of the term

I introduced the term "orthodox file managers" in 1996 (see OFM Bulletin 1998 ) because this type of file managers has an interplay of three features:

• They are remnants of long gone world of text terminals. Like Amish's dress they look like belonging to a different epoch.
• They belong to the rare category of  "command line enabled" GUI tools (Which also include vi, Xedit, THE editor, Gnu screen and several other programs) and as such implicitly promote the use of shell. Knowledge of shell (like OFMs themselves) went out of fashion with the demise of MS DOS, much like Orthodox Christianity went out of fashion with the demise of Byzantium ;-). Now they found new home in Unix, were shell programming traditions still run strong. With the ability to overlay panels and shell terminal window they can be considered as an interesting and innovative extension of shell -- a kind of graphic shell, if you wish. To a certain extent we can talk about "Orthodox GUI interface" as a third, distinct type of GUI interface, different from either Apple-style GUI interface or Windows-style GUI interface (which actually pretty much converged).

• They have found the second home and became tremendously popular (dominant in DOS days) in the USSR and Eastern European countries with the population at least formally belonging to Eastern Orthodox Church with its unique polyphonic musical tradition (Basso profondo from Russia,  Do not reject me in the time of old age, Orthodox music and Basso Profundo Beautiful Russia in Winter,  Let my prayer come true,    Gabriel Appeared, Lord, now lettest thou thy servant depart in peace, Glandsome Light,  Great Litany).  This is some at least superficial similarity in how they with just human voice create magnificent masterpieces to the way keyboard is also pushed to the extreme in OFMs (although mouse can and should be used)

• They emphasize computer minimalism philosophy. In a way orthodox file managers represent a different way of thinking (paradigm) about file operations, a remnant of DOS culture that emphasized the value of keyboard, simple text interface and simplicity in general. They also have an implicit appeal as simple, minimal tools as opposite to baroque, complex tool typical for modern Windows and Linux environments. With its adherence to command line and character-based  interface they represent a trend that is often called computing minimalism. Modern "click-drag-click" GUI interface designers view such approach to interface as antiquated and worthless, but ability to mix and match keyboard with mouse operations carries a rich and valuable cultural tradition from glorious, but long forgotten DOS days of personal computers. As old PC users remember the original versions of IBM PCs did not have mouse, it was introduced only with IBM PS/2 series in 1987. Actually key assignments for OFMs are difficult to understand without knowing about 83 keys XT keyboard with 10 F-keys to the left in two rows F1-F2, F3-F4 (View/Edit in OFM), F5-F6(Copy/Move in OFM), F7-F8(Make directory/Delete in OFM), and F9-F10), keyboards which disappeared around 1994-1996 (recently they were revived in a new form of gaming keyboards which represent direct interest to OFM users).  So from 1987 DOS users tried to combine the best features of both interfaces.  Symmetrical two panels with hidden command window interface also speaks volumes about the value of simplicity and because such software can be replicated independently and you do not have a vendor lock. As such, simple flexible interfaces like used ion OFMs can survive for many decades, producing enormous benefits for the long-term users. Ability to use the same interface for 20 years or more produces level of  motor skills when operations became almost subconscious and user can think about file management problems is a larger "chunks" of OFM operations  like (make_directory-select files-move chunk, or compare_directories-move_newer chunk). This way of thinking gradually evolves into the second nature of the users and a way of thinking about all file operations (paradigm).  

  Note: After demise of XP some keyboard manufactures tried to incorporate XT keyboard F-keys into AT keyboard layout but none was particular successful (the most long lasting and popular was probably Gateway AnyKey). Some programmable keyboards contain XT-style two columns of programmable keys on the left side of keyboard (for example, Logitech G110 (now discontinued, look for G510s). Those keys  can be programmed into "classic" OFM configuration (see Programmable Keyboards) making OFM usage more enjoyable and operations slightly faster.

While not perfect, the term Orthodox File Managers is much more precise and definitive then alternatives. There are actually three main alternatives: 

• "Norton commander clones". This one is clearly a bad idea as modern OFMs are far more then that. Also "Norton Commander clone" or "Norton-style file manager" terms has element of advertising in them. As Symantec abandoned the product in the most inappropriate fashion (without releasing code of old versions, or making it freeware) I strongly object to those type of terms.  Moreover, historically starting from NC3.0 "clones" became much more advanced then the original and it was Symantec that clone ideas from other implementations, not the other way around. So, in a way, NC 4.0 and 5.0 were clones, not vise versa.  The truth is that starting from Volkov Commander (1992) and DN, Symantec was in deep trouble as for original ideas. Volkov Commander essentially smashed the value of Symantec brand into tiny peaces.  The initiative was on the other side: 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 it is fair to say that it was the attempt of Symantec to play catch up with independent developers (that failed in NC4 but was pretty successful in NC5) that can be called cloning :-). When Symantec betrayed the product and ideas behind OFMs, it was independent developers that keep it afloat.   Just compare functionality on NC 5.5 with Orthodox File Managers Standard 1999(OFM1999) - minimal OFM requirements  and The Orthodox File Managers Standard 2004 (OFM2004) Advanced OFM requirements )  which reflect the progress of leading OFM implementations for the last 15 years.
• Commanders. This one is better (similar related word is Navigators), but unfortunately it widely used for unrelated programs. So it brings more confusion then clarity. The term "Commander" is widely used in games, NFS and Samba mounting helpers, security tools (Checkpoint commander), sound card controllers, image processing programs, etc).  BTW the Norton Commander is also the name of a motorcycle made by British manufacturer Norton Motors and if you search Google for the word "Commander" that will be 90% of what you'll get. The other problem is that file managers completely unrelated to Norton Commander, especially those that resemble Windows File Explorer often call themselves Commanders. 
• 2-pane or two panel managers is a wrong term as it does not reflects the critical importance of the command line  window in the interface, which in the default mode is minimized to a single line.  This third, initially minimized window that behaves as it is hidden behind two panels is the principal, distinguishing feature of this type of managers. Also this term does not reflect a unique troika of command line integration features, extension menu, and user menu based integration. The latter is probably the most important and existence of so called "user menu" and a related a set of macro variables (the current file, path to the current panel, path to the passive panel, etc) allow to extent this type of managers in a unique fashion. It also hides close analogies of OFMs with such programs as XEDIT, The Hessling Editor, vi (the category which I call Orthodox editors) as well as GNU screen and minimalist windows managers for X11 like Ratpoison. So in a way this is a culture that emphasize the value of keyboard.  All those programs has nothing to do with two panel concept but they all utilize command line interface, although is different ways and attract similar type of power users -- first of all system administrators.

You can read more about pro-and-contra those alternative terms in Wikipedia discussion, which among other thing contains some very emotional philippics against the term "orthodox file manager" and judge the level of participants on the either side of the debate yourselves. The funniest argument, that probably deserve to be published by Onion were along the lines:

 Waah, if those are orthodox then all others are unorthodox and that means infidel. So they called my favorite file manager infidel ! Bastards.  Damn the author and the term ;-). 

With one particularly nasty Wikipedia user was going as far as claiming that the term was inserted by me at all pages with them that can be found on the WEB...

Of course any term has drawback, but this one still the term reflects my convictions that interface provided by OFMs reflects "less in more" approach and its Spartan interface somewhat reflect ideas asceticism propagated (but not always followed) by Orthodox Priests. If also reflects judging of this interface as a "right, but now viewed as archaic" pretty well and I am sticking to it :-).

Orthodox file managers is also appropriate name in a sense that they stress the value of ability of  working with command line  using the command set instead of click & drag type of interface that is typical for modern GUI programs. OFMs also managed to preserve "look and  feel" of the original program which is now more then 25 years old (this is amazing case of interface longevity, if you think about it). This unique, recognizable two symmetrical panel (often with white letters on blue background) interface is a hallmark of the genre with its ability to shrink and manipulate visibility of left and right panel windows as well as expand command window (preferably gradually but at least to half-screen and full-screen) despite the fact that this interface is quite different from the established by Apple and Microsoft standard for those programs. In this sense we can call Microsoft type of GUI interface with its excessive attention to GUI details "a catholic interface" ;-).

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.
    

Members of the OFM family and their properties

Members of this family of file managers that are represented by such popular file managers as FAR, FC, Total Commander and WinSCP on Windows as well as MC (Midnight Commander) in Unix. Less popular names include probably a dozens of implementations (Demos Commander,  Krusader  , EmelFM2, GNU Commander, GNOME Commander in Linux, FreeCommander, Altap Salamander,  Necromancer's DOS Navigator on Windows,  see CategoryOrthodox file managers in Wikipedia). All of them use simple yet very powerful paradigm of three windows: two symmetrical panels and command window (shell terminal window) hidden behind them with only the last line of this window (command line) visible. There are three fundamental properties of Orthodox file managers:

1. Conservative (as in "far from being fancy"),  very stable (25 years without major changes), very flexible interface with two symmetrical windows (called panels, with default trademark white on blue letters). It teaches us that less is more. By default panels contain listings of files in two (not necessary different -- they can provide two different views of the same directory, for example, sorted by time and by name) directories. One panel is "active" (it has cursor in it), the other is "passive". Tab changes active panel to passive and makes other panel active. All manipulations are performed from active panel with possible target of passive panel directory (in case of copy operations). In advanced OFM along with vertical split panels can be displayed with horizontally which is useful for Unix as permits displaying both attributes of the files and its ownership.  Key variables that describe status of those two panels (often called macrovariables), should be exported to the environment and available as a keyboard shortcuts (for example Ctrl-Enter, Ctrl-[ and Ctrl-] in FAR) for inserting into command line. In a sense OFM is for users who learned this interface, found it highly usable and don't care about with "innovation" like drag and drop and eye candy unless they really increase productivity. Remember that an important part of KISS principle is famous "If it aren't broke, don't fix it"...  Every time you hear the screams of millions of users crying because of another "innovation" from MS or Apple like happened in change of interface from Office 2003 to Office 2007, remember that simple reliable tools like OFM give people what they want and what they already learned and get used to, not an "Even-Newer-Paradigm" each three to five years. The classic "orthodox" lesson that OFM teach us that "If you've got time on your hands, and are looking for something to do, please spend it on improving functionality and flexibility of the application, not the visual candy. "  The UI does not need anything "new", nor do the users want anything new or unfamiliar. It's more than enough hassle to keep up with "innovations" in the OS space... please don't make us learn new tricks for the file managers, which are good enough... As we saw in some popular GUI programs the lion share of "innovations" in new releases is confined to endless variations of GUI interface. Not so much adding functionality, as adding confusion. And the pace is such that sometimes users just get used to new interface and, voila it got updated. The impression is that aging brass imitates "creativity" by meeting some stupid formal parameters in yet another spreadsheet staffed in the endless maze of bureaucratic perversions. Imitates without a soul. And after brass creates "grand plan for innovation" a lower level boss pushes plan for interface "innovations" to worker bees. Who knowing the situation all too well and understand that  "resistance is futile" say, "OK, boss. As you wish !"  Let's shuffle the menu from vertical to horizontal and change location and shape of the buttons. Done deal! Everybody is now happy. And in order to meet the deadline, let's do not fix existing bugs. Because real quality control is gone as the key criteria of their work became meeting the release date too. So both management, software development and quality control are now just imitations of "real thing". The release date hangs over their heads like Damocles sword. And only after the release, the real attempts to fix bugs begin.  Until a new "innovation cycle" starts....

   You got the idea of such an "innovation process". And described perversion and waste of talent and resources for meaningless changes of eye candy under the name of innovation  happens with GUI based applications way too often, so often that the description above does not looks so much as a caricature. I think in this respect US software developers finally reached the level on which industrial projects were completed in the USSR just before its dissolution! Which suggests not only widespread rot at the top, but something deeper and more menacing...

   With OFM the situation is different. Interface is primitive and its structure was fixed 26 years ago. Users learned it long ago and expect it to stay the same; they do not take "innovations" very friendly to say the least. Moreover, there is one stupid guy named Bezroukov who put an effort to document it and published widely ignored but still available standard. And now if somebody deviates from it too much,  he/she might be shamed by some too curious user who read OFM1999 or old hand who used FAR or Norton Commander 3.0, who expected that  that this feature should be done not this way, but that way ;-). Which creates implicit pressure to keep the interface compatible with good old Norton Commander and channel your creative energy into something more valuable then deciding which key combination should be designated for "copy" and which for "move" :-). Or how many panels your file manager should have. Or how shell terminal window should behave.
    

2. Integration with shell via  "shell terminal style" window, which initially is minimized to a single line at the bottom of panels but can be expanded to full screen, half-screen or any number of lines like in GNU screen with the ability to use special set of macrovariables (current file, path to the active panel, path to the passive panel, etc). Classic Norton Commander provided two preselected sizes of "shell terminal" window: half screen and full screen; FAR introduced the ability to expand command line windows by any number of lines necessary.  At least the ability hide panel and work with full screen command windows should be present. Unfortunately this feature is very poorly understood and as such is very poorly implemented (paradoxically it is implemented especially bad in Unix OFMs). At the same time this is what makes OFM close to visual shell -- as you can use environment variables and shortcuts related to panels in command line. This is a really unique feature of OFM.  Unfortunately in Midnight Commander, the most popular Unix OFM, the implementation was completely screwed until version 4.8   ( and it is have bugs in version 4.8.6 as well as complete absence of important "half-screen" shell terminal windows visibility (only one line or full screen capabilities are present)). So the leading Unix OFM fared worse the Windows-based FAR in command window support ;-). The capability to extend the third windows above single line is completely absent from Total Commander -- probably the best GUI-based OFM for Windows. I think this is a serious flaw. So I would like to stress it again, that the key, principal feature of orthodox file managers is usually very badly implemented with the exception of the original Norton Commander and FAR. 

   An additional twist of this capability is the ability to paste macrovariables (current file, path to left and right panel, list of selected files, etc) not only via putting the names of macrovariables in your input string, but also by using keyboard shortcuts such as Ctrl-F (current file), Ctrl-[ (path to left panel), Ctrl-] (path to right panel). This feature introduced in Volkov Commander simplifies many operations in comparison with both die hard command line Unix users on one hand and CDD (click-drag-drop) addicted  type of Windows users on the other.  I always admired the persistence with which Windows users can repeat the same operation using strictly mouse "drag and drop" four dozen times, for example moving 50 files to 10 different directories one by one, when in OFM it takes just slightly more then a dozen of keystrokes :-).  As well as Unix command line users who type command ls probably several hundred times a day each day (the ability to suppress ls command in bash history exists not without a reason) and still feel great and don't even suspect that there is a better way ;-)

   This "visual shell" memo is one of the most powerful ideas within OFM paradigm, but unfortunately "the religion became corrupted" as it often happens. Only FAR and Midnight commander (starting from version 4.8) implement this idea correctly, but with different strong points of the implementation:

   • Midnight Commander 4.8 implements commands window better than FAR in a sense it is a real "first class citizen" shell terminal window in Linux. For example,  you can source your own profile with custom prompt and it will be reflected in the shell terminal window. History is available with arrow keys, Ctrl-R works like it should. Generally you can work with it as with regular shell terminal. It would be great if Midnight Commander implemented the possibility of shrinking of the panels to  "half-screen" mode but may be I am asking too much.  Its already has a huge codebase and developer resources are really scarce...
   • FAR shell windows has different properties then Windows command line (which is extremely primitive anyway), but it implements an important possibility of shrinking panels to half size of more providing visual clues of executed commands on the file system along with output of those commends in the bottom part of the screen.  Still, for example, loss of scrolling history which is implemented in regular Windows shell window is a serious drawback.

   I would like to stress it again that such a popular Windows OFM implementation as Total Commander is completely defective in this respect: the third command line allow only a single command to be executed and output is not visible other that (if this is command affects file in the panel) with the feedback via changes in listed in panels files.
    

3. Extensibility due to integration of small scripts via so called User menu and extension menu using the same set of macro variables that are available for command line. In addition the same user menu and macro variables can be made available in the built-in editor. This way "user menu" provide a user with he capability to write his own simple extensions some of which can be quite useful. Here is an example taken from Midnight Commander User menu (which has a unique feature that it is dynamic and only those items of the menu that are applicable to the current file type and presence/absence of selected files are shown to the user): 

   = t r
   + ! t 
   y       Gzip or unzip current file
           unset DECOMP
   	case %f in
   	    *.gz) DECOMP=-d;;
   	    *.[zZ]) DECOMP=-d;;
   	esac
           gzip $DECOMP -v %f
   
   + t t
   Y       Gzip or gunzip tagged files
           for i in %t
           do
             unset DECOMP
   	  case "$i" in
   	    *.gz) DECOMP=-d;;
   	    *.[zZ]) DECOMP=-d;;
   	  esac
             gzip $DECOMP -v "$i"
           done
   
   
   + f \.tar.gz$ | f \.tgz$ | f \.tpz$ | f \.tar.Z$ | f \.tar.z$ | f \.tar.bz2$ | f \.tar.F$ & t r & ! t t
   z       Extract compressed tar file to subdirectory
   	unset D
   	set gzip -cd
   	case %f in
   	  *.tar.gz) D="`basename %f .tar.gz`";;
   	  *.tgz)    D="`basename %f .tgz`";;
   	  *.tpz)    D="`basename %f .tpz`";;
   	  *.tar.Z)  D="`basename %f .tar.Z`";;
   	  *.tar.z)  D="`basename %f .tar.z`";;
   	  *.tar.bz2) D="`basename %f .tar.bz2`"; set bunzip2 -c ;;
   	  *.tar.F) D="`basename %f .tar.F`"; set freeze -dc;
   	esac
   	mkdir "$D"; cd "$D" && ("$1" "$2" ../%f | tar xvf -)

For Linux/Unix users the simplest way to understand Orthodox file manager interface is to view it as a specialized implementation of GNU screen  that contains three predefined windows: two symmetrical panels side by site at the top and a regular command line window (by default minimized to a single line) at the bottom  The unique feature is that operation in one window (command line window) cause changes in other two windows (panels). This feature actually can  be implemented in screen by running two programs in panels that read two files in, say /tmp directory with location of current (active -- always shows the current directory) and passive (say previous directory) and then update content of their window.

Paradoxically leading Windows implementation (FAR) has richer interface with shell then leading Unix version -- Midnight Commander  (partially because of design flaws in Midnight commander where shell interface is implemented as a hack). There are also many GUI version of orthodox file managers that implement mainly file handling capabilities but not "visual shell" capabilities. The most prominent example is Total commander which in 2007 became fifteen years old implementation. 

There are numerous advantages of modern  Orthodox File Managers, which refines the functionality of  the original Norton Commander for DOS and incorporated into the same interface more then 20 years of development by many talented programmers including John Socha, Vsevolod Volkov, Eugene Roshal (of RAR fame) and Christian Ghisler (Total Commander).  Three main advantages are:

• Close integration with shell. That is reflected the ability to perform all operations using just  keyboard as well as in such features as extensions menu and user menu both of which allow usage of parameterless macros representing various elements displayed on the panels, bridging the gap between command line and GUI worlds in a very flexible and unique way. Hierarchical context dependent (MC) user menu is also a unique and pretty powerful scheme of invocation of scripts and programs, more powerful then GUI icons as invocation can incorporate context elements from both panels, such as active directory, passive directory, current file, selected files, etc.
• Portability.  OFM are probably the most portable type of  file managers in existence as it is one of the few that can work OK without mouse or similar pointing device. Implementations exist for any major OS including Windows CE and most smartphones; they proved to be pretty usable on Blackberry which is a popular type of corporate smartphones) See, for example, Total Commander CE/Pocket 2.51. As interface is pretty Spartan implementers can concentrate on providing advance functionality instead of eyes candy. 
• Availability of public standards.  Two Public standards  are available (OFM1999 and OFM2004), one in in development stage(OFM2012). Existence of standards ensure that OFMs are and will continue to remain one of the few types of managers where skills you get twenty years ago are still mostly usable on any more modern implementation. This is unique situation as interface usually changes pretty quickly, often in less then a decade.  Compare for example this with the evolution of Windows managers were key features of interlace are somewhat different between Windows 4.1, NT 4.0, Windows 2000, XP, Windows 7 and Window 8 Metro interface. Or Office 2003 and Office 2007 (to be fair Office 2003 interface existed for a decade or so).  And Microsoft is a company which historically proved to be very good in preserving compatibility.

All OFMs have a Spartan interface with the main window which is divided into three sub-windows. Two of them are called "panels" that are identical in structure (but can have different sizes and/or be hidden), and are usually positioned side by side at the top of the screen (in Unix positioning one on top of the other is more common as there are additional attributes to display with files). The third  screen-wide window contains an instance of the shell and usually is minimized to one line but can be expanded either gradually, like by line (like in FAR) and/or is large increments (half screen and full screen  as in classic Norton Commander implementation). You should view this command line as a almost minimized (to a single line) command window. Or, if you wish, a separate telnet session to localhost. In case panels are hidden (with hotkey Ctrl-O ) command window should provide full functionality of the OS shell window including history of commands, command completion and other niceties.

In essence OFMs can be viewed as a special type of  windows manager (similar to GNU screen) with functions of two upper windows (panels) largely fixed. But the important feature of OFMs is that panels are implicitly  connected  to the operations performed in command window in several ways:

• One of the panels always contain the current directory and automatically reflects changes in it.

• It is possible to copy certain elements of the left or right panel to the command like using special key combination and special macro variables. Typical examples are the current path, path to the left panel, path to the right panel, the list of names of selected files.
• There are also set of operation for exchange of information between panels (always from active to passive)
• Panel also can contain editor window of viewer for a particular file. 
• Panels are shrinkable and can expose hidden behind them terminal window, while normally only the last line of this window (command line) is visible. The latter permits viewing the results of execution the shell command entered on the command line (e.g. via Ctrl-O shortcut in Norton Commander);
• The ability of user to extend functionality of the manager via so called User menu or Start menu and extensions menu. The ability to create their own file associations and scripts that are invoked for certain file types ( it was Norton Commander who introduced the concept of file associations that is now used in all file managers).

Surprisingly, this Spartan interface proved to be long lasting feature of OFMs.  There were attempts to create the OFM manager with four panels. There were attempts to use tree view as the right panel (similar to Windows Explorer) and most OFM has the ability to replace left panel with tree view. But I personally and many advanced users whom I know never learned to use this productively and prefer classic symmetrical panel view with two directories.  Strangely enough this two symmetrical panel with two directories remain the most productive for a very wide spectrum of real life file operations that are used by sysadmins and advanced users.  When I need tree view for quick navigation I usually use separate view available vie Alt-F10 (find folder).   Probably there are some structures in brain that provide higher productivity with the symmetrical two panels  interface vs. various often more sophisticated asymmetrical variants.  Moreover after you achieve proficiency with it, it's rather difficult to switch to any other: all of them look inferior even if in reality they are more expressive  for some operations (like the Windows File Explorer asymmetric interface with tree on the left side or XTree interface, which provides very good capabilities of coping/moving files from left panel to the arbitrary place in the directory tree). There is some kind of  implicit "lock in": after several years of usage you start thinking about file movements and directories restructurings in terms of OFM operations. That also provide you with some hidden "language" using which you can perform pretty sophisticated directories transformations, the skill that often amazed those who never using OFM manager and observe operations of an advanced user.

Another, already mentioned, advantage of OFM is that this is the only type of file manager that is standardized and the skills are transferable from command like to GUI and back as well as from one platform to another (for example Windows to Unix  -- this is an excellent way to dampen shock of the Unix command line for Windows users who want also use or even migrate to Unix).

OFMs are not for dummies. You will be more productive if you know the shell of the OS you are using. In this case you can use OFM as a navigational helper and a simple generator of complex command as you can easily insert into command line such elements of two panels as the current file, the current directory, directory of inactive panel and  so on.   That's why they are extremely popular among administrators, especially in Eastern Europe and xUSSR area. 

The author argues that this simple classic interface offers the most efficient way to perform complex file operations, and both users and software developers deserve some help in the form of the standard and some kind of commentary about "the state of the art" of this type of file managers. That's why I spend considerable time writing my online book The Orthodox File Manager (OFM) Paradigm that introduced two level of standards (OFM1999 - minimal OFM requirements  and Dr Nikolai Bezroukov. The Orthodox File Manager (OFM) Paradigm. Ch. 9 The OFM2004  provide both commentary and overview of major implementations. This is a volunteer effort and some parts are outdated.  Still this is the only e-book on the subject and as such it can help system administrators more consciously choose the implementation they need and polish the methods of work with OFM.

In this eBook I tried to distill several possible reasons for this surprisingly high productivity of OFM users, the productivity that despite of the age of the interface (more then 25 years) and its Spartan character remains unmatched. Please read at least Ch.1 of the OFM book, the chapter that introduces the concept. 

But even if you do not want to read it, selects and enjoy any OFM you like! I am using this class of filemanagers since 1987 (NC 2.0) and still learn new things each year, things that help to increase my productivity. Despite interface simplicity latest OFMs are very powerful and flexible programs, that have rather steep learning curve and you will be better off learning incrementally,  starting with simple file operations and gradually moving toward full power that bring customarization and availability of user many, extensions menu and several other features of OFM.

I also have found OFMs to be indispensable productivity tool for webmasters and despite my interest and professional exposure to other Windows and Unix filemanagers I am still convinced that in the hands of professional, productivity-wise, OFMs  have a huge edge. BTW I never managed to fully switched to GUI based OFMs, and still use mc in Unix and FAR in Windows environments although recently I spent considerable time using Total Commander.   That's because command line OFMs should be viewed not only as filemanagers but as a new ingenious graphical interface to shell, interface that makes standard Unix-style typing command on the terminal irrevocably backward. Professional Unix administrator fully versed in OFM usually outperform Unix administrator limited to "pure" commend line by a factor of two in not more.  It's actually a pity to see how this poor folk spends valuable time typing innumerous ls commands ;-)

And that brings us to an important point. While invented as a file manager in reality (and especially in Unix environment) OFM should be viewed as new generation of shell interface (visual shell) and as such they should be closely integrated with shell. Unfortunately this point was missed by most Unix developers and capabilities of typical Unix implementation in this respect are rather primitive. In a way you should think about Unix OFM implementation as a fork of screen with specially predefined top windows split vertically (I know screen cannot split windows vertically but let's assume that this is just an implementation limitation).  This ides of "OFM as a visual shell for Unix" is the main point that I advocate in my eBook especially in chapter 4 devoted to Unix OFMs. That's why despite their origin in Windows OFMs proved to be extremely natural to Linux/Unix environment. IMHO a Linux/Unix sysadmin with good OFM skills can be probably twice more productive then any super-skilled UNIX guru that use just plain vanilla command line ;-) Actually good knowledge of OFMs is a trademark of best Unix administrators from Eastern Europe.

But while Europe (especially xUSSR region, Eastern Europe and Germany) became the new home of Captain Norton, the initial versions of NC were written by a talented American programmer John Socha. Like with any brilliant idea it did not take long to implement and develop it to a mature condition: all the major work concentrates in just two years 1985-1987. At this time John Socha was the first director of research and development for now defunct small software company: Peter Norton Computing. Peter Norton who wrote the initial version of Norton Utilities, but AFAIK was not involved in writing Norton Commander was one of the pioneer entrepreneurs in PC software development; 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" ;-). 

The first version of Norton Commander was released in 1986 and it instantly became the dominant file manager for DOS. In 1987-1991 more then a million copies were sold.  In Eastern Europe Norton commander became a synonym of DOS interface and many users did not even understand that this is an add-on program. 

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 later acquired by Asymetrix. He continued cooperation with the Norton division of Symantec 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, but with the introduction of Windows killed it (as well as some other brilliant DOS product it acquired -- XtreeGold). Later they understood the mistake they made and in 1997 there was a reincarnation attempt: Norton Commander for Windows 1.0 was reintroduced in the Symantec product line. But talent was already gone and it  was "too little, too late" and after version 2.0 it died again (still as of January 2003 you can buy Norton Commander for Windows 2.0 in Europe, especially in Eastern Europe).  Not that I advice you to do that :-)

I would repeat it again that OFM can increase the productivity of sysadmins several times, especially for performing complex operation on Unix-style hierarchical file systems.  For some  unknown reasons no other file manager can compete with OFM in performing complex copying or moving of files on the directory tree. I several time managed to win a bottle of wine competing against Unix administrators who used only command line, and believe me as typists they were much better them me. The only other tools that I know, that have a similar semi-religious status with its adherents (but in a different area) are Xedit and vi editor (see my  Orthodox Editors for details).  That's why I consider OFMs to be a must (along with orthodox editors) for any advanced user, sysadmin or webmaster (both Windows and Unix).  As I wrote in my book:

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.

OFMs can be found on all major and minor operating systems including  all flavors of UNIX, OS/2,  all existing versions of DOS, Windows 3.1, 9x,  NT and even PalmOS and Personal PC. Actually OFMs probably represent the most portable family of filemanagers in existence (Xtree is also a very good filemanager available on several platforms, but not that many; Windows Explorer is an average filemanager that was also widely ported to almost any OS in existence because of the influence of Microsoft Windows).

Actually forgetting useful functionality is a problem as one fundamental shortcoming of relying of keyboard shortcuts is that there way too many of them.  This is a problem that require paying special attention to help facilities. OFM always have had a bottom line (or bottom menu as item are clickable by the mouse) that describes function of each of F1-F12 keys and if Ctrl or Alt is pressed and hold this dynamic "mini cheat sheet" changes accordingly. This feature needs to be implemented uniformly and extended to all dialogs.

Understanding OFMs as sysadmin IDE

The right way to look on OFMs is not as on file managers, but as an IDE for sysadmin. That means the quality of shell terminal window provided is of paramount importance for OFMs and the role of user menu is central. Unfortunately most current implementation are very weak in this area and that might be the reason OFMs did not got the popularity among sysadmins they deserve. Some like Total Commander treat shell terminal window functionality like red hair step child despite availability and great productivity enhancing potential of PowerShell on Windows. In Unix OFMs the low quality of shell terminal window implementation (that should be equal to GNU Screen split window implementation) in my view greatly influenced the fact that particular OFM implementation have difficulties to attract critical mass of sysadmins as is visible from scarcity of manpower and development resources in most implementations.

Simplifying the reference implementation for OFM terminal window implementation should serve GNU screen. Anything less than make them much less attractive for Unix sysadmins. That also means that internal viewer and built-in editor are very important, "first class citizens" parts of OFMs and implementation of them should get attention they deserve. The quality of their integration with panel-based file management subsystem by-and-large-determine the quality of this IDE. In this respect pioneered by Midnight Commander editor user menu is an important step forward and should be implemented in other OFMs, especially Unix/Linux OFMs. I would say that without this feature as well as dynamic user menu (also pioneered by Midnight Commander) OFM looks like second rate tools. Unfortunately Midnight Commander is not that perfect in shell terminal window implementation although there is a progress from version 4.6 to version 4.8 and implementation in version 4.8 while far from perfect looks more sysadmin friendly.

They can also serve the role of IDE for webmasters of the sites that use plain-vanilla HTML (as opposed to database driven sites). With ftp and SSH virtual filesystems available for such site an OFM is a quintessential Webmaster tool. It definitely plays this role for Softpanorama. This unique role that OFMs can play as a webmaster IDE fuels my interest in the field after more then two decades of usage. 

Along with integration of file managers, internal viewer and editor OFM also integrate functionality of a dozen command line utilities including but not limited to:

1. touch via files attribute dialog
2. tar -- via Archive VFS
3. gzip -- same
4. bzip -- same 
5. zip/unzip - same
6. ln -- via F5/F6 operations ability to create symbolic and hard links
7. chown -- via change attributes dialog
8. chmod -- via change attributes dialog
9. find -- via FindFile dialog
10. grep -- via FindFile dialog
11. more -- via internal viewer
12. cd -- via NCD panel
13. history -- duplicating management of command history with the additional recoding of history of all dialog boxes.

Comparison Table (from Ch.2 of the OFM book)

Ten OFM 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.

Recommendations for Users

OFM are tools written by programmers for programmers, sysadmins and power users. The elite of PC users. We can distinguish between two levels of OFM skills:

• Power user level when the user can perform basic operation without looking into help and realize most of the advantages of OFM. Such users typically use OFM strictly as file manager, not so much as sysadmin IDE, and usually do not need or make use of such features as user and extension menus and plugin API. Still power user  actions on keyboard often remind for uninitiated the way top piano players perform, achieving tremendous speed for pretty complex and non-trivial file manipulations.  This is the level most users can easily achieve with some effort and experience. With time methods of navigating filesystem used by user typically became more sophisticated automatically. For example usage of Alt-F10 for selecting new directory. You need to discover it once and its benefits are so obvious that you will user it ever since. Same is true for usage of filtering (Ctrl-I) for browsing only "relevant" files and usage of temporary panel for working with "projects" and other similar features.
• Master level is a more difficult to achieve level at which user is able to thinks about file operations in "OFM-way" and can generalize them into user menu items and plug-ins. They customize their OFM setup with keyboard macros, custom entries in the user menu and extension menu as well as tuned to their tasks set of plug-ins which further increases productivity.  Some can write their own plugins.  But the key criteria of  "master level" is the ability to create your own user menu entries and modify extensions menu to your needs. A user without knowledge of shell (or other suitable scripting language) and without his own original menu entries and custom extension definitions can't be considered to be on master level, no matter how well he can perform on the keyboard.  

Although basic skills can be acquired in less then a week and gradually can be enhanced to "power user" level, this is not true for master level skills. First of all getting to this level require knowledge of shell (or other scripting language).  Also you need to spend some time studying default "user menu" supplied with mc (for a given user many entries are redundant and he/she can start with deleting them) and, if possible, experience  of your colleagues in this area. But return of investment is tremendous -- you really will be working in more productive environment, environment productivity of which can't be matched with any number of "off-the-shelf" tools. 

Fundamental problem with any interface oriented on extensive keyboard usage is that the set of commands is large. That means that some important commands and methods are easily forgotten without practice (this situation is typical for any tool with extensive command set, such as vim). Based on my more then 20 years experience with OFM (I started using them in 1989) I would recommend the following  methods of enhancing your skills:

• High level of OFM skills (like piano playing skills, or arms mastery) require constant practice. Also, the basic level is perfectly fine and most users can be very productive on this level.  After all, we rarely learn things we can do without :-). IMHO the real stimulus to go to the real depth of OFM interface capabilities exists only for "netslaves" who spend eight or more hours daily behind the screen ;-) Without practice skills are quickly lost and only gradually can be restored to previous level; it happened to me more then once.   
• Keep a logbook.  It helps, especially at the beginning to write a daily entries in the log and reread them. That speeds acquiring the necessary skills. White down tips and procedures for typical situations, then rewrite and improve them.  Some most efficient methods of performing typical tasks are often discovered accidentally when you deviate from your typical path and are easily forgotten if you never wrote them down. Some of repetitive tasks that you have found ways of efficiently performing with OFM can be automated using macros and user menu.  
• Maintain your own cheetsheet. Put it on the top of your terminal (for example using one of those plastic cutting boards that you can buy in any store) or buy a mousepad that allow inserting paper in it. Start with something simple and readily available. Exclude items that are already etched in your memory. Provide in Cheetsheet references to pages of the log where you discovered and or discussed particular keyboard shortcut or tip. It is not uncommon to discover new methods of working with particular OFM even after ten years of intensive daily usage.
• Create and maintain your own set of keyboard macros and own user menu. If your OFM does not support keyboard macro recorder use some external macro recorder like expect, AutoHotkey, macro capabilities of terminal emulator like TeraTerm or buy a programmable keyboard  (less then $50 new, $30 used). This is simple and tremendously powerful method for extending OFM functionality. Some OFM (FAR and Total Commander are two notable examples) support plug-ins which is even a better tool, but unless you are a programmer you are limited to plug-in written by others which might be not exactly what you need. But just with keyboard macros and user menu parameterized mini-scripts regular sysadmin and/or power user can do a lot. Really a lot. Allocate time on documenting them and experimenting with new, potentially useful entries.
• If your OFM has user forum participate in it (for example both Total Commander and Midnight Commander have active web forums). Post questions and try to answer the questions of other users.

Time spend on those activities will be repaid many times. Learning OFM is one of the best investment in time you can make. Good luck !

Some recommendations for Orthodox file managers designers

There is an old saying that "Really innovative ideas are never stolen."  It is very true because "innovative" means ideas or products that go against established practice/fashion. Just read Talk: Orthodox file manager - Wikipedia, the free encyclopedia to get some insight into related mentality (Wikipedia actually removed the page "Orthodox file managers").

Why are they called Orthodox? --Error 23:55, 12 March 2006 (UTC)

Exactly. Because some 'tard' here is totally dependent on the MU way of thinking, never progressed beyond, and is not trying to convert the world. Of course there is nothing orthodox about them. Try 'crippled' - a much more appropriate term. I suspect the MU Commander people are behind it, shilling their own product. It's not ethical for Wiki. —Preceding unsigned comment added by 86.213.91.157 (talk • contribs)

The existence of that page just goes to show what a joke Wikipedia is.--88.149.233.68 09:17, 21 May 2007 (UTC)

Who dreamed up this definition? A Google search for "Orthodox file manager" yelds a measly 305 results. Moreover, there is NO MENTION of this thing in the Jargon file. The term "orthodox" is NEVER mentioned in GNU Midnight Commander 's home page. This entry is either a joke or somebody's personal "invention" and should be removed. --88.149.168.128 10:35, 28 November 2006 (UTC)

I agree. --24.21.72.22 16:16, 26 March 2007 (UTC)

Third the motion. So we should now seen this page removed, right? —The preceding unsigned comment was added by 86.213.91.157 (talk) 16:13, 5 May 2007 (UTC).

I think everyone knows your opinion. You're not getting very far by writing (unsigned) criticism all over this page. We had the AFD following the comments from 88.149.168.128. Since then, there seems to have been two complaints about the name of this article & both came from anonymous IPs. I think that deletion of this article is unlikely, but we do have a process for that if it is something you believe so strongly in. A move might be more reasonable, since the article (while not well written) is hardly "nonsense" & does describe something worth describing. I don't think anyone would argue that "orthodox file manager" isn't a neologism. However, it is a useful one. It has been adopted on the interwikis, by DMOZ, and by others. --Karnesky 23:17, 5 May 2007 (UTC)

Inappropriate  

Unless the term is a de facto standard - which it is not - then the use of 'orthodox' to describe something as retarded as a Norton file manager is tantamount to shilling and advertising. I strongly object to this. This page was evidently started over two years ago from an IP in China. I call on Wiki to show more discretion and as others I call on Wiki to IMMEDIATELY remove this STUPID PAGE. If you don't - we shall. —Preceding unsigned comment added by 86.213.91.157 (talk • contribs)

Usually reception on innovative ideas is deeply hostile and there are great difficulties even to convince potential users to try them or venture capitalists to finance the project. Inertia on one hand and (opposites meet ;-) fashion on the other rule IT (I think IT is more subjected to fashion whims then woman clothing with a new fad each second year playing role of the length of woman hemline and style of shoes; right now this is cloud computing  ;-).  As Charles Simonyi who oversaw the development of Excel and MS Word at Microsoft once noted:

“I have always worried that when these claimed incredible new benefits come, we will lose all the old ones. Then it becomes a kind of trade-off situation where you have to see if you are better off. I like clear wins. I would bet on improving what we have while maintaining all the benefits and eliminating the drawbacks, rather than introducing new games where there are new benefits and new drawbacks.”

OFM contains a set of innovative ideas that were only recently analyzed and somewhat generalized despite 25 years history. The level of adoption of this set of ideas (and first of all the idea of graphical shell) is surprisingly low. It is very low even among Unix sysadmin, who theoretically should be early adopters of this technology due to obvious OFM style visual shell interface advantages over plain vanilla command line interface.  One reason for this that proper implementation of shell terminal window capability in OFM is rare and this feature is mostly treated like red hair step child in current OFM implementations.

That's why I am still working on analyzing the set of key ideas behind OFMs and popularizing this set of ideas to wider audience.   I think that while each new implementation is an important step in popularizing the OFM concepts, only those implementation which try fully integrate into the design the visual shell "paradigm" and the idea that OFMs is actually a specialized IDE for system administrators and power users (that that entails deep integration of build-in editor into OFM along the line of editor user menu pioneered by Midnight Commander) can scratch a deeper itch and have a lasting value.

Commercial success of OFMs was and is limited and there little chance that situation might  change in the future, although some market openings probably exist for smartphone which are now much more powerful then old IBM PC (and has better screens). But in general this type of software does not feed developers well.  Consider this as a special kind of academic research. Actually all open source development can be viewed this way.

History suggests that OFM as research field has difficulties in attracting and retaining the most talented developers. John Socha switched to other projects just four years after release of Norton Commander 1.0 (it was released in 1986 and in 2000, one year after the release of NC 3.0 (1999) he left the company). If we add, say, additional two years before the first release it would six years in total.

Vladislav Volkov worked on his Volkov Commander even less, but manage to create a true masterpiece of assembler programming which even now looks incredible achievement (he started it being a student and did not even have had his own PC at the time). 

Eugene Roshal was involved with his OFM (FAR) approximately  five years or so. So far only Christian Gisler succeeded maintaining and enhancing his shareware Total Commander for  almost two decades... 

Still for young, ambitious developers that can be the field where they can prove their value as a programmers to the surprised world and learn quite a lot in the process. The latter part is probably the most important no matter what will be the final destiny of the product created and is one of the main attraction of open source in my opinion, making it somewhat similar to academic research, In old day there was a saying that in order for a computer science student to become a "real" programmer he need to write his own text editor.  Now it can be reformulated that the student need to write file manager with integrated viewer and editor. This way you really learn OS API, and learn to work with substantial codebase and experience problems typical for such projects (including gradual decrease of enthusiasm ;-) on your own skin.

Moreover, even small OFM projects are visible and have early adopters, who not only stimulate you to overcome difficulties, but also provide some helpful advice, or at least encouragement.  Look at two very interesting projects related to creating vi-style OFMs ( ranger and vifm ). Linking OFMs with vi concepts and vi culture proved to be a treasure trove of new ideas.

Just don't expect the project last forever and be ready to move to other things when you feel it became more of a burden then a education tool and writing new code for it, and especially maintaining the old one, lost most of the fun. But why not to try? There are visible gaps in functionality not filled by current implementations. For example as I already mentioned Unix implementation are surprisingly, dismally weak in implementing the idea of "visual shell" even on FAR level. If you manage to advance OFM in this direction you may attract enough following to continue the project when you'll leave it.

Actually for open source project it can happen that project died and then after several years the codebase is resonated with somebody own ideas and is picked up by a new talented developer who continued it for a while (that happened with FTE editor  and GNU screen). That's the beauty of open source which again make it close to academic research, for example research in mathematics (one may argue that each program is a kind of specialized mathematical theory).

But it is not always that fact that a talented developer picks up the code base. Sometimes the situation is quite opposite.

So you do not need to start your project from scratch. You can pickup some promising but abandoned project and try to move it one step further. If you doing so it is important to resist natural temptation to wile out all traces of the original author. Again this is more like academic research so please treat them as you want further generation of OFM developers to treat your modest contribution to the field. Among project that I think have value for developing further are

• All Python-based OFM projects as well as Perl and Ruby-based projects, as scripting languages can provide a better implementation language for OFMs than alternatives.
•  Bash Commander by Sergey Vakulenko

  This is a project of Sergey Vakulenko, the author of deco -- one of the first OFM for Unix. Looks like abandonware. Still the direct integration with shell is the best, the most optimal way of implementing OFM, which in essence is nothing more that an attempt to create a graphical shell. The problem here is the most shells are moving target and as they develop the codebase needs to be resynchronize with each new version. Which in most cases dooms the project.  So the only way such a project can be successful is when it is integrated with the development of shell itself. Some shells, such as ksh93 are pretty stable and development is almost stopped. For them such a project is more viable. Also for shells that undeservingly are sidelined, such as zsh, this may be a chance to get into mainstream, as zsh integrated with OFM leaves "pure" bash in the dust. 

  'Bash Commander' is a version of the GNU Bourne Again shell extended with two-panel file manager. Visit http://groups.google.com/group/bashc for project news, FAQ, discussions etc.

• Minimalist OFMs such as deco.
• Implement OFM as clean client-server system.  Here is some relevant information from Chapter 7 of my eBook:

  Starting from version 3 Norton Commander has client-server capabilities (initially via serial null modem line). It was clear even in tiles of DOS that OFM actually consists of two parts:

  • Client -- part that provides typical for OFM interface
  • Server -- which consists of different programs performing actual manipulations with the filesystem

  Now those capabilities are reimplemented using more modern technology. Client part can be implemented as a an extension of a browser and there is at least one such an implementation: firecommander  in Google Projects

  CGI interface looks pretty adequate for communication with various program that perform user actions. Moreover CGI-based interface between client and server parts of OFM make it almost infinitely portable: all you need to run it on a new platform is some basic web-server. Browser with JavaScript capabilities can be on other  platform.  And Web server implementations exist for any platform. 

  The second approach for the creating of truly portable OFM is to use Java for both parts. Java can be run inside the browser and that solve the client part of equation. And Java can run on any server and that solve that server part of equation.

  In other words the principal idea here is to split OFM into two independent parts communicating well established and refined HTTP or HTTPS protocol.

  This is also provides an interesting capability for X11 based remote solutions such as  VNC  for administering servers over dial-up lines or other low bandwidth communication lines.  Also in this case keyboard emulation can be perfect and does not depend on idiosyncrasies of terminfo database on a particular platform -- the issue that hunts Unix OFMs.

  Another reason is the crisis of several implementation, like Midnight Commander, which grow codebase to the extent that it became a complex mess of different libraries that are typical only for Linux. Which created problems with portability and actually discourage usage such OFM as mc as portability outside a couple of platforms (Linux and Solaris) is problematic.

  In this case, even usage of traditional implementation of OFM using Java, such as muCommander along with VNC represents much more portable solution as long as JVM is already installed (which is true for all Unix flavors).

Of course it is difficult to sustain project of pure enthusiasm and time will come to leave it. Please provide documentation for the next generation of developers, as they might come. Even if you abandon your project, you efforts are not in wait as any such project is a great programming school, the school that you can't attend anywhere else for any money. And your experience in developing OFM has a great value in itself as for the reason I explained above, and so be it. Move on. 

There are several ways to beat older OFM implementations in the same game, despite having much small resources:

• To use scripting language as your implementation language or at least integrate scripting language (for example, LUA) into design  from the very beginning
• Use programmable editor as a base of your implementation
• Use windows manager like GNU screen or Ratpoison as the base of your implementation
• Consider reusing some open source IDE framework
• Other possible avenues
• Adhere to standards.  

Use scripting language as your implementation language or at least integrate scripting language (for example, LUA) into design  from the very beginning

A very promising way of simplifying codebase and lessening the amount of lines which are needed to achieve given set of OFM functions is to use a popular scripting language as implementation language and, simultaneously as a macro language. Or at least try to integrate scripting language like LUA into design from the very beginning.

To make your effort more productive it is of paramount importance to use the highest level of language that you know well (or plan  to learn; writing an OFM is perfect programmer training exercise) and that is available on the platform of your choice. In case of scripting language you can get some decent functionality with a manageable for regular human size of codebase (say less then 5K of lines instead of more common for light-weight OFMs sizes like 10K lines; please note that mc is ~72K lines including comments if we count them via command cat `find ./src` | wc -l)

I think it makes great sense to restrict yourself to certain number of "kilolines" and try to do something useful within those restrictions. Projects like mc have pretty high barrier of entry, although they are modular and the largest part probably less then 45K lines with comments or ~25K without them.

If you will feel interest and see perspectives for the project, you can later abandon those restrictions or, better, start anew with a new level of understanding of the problem and the benefit of already acquired experience. Abandoning a couple of thousand lines is not that painful. Abandoning 10K lines written partially on weekends and stolen from family and friends is quite another story (despite the fact that a very good programmer can easily write 1K lines in a weekend). Another benefit of small codebase is that you do not need to kill yourself in endless debugging sessions.

In any case for those who are rotting in some large corporation and feel that they can leave their brains in the morning at home and still perform well this is one way to lessen the frustration from working in a large corporation and enjoying good salary, great benefits, access to the latest hardware and other pluses that large corporation provide.  Talented system administrators with programming abilities can definitely try this path as for them the level of frustration after university is especially high and designing own or supporting an existing OFM project provide immediate value in their primary work environment. See  Social Problem in Enterprise Unix Administration

Use a programmable editor as a base of your implementation

Classic example of an application with a command line interface and a scripting language as a macrolanguage is XEDIT and its derivatives KEDIT and THE. The latter is an open source implementation. While it uses REXX which is not very popular those days, all key implementation ideas are applicable to any other scripting language.   This way all options in panel configuration (sorting by specific attributes, filtering files of specific types, etc can be delegated to this macro language and all you need to implement is the filtering of file list via this user supplied macro. This alone saves provably 30% of codebase. Even larger savings can be achieved by implementing panels as specialized editor windows with read-only files in them. Editors and OFMs are actually two very similar projects and if you have editor of your liking with open source codebase available this is probably the best way to learning it in professional level. Tight integration of built-in editor and filemanager is a promising but never properly implemented idea that still wait for some breakthrough implementation.

As power users are generally very attached to their editors, you can try to implement some minimal implementation of OFM within the framework available for existing programmable editor. As OFMs are genetically oriented toward sysadmins,  vi is a natural choice. Emacs is also a possibility but it way too complex to serve as a reference platform although usage of lisp or lisp-like language for extending OFM like Emacs worth investigating.

VIM is an obvious candidate and there are already several file managers implemented for it.  Similarly some implementations already exist for Emacs (Sunrise Commander) which was implemented on top of Emacs in elisp. Even if your OFM project fail, after programming those extensions and learning API you will became a real specialist in this editor. And deep knowledge of editor is a tremendous asset in your professional career. 

You can also leave the codebase alone and just to use ideas of editors in OFMs, for example the idea of distinct command set (: command in vi) and (piping from and into the editor which actually now is also present in some OFMs such as Midnight Commander). That can be in interesting and promising angle. For example vi has set of ideas that really can enrich OFM concepts. Look not only at attempts to create OFM inside vim in a macrolanguage, but also on attempts to emulate vim concepts in OFM. There are two very interesting projects related to creating vi-style OFMs ( ranger and vifm ). Linking OFMs with vi concepts and vi culture proved to be a treasure trove of new ideas.  

Use windows manager like GNU screen or Ratpoison as the base of your implementation

OFM in reality represent something "in-between" tile windows manager (look at Ratpoison for inspiration) and multi-window terminal emulator like GNU screen on one hand and editors on another.  The people who manage to find right architectural solution along those lines stand better change to compete with established players, because they can reuse pretty rich codebases. While convoluted ad-hoc solutions to those problems hamper  "old-style" OFM implementations. Again Achilles part here is the implementation of command line window and the flexibility of  integration of internal editor on the base of common macrolanguage and common library of primitives.  Ad-hoc hacks in those areas inhibit further growth.

Consider reusing some open source IDE framework

As we mentioned before, one way to look at OFMs as to view them as an IDE for system administrators, who have different needs and preferences them programmers. 

But that does not exclude reusing some open-source framework created for, say, scripting language and written in scripting language. You can definitely reuse a part of implementation of windows system and the editor.

Who candidates that instantly come into mind are Parde or Eclipse. Please not that I hate Eclipse as it is a heavy weight framework, but for experimentation with new OFM features this is a perfect tool.  Using IDE also will help you as a developer, as you will be more productive due to in depth knowledge of this IDE.

In case your chosen IDE is Eslipse, the knowledge you obtain in process of reuse it has great market value: an additional advantage of this approach is that cal simultaneously  became an expert in Eclipse which has its own value on the marketplace. In any case IDE architecture already resolves one way or another all major problems that OFM designer faces and if particular IDE is still developed here again there can be a synergy between two project that can benefit both. Which is always good for open source projects that are typically starved for money and workforce and survive mainly on the enthusiasm of a single developer or a very small team of dedicated designers who really sacrifice their time to the project. Look at ht history of Midnight Commander for more information.  In this sense donations to the project are very important and users of open source products would always remember that there is no free lunch. If they do not support the project it has significant chances of dying and they will be hanging in the cold, if they depend on it. And forced to pay the price of switching to another which can be really significant.  In this sense shareware development (possibly with open code base -- the danger of stealing codebase of significant complexity in reality is close to zero) is more sustainable then open source development. Also FSF can (and should) act as a charity, not as a Stallman vanity promoting venture that stamps GNU label on the projects as a seal of approval of project license with zero real support. It should allocate some money for important projects like GNU Midnight Commander from member dues. Actually for orthodox file managers, orthodox monks should also provide some help ;-)

Other possible avenues

If existing file manager is flexible enough you can try to modify it to comply with the requirements of OFM1999 standard. Victor Zverovich tried the same for Nautilus, see his captain-nemo. 

Of cause there are other opportunities about which I do not know. For example you can use screen and implement panels as shell windows using screen vertical split patch.  There probably other interesting architectural opportunities for OFM about existence of which I do not even suspect.

Adhere to standards

I know everybody thinks that he can do better and that's mostly true. But this is not the all truth. Real truth is deeper. Remember that, as artists know all too well, "form liberates" and the less time you spend on designing your own interface and set of keyboard shortcuts, the more time you have on developing quality implementation of features that you value most. Under Spartan interface of OFM and within restriction put by OFM1999 there are tremendous possibilities for innovation. First of all in the area of integration with shell and virtual panels (in general panel can contain arbitrary set of files, not just content of some directory).  Then in integration on built-in editor with the rest of file manager (the difference between the editor and panel management code is not that big -- panels can be considered as read only windows of the editor and implemented as such)

Focus on key features is the key

In view that involvement of most OFM developers is limited in both time and the total size of codebase (if this is a single person project, but mist such projects are),  the most optimal way of designing new OFM managers is to concentrate on better implementation of one of two key ideas and limit "bells and whistles" to some future period when and if users provide feedback and make it clear that it makes sense to develop the product further.

A single developer simply can't compete with, say, Midnight Commander, or FAR, or Total Commander in the "total coverage" of functions.  But you can implement minimal OFM standard and try to beat other developers by attacking a different set of problem or implementing one of the features that are "misunderimplemented" in current implementations. For Windows OFM the key is usage (and integration with) PowerShell; for Unix implementing command like window should in in a style of GNU screen, as a "first class citizen" not as a bastard child like in Midnight Commander.

In this sense it is important to understand that 80% of your users will probably be limited to basic features described in minimal OFM standard  (Orthodox File Managers Standard 1999(OFM1999) - minimal OFM requirements). They will be attracted by "the feature" that your OFM implements better then competitors, not the general richness of features and "total coverage"...   

Key unresolved problems with OFMs

For standalone application the question if you can built a better mousetrap probably revolves around three features that IMHO are badly addressed in current generation of OFMs:

• Compensating for excessive number of keyboard shortcuts the user needs to know/learn to use OFM productively.  There might be some inventive approaches but, for example, in Unix a better implementation of "helpline" at the bottom of the screen (under the command line) and extending this concept to all dialog boxes can provide great benefits for users, including yourself as the primary user. I for example forget half of "more esoteric" functionality of FAR when I do not use it on daily basis for a week or so. I think other users have the same problem -- too rich set of keyboard key combinations is a self-defeating idea :-(.

  In case of Unix/Linux with its severe restrictions of keyboard driver capabilities you can imitate DOS helpline functionality by "rotating" line with some shortcut with each "slot" representing one of the four position like in the revolver -- plain (no special keys pressed), Alt, Ctrl and Shift.

  This problem with "excessive richness" of command set for keyboard oriented applications is a generic problem, for example vim suffers from it too. So putting efforts in solving it in some elegant way might have far greater return than just your OFM.

  In a way quality of such built-in cheat sheet like OFM bottom "helpline" is much more important for applications that emphasize keyboard usage, then for GUI applications. And solving it in an elegant, inventive way will definitely attract users, especially users who have some investment in other OFM but hit the "glass ceiling" and just can't remember more shortcuts. For example, from my own experience I suspect that this is a fundamental problem for users of Midnight Commander which does not implement "helpline" properly and in menus does not implement anything sophisticated in this area  at all. 
   

• Integration with shell. An Achilles spot of many popular OFM implementation is the compete, absolute lack of understanding of command window semantic. Classic example in this respect is Total Commander. It also negatively affects the of implementation of user menu (called start menu).  Developers who can do better in this area provide for users much better functionality can rightly advertise this advantage and hope to attract power users who value this feature (most OFM users do use command line). There are multiple neat ways cleanly implement the concept of command line window and in case GNU screen approach is used functionality of GNU screen  can be extended to OFMs. That really might make a difference for the users. Another possible avenue of increasing user attractiveness of OFM is providing its own macrolanguage such as LUA which automatically guarantee you full support of regular expressions in dialogs via PCRE library.  This for example is important for the implementation of dynamic user menus and in implementation files search. 
   
• Integration with internal editor and viewer.  The main danger in to make your codebase too big. One way to cut the size of the codebase is to exploit hidden synergy between internal editor and panel management code. False solution here is to drop internal editor altogether (Total Commander is an example of this approach). As editor code can be studies and borrowed from several first class open source implementations that creates an opportunity of reuse of this library (and possibly internal macro language, if the programmable editor serves as a reference model is ). If the editor is still actively developed there can be synergy and sharing with the developer of the editor as part of functionality of OFM related for file management is useful for editor two. This way instead of team of one, you can have a team of two.  The library used in development of a good editor contain probably 60% what is needed for the development of OFM and polishing of this library can benefit both projects.  So an interesting approach to OFM development would be to start with some editor implementation and try to extend it to OFM maximizing reuse of common elements and the macro language of the programmable editor. One interesting example of this approach is Sunrise Commander which was implemented on top of Emacs in elisp.

Your web site can as a powerful tool of popularizing the idea that you have chosen.  In case you are doing open source development; don't be shy to ask for donations, especially in a form of equipment.

Conclusions

I think that for system administrators this is a question of "esprit de corps" to support development of one of OFMs.  As sysadmin IDE this open source development helps everybody and this page is my small contribution to the development of OFMs as sysadmin IDE of choice.  If you think how dull typical enterprise environment is, you probably can find a couple of hours a month to contribute to the project. It is not necessarily contribution via coding. Testing and creation of documentation are also very valuable, albeit much underappreciated activities.

A challenge for human-computer interface is to support creativity and that's flexibility that OFM interface provides and close integration with shell make them far more extensible and "creativity friendly" from other types of file managers.

If you are a sysadmin who never tried one, please spend a couple of hours (or better days) and play with  Midnight Commander or FC for Linux/Unix and FAR on Windows.  All of them provide some implementation of shell terminal windows which is of primary importance for sysadmins. FAR also provides rich set of plug-ins and integration with LUA. Please note that OFMs have a rather steep learning curve and don't be discouraged by initial difficulties. Your persistence will pay you nicely... 

Webliography

Orthodox File Managers

The Orthodox File Manager(OFM) Paradigm

Dr. Nikolai Bezroukov

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