What must I do to have stow only linking the binaries (and maybe the man pages) correctly?

I want to use GNU stow to manage local installs on my machine. However, stow does not simply symlinks the binary, but all files in the program folder. What I did so far:

  • created an extended stow-ignore file
  • use a subfolder src/ where all files except the binary go and manually change the Makefile to create a bin/ subfolder. Then later delete the linked local/src/ folder

I guess there must be a better way and I am using stow wrong.


Folder structure

   |+bin/     <-- binarys should go here
   |+share/   <-- man page

From here I would go into the stow/ folder type

stow dwm-6.0

Then stow links all files into the local/ folder, instead of only the binary dwm into the local/bin/ folder. I can now change the Makefile so it creates a dwm-6.0/bin/ folder and moves the binary in there. Then stow at least will link dwm to local/bin/, but still all other files are linked to local/ as well.

The same goes for hub:

[9962]../stow:$stow hub-1.11.1
Loading defaults from .stowrc
stow dir is /home/myusername/local/stow
stow dir path relative to target /home/myusername/local is stow
Planning stow of package hub-1.11.1...
LINK: man => stow/hub-1.11.1/man
LINK: test => stow/hub-1.11.1/test
LINK: hub.gemspec => stow/hub-1.11.1/hub.gemspec
LINK: script => stow/hub-1.11.1/script
LINK: etc => stow/hub-1.11.1/etc
LINK: lib => stow/hub-1.11.1/lib
LINK: hub => stow/hub-1.11.1/hub
LINK: bin/hub => ../stow/hub-1.11.1/bin/hub
LINK: git-hooks => stow/hub-1.11.1/git-hooks
LINK: Rakefile => stow/hub-1.11.1/Rakefile
LINK: Gemfile => stow/hub-1.11.1/Gemfile
LINK: features => stow/hub-1.11.1/features
Planning stow of package hub-1.11.1... done
Processing tasks...
Processing tasks... done

Now stow even links the man files to a separate folder instead of using share/



# Comments and blank lines are allowed.


\.\#.+       # CVS conflict files / emacs lock files



.+~          # emacs backup files
\#.*\#       # emacs autosave files
.*\.c        # c src files 
.*\.cc       # c++ src files 
#.*\.\d       # compile temporary files 
#.*\.\d\..*       # compile temporary files 
.*\.o        # object files
.*\.h        # include files
.*\.mk       # make configs
.*\.swp      # vim temp buffer file
.*\.lock     # vim temp buffer file
.*\.md       # mark down 
.*\.yml      # YAML
#.*\.gemspec  # gem file
#.*\.rb       # ruby file
#.*\.sh       # shell file
#.*\.feature  # shell file



3 Answers 3


One approach would be to use local ignore lists, one per package.

However, I believe your approach is fundamentally the wrong one which is making your life unnecessarily hard. The problem is that you are not distinguishing between files needed at build-time vs. files needed at run-time. Directories like ~/local/stow/dwm-6.0/ are package directories which are supposed to contain installation images, not source code or other resources only intended for use at build-time.

The correct workflow is as follows:

  1. Download the source code into a directory totally ignored by Stow (e.g. ~/src).
  2. Build and install from the source into ~/local/stow/dwm-6.0/ (the manual has lots of tips on how to achieve this)
  3. Verify that ~/local/stow/dwm-6.0/ only contains directories files required at runtime (files under bin/, man/ etc.)
  4. stow dwm-6.0
  • Adam, thanks alot for your help and sorry for my late reply. However, i still find this construct somewhat unsatisfactory. If for each software i have to manually rewrite the Makefile to build, e.g., from local/src/dwm to /local/stow/dwm-6.0/ and then stow dwm. I could skip stow by modifying the Makefile to just directly build from local/src/dwm to local/bin/... Then using stow only makes sense to me if one is to use different versions of the same software. Or do i miss something here?
    – Da Frenk
    Jun 3, 2014 at 14:56
  • You could do that, and you're sort of right, but that would force you to rely on the package's uninstallation process being 100% correct, and you would have to also remember exactly how to uninstall because each package will do it different. It's cleaner to keep the installation image separate from the target tree, and then Stow gives you a standard way to uninstall any package. Jun 3, 2014 at 16:14
  • I guess my simple use-case for local installs just doesn't fit for stow, as now I don't see any upsides for the uninstall process either. Following your steps 2. and 3. the user has to already know manually which directories & files are required at runtime... or?
    – Da Frenk
    Jun 3, 2014 at 16:24
  • I'm not sure why you think the user has to know that, but please can we continue the conversation on help-stow where it belongs? Jun 3, 2014 at 19:43

See B. Comnes' 10/10/14 blog entry "GNU Stow Include Files". To sum it up, the regex:


in the global ignore list will stow "only" those (bin, include, etc.) directories.


It looks like you're stowing directories with source code in them.

Use configure (or whatever build system the software is using) and set an installation prefix under the stow directory instead. Run the make and make install, and then stow the installed program.

That was how stow was meant to be used...

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .