scrot: a command line screen capture tool, and how it was rescued

A capture tool built for scripts

scrot is a simple command line screen capture utility, and it works by using imlib2 to grab and save images. The feature list is short and each item is about output rather than interaction. It supports several image formats, including JPG, PNG and GIF, and anything else that Imlib2 supports, which means the format set is inherited from the imaging library rather than hard coded in scrot. The quality of the screenshot is configurable, so a PNG for documentation and a small JPEG for a quick paste do not need different tools.

The more useful capability is the targeting. It is possible to capture a specific window, or a rectangular area on the screen, rather than always taking the whole display. That is the difference between a tool you run by hand and a tool you put in a script, and the project is explicit that because it is a command line utility it can easily be scripted and put to novel uses. The example it gives is monitoring an X server in the absence, which is the kind of job that a screenshot tool with no interface is unusually good at: run it on a timer over a session you are not watching and collect the images.

How a dead project came back to life

The history is unusual enough to be worth knowing, because it explains the shape of the repository. The original scrot was developed by Tom Gilbert, and it went unmaintained. The source of the last version, 0.8, was imported from a Debian snapshot, and after that, patches from Debian and elsewhere were applied to create the 0.9 release. The details of the releases are registered in a ChangeLog file in the repository root.

From there the project was taken on by volunteers organised under the Resurrecting Open Source Projects umbrella, and the current releases come from that group. The versions since then have moved quickly, with 1.12 published in March 2025, 1.12.1 in April 2025 and 2.0.0 in March 2026, and the last push to the repository was on 2026-10-16. A project with a 2.0 release after a gap of unmaintained years is a good example of what the resurrection model produces: nothing spectacular, but a maintained tree again. The licence is described as MIT-feh, which is a custom variant of the MIT licence, and the licence text sits in a file called COPYING.

Installing from the distribution first

The project recommends using the system package manager, and it says scrot is available in the official repository of many Linux and BSD distributions. For Debian the documented command is a single install:

$ sudo apt install scrot

There is a list of repositories that package scrot on the Repology project, which is the place to look if you are on a distribution the project notes do not mention. The recommendation to use the distribution package rather than a source build is not unusual advice, but it matters more here than usual, because scrot pulls in a stack of X11 libraries and a rebuilt imlib2 is a chore that a package manager has already done for you.

The build instructions exist for the case where your distribution does not package scrot, and they are complete rather than a sketch, which is a sign of a project that takes its release process seriously.

Building from source when nobody packages it

The dependency list is the first thing to read, because imlib2 has to be built with X support, and several of the others are only needed in unusual situations. autoconf and autoconf-archive are build time only, as is a pkg-config implementation such as pkgconf. imlib2 must be built with X support. libbsd is only needed if the header err.h is missing on your system. Then there is an X11 implementation such as X.Org, and the X composite, fixes and randr libraries, all of which come from the X.Org tree. A file called deps.pc in the repository root documents the minimum version requirements for some of those libraries, which is the file to check before you blame a compile error on your distribution.

The build itself is the standard autotools sequence, and the first step is the one people miss. A git checkout does not contain a configure script, so it has to be generated:

$ ./autogen.sh

After that, the configure and make step is the usual one:

$ ./configure && make

And installation can be done as root with the plain target, or as a regular user with sudo in front of it:

# make install

$ sudo make install

The cleanup targets that catch people out

A small tool that ships four cleanup commands is a hint that the build is autotools based and that people lose track of the state of a checkout. Cleaning the build artefacts is one command:

$ make clean

To remove all the pre-built files, including the configure script itself, the target is distclean:

$ make distclean

And to get back to a pristine source tree before running configure at all, the autogen script takes a clean argument:

$ ./autogen.sh clean

The distinction between clean and distclean is the one to remember. Clean leaves the generated configure script in place, distclean removes it, and autogen.sh clean is the reset that puts the checkout back the way it was cloned. If you have patched a tarball and then changed your mind, the last one is the escape hatch. Shell completion for Bash and Zsh is provided in the etc directory, which is a small convenience that most distributions package along with the binary anyway.

What the repository actually contains

The top level tells you this is a classic autotools C project. There is a configure.ac and a Makefile.am rather than a hand written build system, an autogen.sh wrapper, the deps.pc file for version requirements, and the usual metadata files: an AUTHORS file, a ChangeLog, a FAQ, a TODO, a COPYING with the licence text and a contributing guide. The code lives in src/, the manual page in man/, the completion scripts and other resources in etc/, and there is a doc directory holding the project image.

The tooling around it is worth a mention too, because a resurrected project usually inherits whatever the new maintainers bring with them. A clang-tidy configuration file is present for static analysis, and a Cirrus configuration file suggests continuous integration on a BSD as well as the GitHub workflows. Neither of those guarantees anything about the code, but both indicate a project with modern habits around a codebase that predates them. The last push was on 2026-10-16 and the most recent release is 2.0.0 from 2026-03-14, so the tree is active even though the release cadence is measured in months rather than weeks.

Editorial conclusion

scrot fits a shell script or a remote session that needs a picture of the screen without a desktop application, and it fits a user who wants a specific window or a region rather than a whole display, because both are first class options. It is the wrong choice if you are on Wayland, since the dependencies are the X11 libraries and the X composite, fixes and randr extensions, and it is the wrong choice if you need something maintained by an organisation with a support desk, since the work is done by volunteers. Before you build it yourself, check whether your distribution already packages it, because the project recommends the system package manager and the packaging list is the quickest route, and read the licence file rather than assuming, because the project describes itself as MIT-feh, which is a variant with its own terms. If you do build from source, remember that a checkout has no configure script until you run autogen.sh, and that the minimum library versions are recorded in deps.pc.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. resurrecting-open-source-projects/scrot on GitHub