FAQ

Why should I use a terminal file manager?

Below are some reasons why one might prefer using a terminal file manager. Note that, not all terminal file managers provide the same set of features and the emphasis here is given to lf.

• Terminal file managers give you a visual representation of the current directory at all times.

  When you do some file operations (e.g. create/delete/rename a file/dir) you can immediately get a visual feedback. This releases the cognitive burden of keeping the representation of the filesystem on your mind and makes it easier to spot mistakes. A similar analogy for the relation between shells and terminal file managers can be seen in classical ex and vi editors. The idea of seeing the edited text continuously proved itself to be quite useful in many cases.

• Terminal file managers let you assign frequent commands to simple keybindings.

  You can launch your pager/editor or run version control commands with a few keys. Unlike aliases/functions in regular shells, most of the time

  1. you don't need an extra enter key,
  2. you don't need to type the file name or tab complete it, and
  3. you can get a popup list of existing mappings for keybindings with multiple keys without resorting to tab completion.

  This is similar to modal editing much like normal mode in vi, but for your shell.

• Terminal file managers can be used to select certain files to operate with.

  Compared to globbing in regular shells, toggling files/dirs in terminal file managers

  1. are usually more straightforward to do so, and
  2. minimizes the possibility of accidental selections by showing you what is selected. In any case, you can always use globbing in terminal file managers as well when you need it.

  Again, a similar analogy can be seen in the visual mode for vim editor which provides an alternative to operator pending mode when you need it.

• Terminal file managers give you an alternative to cd/ls cycle or cd with tab completion.

  This lets you navigate the filesystem using the keys in your home row instead of typing names or tab completing them. Helper scripts are provided so that the present working directory of your shell can be automatically changed to the last directory you were on when you quit your terminal file manager. One might also set a keybinding in shell so that launching a terminal file manager is accomplished using a keybinding instead. As an alternative workflow, you can also launch a shell from inside the terminal file manager and then get back to your existing session when you quit the shell.

• Terminal file managers can provide a preview of the currently selected file or directory.

  This is to give you an idea about the current file or directory without opening it. In addition, terminal file managers can be integrated to your editor to preview or open files besides other file operations. This way, you would be using the same file manager in your shell and editor.

How is lf different than ranger?

ranger is the main influence for lf so they should look and feel very similar. Having said that, lf is not a ranger clone and there are many differences under the hood. Below are some of the major differences between lf and ranger. Note that this answer is highly likely to be biased towards lf and also some of the things mentioned here about ranger may not be fully accurate or up to date.

• lf is supported natively in Windows whereas ranger is not.

  This means that you can use lf with either cmd.exe or powershell. Note that there are still some rough edges in Windows as some features are designed with a Unix system in mind. However, these should get better in time especially if more Windows users show interest in the project.

• lf is a single binary without any runtime dependencies except for terminfo database whereas ranger is a Python application that requires an installation.

  lf uses termbox-go library for its ui, which includes terminfos of common terminals as builtin, so not even terminfo database may be necessary. On the other hand, having Python installed in a machine is often a reasonable dependency, although it can still be limiting at times. Most sysadmins, for example, need to deal with very old machines that have not been updated for a long time. These machines sometimes version of Python that is older than a decade. Also, in some embedded systems Python may not even be available at all. So there will always be some systems where ranger dependencies are not met. Binary formats on the other hand are usually much more stable. Simply copying lf binary to an executable path should be enough in most cases. Documentation is also bundled with the binary for this purpose.

• lf has a fast startup and low memory footprint due to native code and static binaries whereas ranger startup time is usually noticeable.

  Response times have a significant effect on the user experience. Whether it is a command running, a website loading, or getting search results, an extra 500ms can be enough to alienate users. One of the most important reasons unix commands are written in a native language is to have good performance and fast startup. lf is designed to completely replace ls and cd commands. With this in mind, lf is written in a native language and tries to stay lightweight. Features that have a chance to cause performance slowdown are turned off by default. These are mostly non-issues when you work on your laptop with an SSD drive but it can be important when you are working on a spinning disk or a network storage in which latencies are significant.

• lf uses a server/client architecture to share file selection among multiple instances whereas ranger is designed to work within a single instance for file operations.

  It is not uncommon for people to work on multiple terminals at the same time. This is achieved either by launching multiple terminals/tabs or by using a terminal multiplexer such as screen or tmux. A file manager should be able to work across these multiple instances for file operations. For this purpose, lf launches a server process in the background when you run it the first time. Server listens and records file selections so that you can copy files in one instance and paste in another.

• lf is configurable with shell commands whereas ranger is configurable with Python.

  For many people, shell is the most practical language to deal with files, so it makes sense to use it for scripting your file manager as well. lf implements a simple configuration syntax to let users define shell commands and optionally assign keys to these commands. Different types of commands are provided to be able to see the output after the command finishes or run the command asynchronously. Current file or selected files are passed as environment variables to be used in these shell commands. Remote commands are implemented to be able to alter the internal state of lf within these shell commands. Learning curve of these features should be minimum, so users familiar with shell can start scripting in no time.

• ranger has more user friendly features whereas lf skips some tricky features that are difficult to maintain.

  Copying files may sound easy at first but one needs to consider many edge cases to get it right at all times. For this reason, go language does not include a file copying function in its standard library. For the same reason, lf delegates file copying and moving operations to the underlying cp and mv commands (robocopy on windows). Consequently, since these commands do not include backup options in POSIX standard, lf simply tries to skip existing files by default to comply with the standard. Similarly, lf does not show a progress bar for file copying by default. Note that it is still possible to use the backup option of cp and mv if you have the GNU implementations and show progress information supplied by rsync by altering the default file copying implementation. Another feature that is currently on hold in lf is monitoring the file system for changes to update the file list automatically. Each operating system have a different implementation for file system monitoring and go language does not provide a common api in the standard library for maintenance reasons.

• ranger has more things builtin whereas lf is more barebones.

  Among some major features, builtin bookmark support is still missing in lf and users are expected to write custom commands or use an external tool if they need bookmarks. Apart from this, ranger comes bundled with its own file opener named rifle whereas lf requires an an external tool to manage file associations and open files. ranger also comes with many predefined commands for common operations such as renaming a file or creating a directory whereas lf users are expected to directly use corresponding shell commands for these operations or define their own commands. While these things may not be direct advantages or disadvantages for all, they may provide a better out-of-the-box experience to ranger users.

• ranger is more mature whereas lf is still in development.

  Many things still change frequently in lf which may require users to modify their configurations. There may also be occasional obvious bugs in lf especially in newer features.