## 1 Introduction

GNU Stow is a symlink farm manager which takes distinct sets of software and/or data located in separate directories on the filesystem, and makes them all appear to be installed in a single directory tree.

Originally Stow was born to address the need to administer, upgrade, install, and remove files in independent software packages without confusing them with other files sharing the same file system space. For instance, many years ago it used to be common to compile programs such as Perl and Emacs from source and install them in `/usr/local`. When one does so, one winds up with the following files1 in `/usr/local/man/man1`:

    a2p.1
    ctags.1
    emacs.1
    etags.1
    h2ph.1
    perl.1
    s2p.1

Now suppose it’s time to uninstall Perl. Which man pages get removed? Obviously `perl.1` is one of them, but it should not be the administrator’s responsibility to memorize the ownership of individual files by separate packages.

The approach used by Stow is to install each package into its own tree, then use symbolic links to make it appear as though the files are installed in the common tree. Administration can be performed in the package’s private tree in isolation from clutter from other packages. Stow can then be used to update the symbolic links. The structure of each private tree should reflect the desired structure in the common tree; i.e. (in the typical case) there should be a `bin` directory containing executables, a `man/man1` directory containing section 1 man pages, and so on.

While this is useful for keeping track of system-wide and per-user installations of software built from source, in more recent times software packages are often managed by more sophisticated package management software such as `rpm`, `dpkg`, and Nix / GNU Guix, or language-native package managers such as Ruby’s `gem`, Python’s `pip`, Javascript’s `npm`, and so on.

However Stow is still used not only for software package management, but also for other purposes, such as facilitating a more controlled approach to management of configuration files in the user’s home directory2, especially when coupled with version control systems3.

Stow was inspired by Carnegie Mellon’s Depot program, but is substantially simpler and safer. Whereas Depot required database files to keep things in sync, Stow stores no extra state between runs, so there’s no danger (as there was in Depot) of mangling directories when file hierarchies don’t match the database. Also unlike Depot, Stow will never delete any files, directories, or links that appear in a Stow directory (e.g., `/usr/local/stow/emacs`), so it’s always possible to rebuild the target tree (e.g., `/usr/local`).

Stow is implemented as a combination of a Perl script providing a CLI interface, and a backend Perl module which does most of the work.

For information about the latest version of Stow, you can refer to http://www.gnu.org/software/stow/.

#### Footnotes

##### (1)

As of Perl 4.036 and Emacs 19.22. These are now ancient releases but the example still holds valid.

##### (2)

http://brandon.invergo.net/news/2012-05-26-using-gnu-stow-to-manage-your-dotfiles.html

##### (3)

http://lists.gnu.org/archive/html/info-stow/2011-12/msg00000.html