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.

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 tcell 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 have a 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 and remote commands to manage 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 can notify other clients with remote commands so that you can copy files in one instance and paste in another.

• lf is extendable and configurable with shell commands whereas ranger mostly uses 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 things builtin whereas lf is more barebones.

  Among some major features, ranger comes bundled with its own file opener named rifle whereas lf requires an external tool to manage file associations and open files. ranger also comes with many predefined commands for common operations such as 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.

Builtin commands for most file operations are left out in favor of their shell counterparts. For example, there is no builtin :mkdir command and users are meant to use $mkdir or %mkdir instead. lf has features to make the use of these underlying shell commands as easy as possible. For example, piping shell commands are used to avoid ui flicker and show any errors in the ui (i.e. %mkdir), :push is used to keybind these commands to avoid typing (e.g. map a :push %mkdir<space>), and completion works with shell commands for when there is no dedicated keybinding (e.g. %mkd<tab>). Such direct use of the shell brings the benefits of shell to lf. For example, you can create multiple directory with a single command (e.g. %mkdir foo bar), use brace expansions if you have bashism (e.g. %mkdir foo-{bar,baz}), and use the usual shell idioms when you need more power (e.g. %seq 10 | xargs -I{} mkdir foo-{}). In a way, having easy access to the shell is the most powerful feature of lf.

Currently, there are some exceptions to this rule:

• There is a builtin :delete command because it is useful to have a prompting mechanism by default for safety and single letter prompts without enter key can be complicated in shell commands.

• There is a builtin :rename command because it is useful to have a prompting mechanism by default for safety and keeping the current name in the prompt can be complicated in shell commands.

Currently, there are no builtin commands for mkdir, touch, chmod, chown, chgrp, and ln. Feel free to open an issue for discussion if you think there is a strong rationale for having a builtin command for a command from this list or elsewhere.

There are numerous examples of possible configurations for such operations in the Tips section of the Wiki.