Clifm: a file manager that is a command line, not a TUI
💾 The shell-like, command-line terminal file manager
At a glance
- What is it?
- Clifm is a C file manager that replaces the panel-and-keystroke model with a shell-like prompt. The design is coherent and the compatibility claims are unusually specific, but the same choice that makes it fast on a VT102 makes it a poor fit for anyone who wants a visual directory pane.
- Who is it for?
- Adopt clifm if you already live in a shell, want file operations to be composable commands rather than keystrokes, and need something that runs on a bare console or over SSH. Skip it if you want a two-pane visual browser or if your file work is mostly drag-and-drop-style browsing, because clifm deliberately has no panels or menus to fall back on.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly C, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem clifm picks: file management without leaving the shell prompt
Most terminal file managers reproduce a graphical file manager inside the terminal. They draw panels, bind keys to navigation, and expect you to move a cursor. Clifm takes the opposite position. The README states it has no GUI, no TUI, and no menus, and that the interface is a command line where you type file operations the way you would type shell commands. The target user is someone who already thinks in commands. If you routinely chain find, xargs, and mv, the friction clifm removes is the context switch between a shell and a separate file browser. It also targets environments where a full-screen interface is impractical: the README claims it can run on a kernel built-in console, over SSH, and even on a DEC VT100, and that it works on terminals with eight colors and no Unicode support. That is a narrower and more honest claim than general terminal compatibility, and it is the clearest statement of who the project is for.
Entry list numbers and short commands: the actual interaction model
The mechanism that makes a command-line file manager usable is the entry list number, or ELN. The README lists ELNs as a feature and links to a wiki section on them. The idea is that each item in the current directory gets a number, and commands operate on those numbers instead of on typed paths. That is the piece that distinguishes clifm from running ls and mv by hand. Commands themselves are short, and the README says short and even one-character commands are supported. Bulk rename, bulk create, bulk remove, and bulk symlink creation are grouped under bulk operations in the feature list. File selection supports glob and regular expressions and, according to the README, works across multiple instances of the program. Search likewise supports glob and regular expressions. The data flow is therefore: list the directory, refer to entries by number or pattern, and issue a command that acts on the selection. Everything else in the feature list, including bookmarks, tags, filters, trash, and the file opener, hangs off that same prompt.
Installation and the config surface you actually touch
The README points to an installation section and to the wiki for documentation, and it links to an openSUSE Build Service package page for CliFM. The README does not inline a package-manager command in the portion available here, so the reliable path is the wiki's install page or your distribution's package. One concrete item does appear in the feature list: filters support a .hidden file, which is the project's own convention for hiding entries from the listing. That is a config file you create in a directory, not a flag you pass, and it is a good example of how clifm expects configuration to live alongside your files. The README also links a misc/tools/imgprev directory for image previews, which indicates previews are partly delivered as external tools rather than compiled into the binary. Beyond that, the available material describes configuration through wiki pages on colors, file opener, and autocommands rather than through a single documented config key list, so treat the wiki as the specification.
Plugins, autocommands, and what extensibility costs
Clifm exposes plugins, and the README cites file encryption and decryption as an example implemented as a plugin rather than as a built-in command. Autocommands are listed as a feature, which implies you can bind actions to directory entry events. This is a reasonable architecture for a program whose whole premise is that the command line is the interface: a plugin is just another program the file manager can invoke, and it inherits the same environment. The cost is that a plugin is only as portable as the interpreter or binary it calls. The encryption example in particular depends on external tooling that the README does not name in the material available here, so you cannot assume it works out of the box on a minimal system. The same applies to image previews under misc/tools/imgprev. If you adopt clifm on a stripped-down console machine, verify that the plugins you want have their dependencies present before you rely on them.
Where the CLI-only design becomes a liability
The README is direct that clifm does not need to be better than TUI file managers, only different, and that framing is accurate. The limitation follows from it. There is no panel view, so you cannot see two directories side by side and drag between them; you navigate and act through commands. For someone who browses unfamiliar directory trees by eye, that is slower, not faster. The compatibility claims cut the same way. Working on a VT100 or an eight-color terminal is an achievement, but it also means the interface cannot lean on color or Unicode to convey file type and state, so you are reading text output. The feature list is long, which raises a second concern: breadth in a single C binary usually means the surface area you must learn is large, and the material here describes most features by wiki link rather than by example. Nothing in the available material indicates a stable plugin API version, so a plugin written against one release may need attention after an upgrade.
How clifm differs from ranger and lf
Ranger and lf are the obvious comparison points, and the difference is structural rather than cosmetic. Both present a multi-column or two-pane view driven by keybindings, with a command line as a secondary input. Clifm inverts that: the command line is primary, and the listing is something you query. If you want to see where you are and what is next to it at a glance, a panel-based manager answers that question without typing. If you want to script a repeated file operation across a selection, clifm's ELN and pattern-based selection model is closer to the shell you already use. The README's own framing supports this reading: it calls clifm shell-like and says it sits on the command line, and it explicitly declines to claim superiority over TUI managers. That is a fair description of a real trade-off rather than marketing.
Licence, maintenance, and what to check before upgrading
The README displays a GPL2+ badge linking to the LICENSE file, but the repository metadata reports the licence as NOASSERTION. Those two signals disagree, and the practical consequence is that you should read the LICENSE file in the repository rather than trust either label. This is not legal advice; if you plan to redistribute clifm inside a product, have someone qualified confirm the terms. On maintenance, the release history shows v1.27 and v1.27.1 in January 2026 and v1.28 in May 2026, with the last push to master in September 2026. That is a cadence of a few releases per year, not a weekly churn, which is normal for a project of this size and language. The upgrade cost is concentrated in configuration and plugins rather than in the binary: because behavior is configured through files like .hidden and through wiki-documented settings, a point release can change what a config file means without changing the command name. Read the release notes for the version you are moving to, and check whether any plugin you depend on has been updated for it.
Editorial conclusion
Adopt clifm if you already live in a shell, want file operations to be composable commands rather than keystrokes, and need something that runs on a bare console or over SSH. Skip it if you want a two-pane visual browser or if your file work is mostly drag-and-drop-style browsing, because clifm deliberately has no panels or menus to fall back on. Before committing, read the wiki page on the command syntax and confirm the specific version your distribution packages, since the README's feature list is broader than any single release note and the license field on the repository reads NOASSERTION even though the README carries a GPL2+ badge.
Community notes