clifm: a command-line file manager for people who never wanted a TUI
💾 The shell-like, command-line terminal file manager
At a glance
- What is it?
- clifm replaces the two-pane terminal file manager with a shell-like prompt, ELNs and short commands. It is fast, portable and unusual, but it is not a drop-in replacement for lf, yazi or superfile.
- Who is it for?
- Adopt clifm if you already live in a shell, want file operations typed rather than navigated, and care about running on old hardware, remote sessions or VT102-era terminals. Skip it if you want a persistent two-pane view or a mouse-driven interface, because the README is explicit that there is no GUI and no TUI.
- 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 last received commits 1 day ago.
- 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 30, 2026, and from our analysis. They are not legal advice.
Editorial analysis
What clifm solves, and who it is actually for
Terminal file managers usually fall into one shape: a full-screen text user interface with panes, a cursor and keybindings. clifm takes the opposite position. The README describes it as "a shell-like, text-based terminal file manager that sits on the command line" and states plainly that there is "No GUI, no TUI, and no menus: just you and a powerful, file-management-oriented command line." You type commands at a prompt instead of moving a selection through a list.
The intended user is someone who already thinks in shell commands and finds pane navigation slower than typing. clifm adds file-specific verbs on top of that habit: bookmarks, file selection, tags, filters, previews, bulk rename, archiving, trash, a file opener, a directory jumper, workspaces, plugins and autosuggestions. The README's own framing is that clifm "does not need to be better: it's just different," which is a fair summary of the trade-off rather than marketing.
The second audience is hardware and environments. According to the README, clifm runs on the kernel built-in console, over SSH or any remote session, and is "highly compatible with old VT102-only terminal emulators like Rxvt and Rxvt-based ones." It claims to work on a terminal with only 8 colors and no Unicode support, and the wiki documents it running on a DEC VT100. That is a narrower claim than "lightweight", and a more useful one.
How the CLI design works in practice
The mechanism is a persistent prompt rather than a screen. You stay in a working directory, type a command, and the directory listing is redrawn. Two features carry most of the interaction weight.
Entry list numbers (ELNs) assign a number to each filename in the current listing, so you can refer to a file by number instead of typing or completing its name. The README links this under Common Operations. Short commands, including one-character commands, are the other half: the wiki's command summary is the reference for what each letter does. Together they mean the common case is a number plus a letter rather than a path.
File selection is the piece that makes this more than a shell alias. The README states that selection supports both glob and regular expressions and "works even across multiple instances of the program", so a selection made in one clifm session is visible to another. That is a different model from a shell's argument list, which dies with the command.
Beyond that, the README lists file tags, file filters (including support for `.hidden` files), file previews with image previews, a file opener that discerns between GUI and non-GUI environments, bulk operations for rename, create, remove and symlink creation, a Freedesktop-compliant trash system, copy(-as) and move(-as), interactive rename, open-with, and a filenames sanitizer. File encryption and decryption is listed as a plugin rather than a built-in, and plugins are the documented extension point.
Installing clifm and running a first session
The README points to its Installation section and the repository ships a Makefile. The Makefile detects the operating system with `uname -s` and links a different library set per platform, so the build depends on what you already have installed. On Linux the Makefile uses `-lreadline -lacl -lcap -lmagic`; on BSD and Darwin the lists differ, and Darwin expects Homebrew or MacPorts paths such as `/opt/homebrew/opt/readline/include`.
Build and install with the default prefix of `/usr/local`:
make
sudo make installThe Makefile's `install` target places the binary in `$(BINDIR)` and creates `$(PROG_DATADIR)`, man pages under `$(MANDIR)/man1`, and bash completion under `$(DATADIR)/bash-completion/completions`. If you want a different prefix, the Makefile exposes `PREFIX`, so `make PREFIX=$HOME/.local install` is the shape to use, with `DESTDIR` available for staged installs. The README also links an openSUSE Build Service package, which is the only prebuilt route the README shows.
Once installed, start it by name:
clifmYou land at a prompt in your current directory with a numbered listing. From there the workflow is typing short commands. The README documents `n` for new (with file templates), `bb` for the filenames sanitizer, `ow` for open-with, and `c`, `l`, `e`, `edit`, `m`, `md`, `r` for the copy, list, edit, move, make-directory and remove family. Because the commands are short and documented on the wiki rather than in the README, expect to keep the wiki open for the first hour. That is a real cost, not a formality.
Where clifm is the wrong tool
The absence of a TUI is not a neutral design choice. If your work involves comparing two directories side by side, dragging a selection across a long listing, or handing a terminal to someone who has never used a shell, clifm offers nothing. The README does not document a two-pane mode, and it should not be expected to grow one: the design goal is the opposite.
There is also a command-memory cost. A pane-based manager shows you what you can do; clifm requires you to recall it. Autosuggestions soften this, but the README positions them as one feature among many, not as a discovery interface.
Build complexity is a second boundary. There is no documented package for every distribution. The Makefile's Darwin branch hardcodes Homebrew and MacPorts include and library paths, and the BSD branches expect `/usr/local` or `/usr/pkg` layouts. If your system deviates from those assumptions, you are editing the Makefile.
Finally, the licence metadata is worth reading yourself. The repository's licence field reports NOASSERTION, while the README carries a GPL2+ badge and links a LICENSE file. Those two signals do not contradict each other necessarily, but a project that matters to your organisation deserves a look at the actual LICENSE text rather than the badge.
How clifm differs from lf, yazi and superfile
The honest comparison is architectural, not feature-by-feature. lf, yazi and superfile are TUI file managers: they own the terminal screen, draw panes, and you move a cursor. clifm does not own the screen. It behaves like a shell that happens to know about files, which is why the README can claim it runs on the kernel console and on a VT100. A TUI needs cursor addressing and a redraw model; a line-oriented prompt needs much less.
That difference explains the rest. Yazi's tab handling, lf's editor integration and superfile's layout are all things a screen-owning program can do well and a prompt cannot. Conversely, clifm's selection surviving across instances, its ELNs, and its one-character commands are conveniences that come from treating the filesystem as arguments rather than as a visual list.
If you are choosing between them, the question is not which has more features. It is whether you want a program you look at or a program you type at. clifm is the second kind, and it is the most committed example of that position among the projects named here.
Maintenance, upgrades and the licence question
The repository is not archived and its last push was on 2026-09-09, so it is being worked on. Recent releases are v1.28 on 2026-05-28, v1.27.1 on 2026-01-10 and v1.27 on 2026-01-07. That cadence, roughly a few releases a year, is normal for a single-maintainer C project and means you should not expect rapid breaking changes.
Upgrade cost depends on how you installed it. A source install means re-running `make` and `sudo make install` and watching for new library requirements in the Makefile's per-OS `LIBS_` variables. The README does not document a rollback path or a version pinning mechanism, so keeping the previous binary before overwriting it is your own responsibility. If you installed from the openSUSE Build Service package, upgrades follow that channel instead.
On licensing: the README shows a GPL2+ badge and links a LICENSE file, while the repository metadata reports NOASSERTION. GPL2+ would carry copyleft obligations if you redistribute a modified binary. This is not legal advice; read the LICENSE file in the repository and decide with whoever handles licensing where you work.
Editorial conclusion
Adopt clifm if you already live in a shell, want file operations typed rather than navigated, and care about running on old hardware, remote sessions or VT102-era terminals. Skip it if you want a persistent two-pane view or a mouse-driven interface, because the README is explicit that there is no GUI and no TUI. Before committing, read the wiki pages for the commands you use daily, check the Makefile's per-OS library list for your platform, and confirm the LICENSE file's exact terms, since the repository metadata reports the licence as NOASSERTION while the README badge shows GPL2+.
Frequently asked questions
Is clifm a safe app to use as a file manager?
The README claims a secure environment and secure commands, plus a stealth mode, and states there is zero data collection and no connection to the outside world. It does not publish an independent audit, so treat those as design claims from the project rather than verified guarantees.
Is the CLI still used today, and why would I use clifm instead of a graphical file manager?
That is a general question rather than one about clifm, but the project's own answer is in its README: it runs on the kernel built-in console, over SSH or any remote session, and works on terminals with only 8 colors and no Unicode support, including old VT102 emulators.
How do I open a file from the command line in clifm?
The README lists an open-with function, documented on the wiki under the `ow` command. The file opener supports regular expressions and, according to the README, is able to discern between GUI and non-GUI environments.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/leo-arch-clifm)