|Home||Switchboard||Unix Administration||Red Hat||TCP/IP Networks||Neoliberalism||Toxic Managers|
May the source be with you, but remember the KISS principle ;-)
Skepticism and critical thinking is not panacea, but can help to understand the world better
The future is already here — it's just not very evenly distributed.")
This is a third of OFM standards developed by the author. Currently this is early draft stage. As such this a copyrighted unpublished work. Please do not copy this page to any other site or medium. The content will substantially change is subsequent versions and it is important to avoid confusion caused by early drafts stuck in the WEB. The sole purpose of this early draft publication is to invite comments (see Feedback).
Distinct command language layers and the usage of scripting language as a macro language in all levels of implementation, and first of all in dynamic user menu and extension menu
"Dream OFM" standard is based on generalization of actual features of various OFMs (as reflected is famous William Gibson saying: "The future is already here — it's just not very evenly distributed."). It involves features in which, during my research I saw the possibility to of useful generalization and user extensibility. And user extensibility is the key for the power of the particular interface.
While each of those features is attractive the devil is in implementation details. Some of those features are incompatible with existing OFM architecture which is rather simple. Shell terminal window is one such example.
Most OFMs are products of a single developer and that limits upper level of manageable complexity of such a tool to, say, 10K lines of pure code (not counting comments, includes and libraries). This upper limitation has three major consequences:
This standard should help in selecting item number 2 -- the leitmotiv of your implementation.
The list is still dynamic (and you can contribute to it, see Feedback for Softpanorama.org) and currently includes, but is not limited to:
Note: Like we probably will never see 256 bit word computer we probably might never see OFM with all such features fully implemented. But this list should influence priority of existing implementations and might help to implement some areas where they are dismal such as command windows support, which is an Achilles spot of such otherwise wonderful implementations as Midnight Commander (where it is a dirty hack) and Total commander in which it is totally ignored :-).
The implementation should provide full capabilities of shell terminal window without any limitations (like in split mode of GNU screen). Proper implementation of command window significantly amplifies the power of Unix shell or Power Shell in Windows, making OFM a natural part of shell environment, a unique incarnation of a graphic shell. Here you need to take approach of windows manager (like ratpoison) during the implementation which definitely was never done in old OFM implementations.
Although originated in DOS, in my view OFMs can and should be considered as a new generation of Unix shells command line interface, the interface that simplifies working with the command line shell environment. I would say that this is essentially a breakthrough in the creation of the shell command line interface. The only thing that is lacking is a component model and the integration with a suitable scripting language as a macro languages (for example, scripting host in Windows, TCL in Unix).
That means that the importance of OFMs is closely related to the importance of shell environment and that OFM are most attractive to power users, especially Unix and Windows system administrators who use shell on daily basis. As David Korn aptly said (bold italic is mine - BNN):
There are many people who use UNIX or Linux who IMHO do not understand UNIX. UNIX is not just an operating system, it is a way of doing things, and the shell plays a key role by providing the glue that makes it work. The UNIX methodology relies heavily on reuse of a set of tools rather than on building monolithic applications. Even Perl programmers often miss the point, writing the heart and soul of the application as Perl script without making use of the UNIX toolkit.
Paradoxically that means that Unix is a better environment for OFMs then Windows. Recently that changed with the introduction of PowerShell by Microsoft which in many ways resembles Korn shell.
Panelizing editor window brings certain benefits for command line OFMs (in case of GUI OFMs you open it in a separate window and view it on the second display, so while useful this is not that critical)
Thinking about OFM along those lines reveal deep analogy between OFMs and tiling windows manager. See Tiling window manager.
Some Windows managers implementation like ratpoison have a lot of common with OFMs. What is interesting is that ratpoison is a generalization of GNU Screen and was inspired by GNU Screen functionality.
One of the key features of orthodox interface is a distinct command language layer. Typical examples of this layer we can find only in editors such as Xedit (and its derivatives such as Kedit and THE) and, of course vi. In this sense Norton Commander was "semi-orthodox" file manager as this layer is absent from the implementation.
Currently few OFMs explore this avenue of development. Among them are Ranger and EmelFM2 -- a GUI-based OFM written in C++ with usage of GTK+2 toolkit.
Ranger - a Python written file manager with default vi bindings. Here is the command set it provides:
You can enter the commands in the console which is opened by pressing ":".
There are additional commands which are directly translated to python functions, one for every method in the ranger.core.actions.Actions class. They are not documented here, since they are mostly for key bindings, not to be typed in by a user. Read the source if you are interested in them.
This shell script is opened in an editor for you to review. After you close it, it will be executed.
:cd -is equivalent to typing "."(dot)
The octal number is between 000 and 777. The digits specify the permissions for the user, the group and others. A 1 permits execution, a 2 permits writing, a 4 permits reading. Add those numbers to combine them. So a 7 permits everything.
Key bindings in the form of [-+]<who><what> and =<octal> also exist. For example, +ar allows reading for everyone, -ow forbids others to write and =777 allows everything.
See also: man 1 chmod
To copy key bindings of the console, taskview, or pager use "copycmap", "copytmap" or "copypmap".
When asking for confirmation, this command will only proceed if the last given word starts with a `y'.
Examples: :eval fm :eval len(fm.env.directories) :eval p("Hello World!")
The keys you bind with this command are accessible in the file browser only, not in the console, task view or pager. To bind keys there, use the commands "cmap", "tmap" or "pmap".
None None bool True or False integer 0 or 1 or -1 or 2 etc. list [1, 2, 3] tuple 1, 2, 3 or (1, 2, 3) function lambda <arguments>: <expression> regexp regexp('<pattern>') string Anything
Names of e2 internal commands (a.k.a. actions) are of the form 'string1.string2', e.g. 'file.copy'.
Actions may be executed just like an external command, by entering the action name. You may add argument(s) for an action, with whitespace character(s) between the action name and the first argument, e.g.'file.view mydocument'.
A detailed description of actions and their arguments is provided in the document ACTIONS. A list of the actions can be found in the configuration dialog, e.g. by clicking on the action column on the 'key bindings' page.
Much like shell environment variables, internal variables may be defined and used e.g. for communication between actions or commands. As in the case of an environment variable, an internal variable can be stored by a command of the form 'NAME=VALUE', retrieved by '$NAME', and cleared by 'NAME='. In addition, a command '=VALUE' will list the name of any variable with that value, and just '=' will list all internal variables with their values. Whitespace surrounding the "=" in any variable-related command is ignored.
There are several ways to influence how e2 runs a command (action or external command). One or more of the following may be applied:
* adding '>' to the beginning of an external command will cause it to run in a separate shell, i.e. bash, zsh, korn, sh etc. This is necessary if you want extra functionality like pipes, re-direction, fancy variable processing. Commands which include any of '|<>' are automatically run in a separate shell.
* adding '>>' to the beginning of a "joined" external command will cause it to run as a single command in a separate shell, i.e. bash, zsh, korn, sh etc. This is necessary if you do not want the individual components of the joined command to be indivually sent to the shell.
* adding '|' to the beginning of a command will cause it to 'block'. This means nothing else will happen until the command is completed. (For commands applied to selected items, any '|' will be ignored, as a configuration setting takes precedence)
* adding '!' to the beginning of a command will suppress macro expansion. (See below for macros description). This means things like '%f' will be treated literally.
* adding '&' to the end of a command will run it in the background, and all output other than standard error is suppressed. (For commands applied to selected items, any '&' will be ignored, as a configuration setting takes precedence)
Unless the OFM written in scripting language (and is this case you need "to eat your own dog food") I think using LUA instead of ad hoc language ("vendorscript") can bring great benefits both to developers and to users. For example visibility conditions -- a method of hiding "irrelevant" items from the user menu first invented and implemented in Midnight Commander can be much better implemented using scripting language. Generally this approach has great potential as Midnight Commander only scratched the surface in adding power to the user menu. It is actually a great way to organize sysadmin sell scripts.
This is a method of hiding "irrelevant" items from the user menu first invented and implemented in Midnight Commander (but possibly based on usage of LUA library for programming conditions instead of ad hoc approach used in mc). For example if particular menu item works only with selected files on active panel, there should be capability to hide this element in "displayed user menu" (which is dynamic and is subset of items defined in user menu) when no selected files in present on active panel. And if particular element of the panel works only with tar and gtz archive, it should be possible to specify that it is excluded if the current file does not have a suitable extension. In way this is a generalization of extensions menu to each item of the user menu.The MC implementation was based on availability of special macros in user menu such as:
That on this macros the MC developers expended the notion of user menu item by providing the capability to include special conditional expressions that use values of those macros before each user menu item
Actually with proper plug-in API the core OFM can be made very small, and most of operations typically associated with core can be offloaded into plug-ins. That would greatly simplify the codebase for the core.
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 - Orthodox File Manager implemented as Firefox extension in Google Projects
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).
Infopanel is the state of the passive panel in quick view mode. Infoline is the last line of the panel where by default the name of current file is duplicated and some additional attributed are provided. You can think about it a minimized infopanel.
An interesting thing about infoline is that you can think about its content as an output of a script that is run each time the current file changes. Actually the same mode that is called quick view in OFMs.
That mean that we can provide a capability to assign a script to both Infopanel and infoline. This script can pipe its results into the infoline/infopanel with each change of the current file. It also can be set of scripts depending on extension. For example, for extension .pl it can execute the command
while for MP3 files it can extract some tags
Two keywords need to be added to extension menu
Operation Ctrl-O which opens full screen shell terminal windows and minimized panels can export all context variables in a file which can then be source by shell scripts. That actually make Ctrl-O viable even in GUI implementation when shell screen can be constantly visible due to larger real estate (especially in dual monitor configurations).
For example for mc it can be mc_env.sh file which should be put in user .mc directory. The file should have very simple structure for example:
export mc_f="..." export mc_F="..." export mc_d="..." export mc_D="..." export mc_t="..." export mc_T="..."
and be only readable, not executable (as it should to be sourced in, not executed).
On return to panel view mc can source another file mc_start_dir in which the last line should represent directory that active panel should display, is such directory exists and is accessible under current mc process id. As content is checked for existence of a directory is should a safe operation.
The three existing mechanisms of grouping files in OFM:
can be implemented as a single mechanism (panel) with just three different targets. Default target can be determined based on hotkey used for invocation of this dialog.
Ability to store search results in a form similar to user menu and directory favorites is important.
Actually elements of this understanding can be observed in Total Commander and nomad by Eugeny Sichkar
In the current form as implemented in Midnight Commander panelize command can pipe into panel result of arbitrary script as long as it is represents the list of files.
Here is another generalizatrion in which output can be piped in viewer (Nooface TermKit Fuses UNIX Command Line Pipes With Visual Output)
TermKit is a visual front-end for the UNIX command line. A key attribute of the UNIX command line environment is the ability to chain multiple programs with pipes, in which the output of one program is fed through a pipe to become the input for the next program, and the last program in the chain displays the output of the entire sequence - traditionally as ASCII characters on a terminal (or terminal window). The piping approach is key to UNIX modularity, as it encourages the development of simple, well-defined programs that work together to solve a more complex problem.
TermKit maintains this modularity, but adds the ability to display the output in a way that fully exploits the more powerful graphics of modern interfaces. It accomplishes this by separating the output of programs into two types: data output, which is intended for feeding into subsequent programs in the chain, and view output, for visually rich display in a browser window.
The result is that programs can display anything representable in a browser, including HTML5 media. The output is built out of generic widgets (lists, tables, images, files, progress bars, etc.) (see screen shot). The goal is to offer a rich enough set for the common data types of Unix, extensible with plug-ins. This YouTube video shows the interface in action with a mix of commands that produce both simple text-based output and richer visual displays. The TermKit code is based on Node.js, Socket.IO, jQuery and WebKit. It currently runs only on Mac and Windows, but 90% of the prototype functions work in any WebKit-based browser.
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-2018 by Dr. Nikolai Bezroukov. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) in the author free time and 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 make a contribution, supporting development of this site and speed up access. In case softpanorama.org is down you can use the at softpanorama.info|
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 author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.
Created Jan 2, 1999; Last modified: March 12, 2019