nautilus-scripts: right-click actions for the Linux desktop file managers

One set of actions, six file managers

nautilus-scripts is a set of actions for extending the functionality of the GNOME Files file manager, and the same set works with Nemo, Caja, Dolphin, Thunar, and PCManFM-Qt. The project describes itself as a set of file manager actions that enhance your workflow, with useful right-click options to simplify common tasks across GNOME, KDE, Xfce, and more.

That cross-desktop reach is the interesting part of the design. Each of those file managers has its own extension mechanism. Nautilus has its own script directory and its own menu integration, Nemo has a different one, Dolphin has a plugin and a script mechanism of its own, and Thunar and Caja have their own again. A script written for one of them usually does not work in the next.

This repository solves that by writing the actions once, in shell, and by installing them into the right place for each file manager. The scripts are the same code, the differences are in the integration layer, and the compatibility table in the documentation is a list of what each of them supports.

The operations themselves are the ones a file manager tends to leave out. There is a category for archive handling, one for audio and video, one for checksums, one for the clipboard, one for directories and files, one for documents, one for encryption, one for images, one for links, one for network and internet, one for opening a file with a chosen program, one for renaming files, and one for security and recovery. The taxonomy is a folder layout rather than a list in a document.

The project is MIT licensed, the last push was on 2026-10-22, and the release numbers move often, with three releases in two days, two on 2026-10-19 and one on 2026-10-17. The supported desktops are listed on a badge as GNOME, KDE, MATE, Xfce, Cinnamon, and LXQt.

Installing, online or from a clone

There are two installation routes, and the online one is the recommended one.

The online route pipes a script straight into a shell, and there are two spellings of it, one for curl and one for wget. You are told to choose one of them.

bash -c "$(curl -fsSL https://cfgnunes.github.io/nautilus-scripts/install.sh)"

bash -c "$(wget -qO- https://cfgnunes.github.io/nautilus-scripts/install.sh)"

The local route is for people who have already cloned the repository, and it is a single command.

bash install.sh

There is an uninstall script in the repository as well, which is the detail that matters about the online route. A script fetched over the network and run with a shell has to be able to undo itself, and the presence of a matching uninstall file says that this is a supported expectation rather than a hope.

The installer is also where the category based installation happens. You choose which script categories you want installed, so there is no need to install everything, and that is a sensible default for a set of scripts this size, since each one is a separate file in a separate directory.

Two more things happen at install time. The scripts need dependencies, and the installer prompts the user to install any that are missing, which is friendlier than a script failing halfway through with a missing command. And the messages are localised, because the scripts detect the system language and display their messages in it.

What the scripts do, and how they are organised

The keyboard accelerator table is the best catalogue of the actions, because it lists every one of them with the key that triggers it.

The single key bindings are the short ones. F4 opens a terminal, and adding shift opens one with synchronised panes. F7 opens a code editor, and F12 runs a disk usage analyser.

Then come the compression actions, and the choice of formats is the point. There are separate bindings for compress to tar.gz, to tar.zst, to tar.xz, and to zip, which covers the two compression approaches people actually argue about, the gzip family and the zstd family, plus the two archivers that are not tar based.

The inspection actions are the ones that make this more than a convenience set. There is show file information, show file metadata, find empty files, find empty directories, find junk files, find duplicate files, list hidden files, list permissions and owners, list largest files, and list recent files. A file manager that can find duplicates and list the largest files in a tree covers two chores that otherwise need a disk analyser and a lot of patience.

Then there is extract here, copy file names, compare items, and compute all checksums.

The version control and network actions are the two that reach outside the file manager. There is a git clone URLs action, and a git reset and pull action that runs on a repository. There is a URL download file action, and paste as hard link and paste as symbolic link, plus paste clipboard contents.

The file system helpers sit in the middle. There is open item location, which opens the containing directory, and create backup via Rsync, which makes a copy of a selection rather than moving it.

That is roughly thirty actions, and they are grouped into the same thirteen directories the repository uses, so the folder layout is the documentation.

The compatibility matrix, and the levels of integration

The compatibility table is the most useful thing in the documentation, and its structure is what makes it useful. There are five integration levels, not one boolean.

The columns are the file manager and its desktop environment, then menu integration, application shortcuts, keyboard accelerators, and a menu for recently accessed scripts.

GNOME Files, Nemo, and Caja have everything. All three are full. The three of them are also the three file managers whose extension mechanism is a script directory that the file manager reads and offers in the context menu.

Thunar, Dolphin, PCManFM-Qt, and PCManFM have the menu integration and the application shortcuts, and then the differences start. Thunar has the keyboard accelerators but not the recently used menu, and the other three have neither.

So there are three tiers in practice. Three file managers with everything, one with the accelerators but not the recent menu, and three with the menu and the shortcuts only.

The reason for the split is a property of the host applications rather than of the scripts. An application shortcut is a desktop entry, so it can be registered from the installer for any of them. A keyboard accelerator is a desktop key binding, and only some of these file managers can be told about one from outside. The recently used menu needs the file manager to keep state about which scripts have been run, which is the most specific of the three and the one that only the script based file managers expose.

Reading the table this way tells you which file manager to use if the accelerators matter to you, and it tells the maintainer exactly which integration work is worth doing next.

Batch mode, and the argument list problem

The last section of the documentation solves a specific problem that appears only when you have a lot of files selected, and the solution is unusual enough to be worth understanding.

The problem is the shell's limit on the length of an argument list. When a file manager runs a script on a selection, it passes the selected paths as arguments, and with a very large selection, ten thousand input files being the example given, that argument list becomes too long for the shell to accept, and the action fails with an argument list too long error.

The workaround is a convention rather than a flag. You place all the input files in a folder whose name contains the word batch, and then you run the action on that folder. The scripts notice the folder name, and instead of expanding the selection into arguments, they process the files one at a time.

That has two consequences worth thinking about. The first is that the batch mode is a different code path, and it is slower per file than the parallel path, because the whole point of the parallel execution is to overlap the work. The second is that the convention is in the folder name, so the operation is not available on an arbitrary selection, and a user who has never read the documentation will hit the error and not know why.

The parallel execution is the other feature the batch mode is trading against. The documentation describes it as processing multiple files simultaneously and calling it very fast, and that is what makes the set of scripts usable for the operations where you have selected a lot of files, such as checksumming or compressing a whole tree.

Editorial conclusion

nautilus-scripts fits a Linux desktop user who lives in the file manager and wants the operations that a terminal does better available from the right-click menu, especially across a mixed desktop environment where a script written for one file manager usually breaks in the next. It does not fit a user on a file manager outside the supported list, and the keyboard accelerators and the recently used menu are not universal. Verify first which of the five integration levels your file manager supports in the compatibility table, that the dependencies the scripts need are present or that the installer's prompt for them is acceptable to you, and that the batch mode is what you want before selecting ten thousand files, since the folder-name convention it uses changes how you invoke the action.

Frequently asked questions

Official sources

1. cfgnunes/nautilus-scripts on GitHub
2. Issues
3. License: MIT
4. README
5. Releases