May the source be with you, but remember the KISS principle ;-)
Home Switchboard Unix Administration Red Hat TCP/IP Networks Neoliberalism Toxic Managers
(slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and  bastardization of classic Unix

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)


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.



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:

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:

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

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:

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:
    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 CommanderKrusader  , EmelFM2, GNU Commander, GNOME Commander in Linux, FreeCommander, Altap SalamanderNecromancer'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:

    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;;
            gzip $DECOMP -v %f
    + t t
    Y       Gzip or gunzip tagged files
            for i in %t
              unset DECOMP
    	  case "$i" in
    	    *.gz) DECOMP=-d;;
    	    *.[zZ]) DECOMP=-d;;
              gzip $DECOMP -v "$i"
    + 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;
    	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:

Three main advantages of OFM are (1) close integration with the shell, (2) portability and (3) the availability of public standard

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:

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).

Another 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).

The first and the main advantage of OFMs is simplicity and stability. Attempts to radically enhance this simple, Spartan interface largely failed.  Also after the first three years of using OFM most file operations can be performed so fast that usefulness of further improvements  might be marginal ;-)

There is now a large number of OFM users who have more then 20 years experience with this category of file managers, wand who while achieving amazing productivity due to multi-year day-to-day experience, still are polishing and improving their skills.  Few other types of file mangers can boast such dedicated and "hardcore" user base. And that includes myself. I use OFMs daily for the last 23 years. And my memorized keyboard shortcuts and tricks that I first learned using Norton Commander 2.0 or 3.0 are still applicable to modern OFMs.  And I am still finding some new features of tricks that increase my productivity, some (or most ;-) of them I was aware at some time in the past 20 years but forgot ;-).

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.

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.  On Unix quality of shell terminal window implementation (that should be equal to GNU Screen split window implementation) in my view greatly influence whether particular OFM implementation can attract critical mass of users, or not.

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)

OFM name
(and link to a book chapter)
Norton Commander
File Commander
Dos Navigator
Far Manager
Midnight Commander
Norton Commander for Windows
Total Commander WinSCP Krusader EmelFM2 FreeCommander mu
Altar Salamander
OFM Type Classic Classic Classic Classic Classic     GUI GUI GUI GUI GUI GUI GUI GUI
Status of development
(active if the the version is less then six month old, stalled if a year, frozen if more the a year)
Stalled Stalled  Active Active   Abandoned Active Active Stalled Stalled Stalled, but forum is active Active Stalled
Last stable version 5.0 2.4
(as of March 2011)
2.31.5309 (Mar 23, 2010)
1.75 build 2634 and 2.0 build 1897
(Feb 03, 2011)

Far 3.0 built 2884

(Sept 2012)
  2.01 8.01
(Aug, 2012)
(Mar, 2011)
2009.02b 0.9 (as of July, 2012) 2.54, Sept 2010
OS supported DOS  OS/2,
Win 9x,Linux, Solaris, FreeBSD

Linux (ndn)

 Win Linux & Unix
  Win 98, Win2000, Win XP  Win XP, Win 7,
Win 8
Win XP, Win 7,
Win 8
Linux, KDE Linux, GTK+ Win Multi-platform
Windows XP and Win7
Size of compressed distribution 1.4M   0.3M ~1M 1M 1.56 M      2M   3.5M 4.78 4M 1M (source) 2.54M 4M 7MB
Software type and download link (if different from the development Commercial Shareware Open source:
2 major versions:
ndn & dnosp
Far 1.75 is free,

Far 2.0 is open source

  Commercial Shareware GNU License GNU License GNU License Freeware GNU License Commercial
Price $90 ? $35 $0 $25 $0   £21/€ 35 $44/€ 32 $0 $0 $0 $0 $0 $29.95

Ten OFM Commandments ;-)

"I have found Jesus. He came to me in the form of muCommander."

-- A happy user

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.  
  2. Seamless integration with the shell making OFMs a synonym to "Visual shell.". There are two features that are obligatory for orthodox file managers
  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:
  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. 
  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:
  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.

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":

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:

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:

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 (talk contribs)
The existence of that page just goes to show what a joke Wikipedia is.-- 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. -- 10:35, 28 November 2006 (UTC)

I agree. -- 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 (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 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)


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 (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

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:

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:

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.


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


Orthodox File Managers

The Orthodox File Manager(OFM) Paradigm

Dr. Nikolai Bezroukov



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


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 quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard Shaw : Mark Twain Quotes


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


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 DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting 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-MonthHow 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

Copyright © 1996-2021 by Softpanorama Society. was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to to buy a cup of coffee for authors of this site


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