I'm running Stow on Guix where /usr/local does not exist by default. Considering that Stow is now frequently used for managing .dotfiles, would it make sense to make the default target directory the users home directory instead? That will probably always exist no matter the distribution. Alternatively, does a default target directory need to be set at all?

Once /usr/local/stow starts filling up with packages, it is useful to organize packages into categories under /usr/local/stow, eg Audio, Desktop, Utilities, Video etc

If packages under these sub-directories, which of course should get marked as being STOW directories with the presence of a .stow file, contain common target directories, then these should be folded/unfolded as appropriate on stowing and unstowing.

However when find_stow_path is called with the path to a target link to be changed in a sub-directory, it returns the name of the package as just the sub-directory category name eg Audio, or Desktop or whatever and not the category plus package name relative to the top stow directory. Of cours unlinking/mkdir then fails because the combined full stow path is wrong as it does not contain the actual package name and thus does not exist, causing stow to exist with the error message that it was called with non-directory path.

This is rectified with the following patch to Stow.pm for find_stow_path

--- Stow.pm.ORIG       2014-10-28 21:02:46.397092559 +0100
+++ Stow.pm            2014-10-28 21:02:46.397092559 +0100
@@ -911,7 +911,7 @@
                 if $i == $#path;

             debug(4, "    yes - $dir was marked as a stow dir");
-            my $package = $path[$i + 1];
+            my $package = "$path[$i + 1]/$path[$i + 2]";
             return ($path, $dir, $package);
         }
     }

Just received advice from [email protected]:

• License needs to be upgraded to GPL v3
• "Many files are lacking a copyright notice and/or a license notice. It is important that every file (except trivial files less than 15 lines or so) contain both a copyright notice and a license notice"

See also #47 (Move manual to GNU FDL (Free Documentation License)).

Hello,I meet a problem about an error is reported during the execution of self-test cases.

Steps to reproduce the issue

[root@centos8 stow]# ls
aclocal.m4  autom4te.cache  bin       ChangeLog   config.status  configure.ac  default-ignore-list  INSTALL.md  Makefile     Makefile.in  MANIFEST.SKIP  META.yml  README.md             t       TODO
AUTHORS     automake        Build.PL  config.log  configure      COPYING       doc                  lib         Makefile.am  MANIFEST     META.json      NEWS      removed_la_files.txt  THANKS
[root@centos8 stow]# make check
[ -d bin ] || mkdir bin # required in vpath mode

# Perl modules will be installed to /lib/site_perl/5.32.1
#
# This is in /home/spack/spack/opt/spack/linux-centos8-aarch64/gcc-8.3.1/perl-5.32.1-2s3unjl3vzun64kvy54peyqyutnjf7m5/bin/perl's built-in @INC, so everything
# should work fine with no extra effort.

Generated bin/stow from bin/stow.in
chmod +x bin/stow
Generated bin/chkstow from bin/chkstow.in
chmod +x bin/chkstow
Generated lib/Stow.pm from lib/Stow.pm.in and ./default-ignore-list
Generated lib/Stow/Util.pm from lib/Stow/Util.pm.in
make  tmp-testing-trees
make[1]: Entering directory '/tmp/root/spack-stage/spack-stage-stow-2.3.1-file4ivvcsvkwadvhc7qluufgxkqltvt/spack-src'
mkdir -p tmp-testing-trees
make[1]: Leaving directory '/tmp/root/spack-stage/spack-stage-stow-2.3.1-file4ivvcsvkwadvhc7qluufgxkqltvt/spack-src'
make  check-TESTS
make[1]: Entering directory '/tmp/root/spack-stage/spack-stage-stow-2.3.1-file4ivvcsvkwadvhc7qluufgxkqltvt/spack-src'
dir=./t; \
/home/spack/spack/opt/spack/linux-centos8-aarch64/gcc-8.3.1/perl-5.32.1-2s3unjl3vzun64kvy54peyqyutnjf7m5/bin/perl -Ibin -Ilib -I./t -MTest::Harness -e 'runtests(@ARGV)' "${dir#./}"/*.t
t/chkstow.t ................ Can't locate IO/Scalar.pm in @INC (you may need to install the IO::Scalar module) (@INC contains: bin lib ./t /home/spack/spack/opt/spack/linux-centos8-aarch64/gcc-8.3.1/perl-5.32.1-2s3unjl3vzun64kvy54peyqyutnjf7m5/lib/perl5 /home/spack/spack/opt/spack/linux-centos8-aarch64/gcc-8.3.1/perl-5.32.1-2s3unjl3vzun64kvy54peyqyutnjf7m5/lib/site_perl/5.32.1/aarch64-linux-thread-multi /home/spack/spack/opt/spack/linux-centos8-aarch64/gcc-8.3.1/perl-5.32.1-2s3unjl3vzun64kvy54peyqyutnjf7m5/lib/site_perl/5.32.1 /home/spack/spack/opt/spack/linux-centos8-aarch64/gcc-8.3.1/perl-5.32.1-2s3unjl3vzun64kvy54peyqyutnjf7m5/lib/5.32.1/aarch64-linux-thread-multi /home/spack/spack/opt/spack/linux-centos8-aarch64/gcc-8.3.1/perl-5.32.1-2s3unjl3vzun64kvy54peyqyutnjf7m5/lib/5.32.1 .) at t/testutil.pm line 31.
BEGIN failed--compilation aborted at t/testutil.pm line 31.
Compilation failed in require at t/chkstow.t line 25.
BEGIN failed--compilation aborted at t/chkstow.t line 25.
t/chkstow.t ................ Dubious, test returned 2 (wstat 512, 0x200)
No subtests run
t/cleanup_invalid_links.t .. Can't locate IO/Scalar.pm in @INC (you may need to install the IO::Scalar module) (@INC contains: bin lib ./t /home/spack/spack/opt/spack/linux-centos8-aarch64/gcc-8.3.1/perl-5.32.1-2s3unjl3vzun64kvy54peyqyutnjf7m5/lib/perl5 /home/spack/spack/opt/spack/linux-centos8-aarch64/gcc-8.3.1/perl-5.32.1-2s3unjl3vzun64kvy54peyqyutnjf7m5/lib/site_perl/5.32.1/aarch64-linux-thread-multi /home/spack/spack/opt/spack/linux-centos8-aarch64/gcc-8.3.1/perl-5.32.1-2s3unjl3vzun64kvy54peyqyutnjf7m5/lib/site_perl/5.32.1 /home/spack/spack/opt/spack/linux-centos8-aarch64/gcc-8.3.1/perl-5.32.1-2s3unjl3vzun64kvy54peyqyutnjf7m5/lib/5.32.1/aarch64-linux-thread-multi /home/spack/spack/opt/spack/linux-centos8-aarch64/gcc-8.3.1/perl-5.32.1-2s3unjl3vzun64kvy54peyqyutnjf7m5/lib/5.32.1 .) at t/testutil.pm line 31.
BEGIN failed--compilation aborted at t/testutil.pm line 31.
Compilation failed in require at t/cleanup_invalid_links.t line 28.
BEGIN failed--compilation aborted at t/cleanup_invalid_links.t line 28.
# Looks like your test exited with 2 before it could output anything.
t/cleanup_invalid_links.t .. Dubious, test returned 2 (wstat 512, 0x200)
Failed 6/6 subtests
t/cli_options.t ............ Can't locate IO/Scalar.pm in @INC (you may need to install the IO::Scalar module) (@INC contains: bin lib ./t /home/spack/spack/opt/spack/linux-centos8-aarch64/gcc-8.3.1/perl-5.32.1-2s3unjl3vzun64kvy54peyqyutnjf7m5/lib/perl5 /home/spack/spack/opt/spack/linux-centos8-aarch64/gcc-8.3.1/perl-5.32.1-2s3unjl3vzun64kvy54peyqyutnjf7m5/lib/site_perl/5.32.1/aarch64-linux-thread-multi /home/spack/spack/opt/spack/linux-centos8-aarch64/gcc-8.3.1/perl-5.32.1-2s3unjl3vzun64kvy54peyqyutnjf7m5/lib/site_perl/5.32.1 /home/spack/spack/opt/spack/linux-centos8-aarch64/gcc-8.3.1/perl-5.32.1-2s3unjl3vzun64kvy54peyqyutnjf7m5/lib/5.32.1/aarch64-linux-thread-multi /home/spack/spack/opt/spack/linux-centos8-aarch64/gcc-8.3.1/perl-5.32.1-2s3unjl3vzun64kvy54peyqyutnjf7m5/lib/5.32.1 .) at t/testutil.pm line 31.
BEGIN failed--compilation aborted at t/testutil.pm line 31.
Compilation failed in require at t/cli_options.t line 27.
BEGIN failed--compilation aborted at t/cli_options.t line 27.
# Looks like your test exited with 2 before it could output anything.
t/cli_options.t ............ Dubious, test returned 2 (wstat 512, 0x200)
Failed 10/10 subtests
t/cli.t .................... Can't locate IO/Scalar.pm in @INC (you may need to install the IO::Scalar module) (@INC contains: bin lib ./t /home/spack/spack/opt/spack/linux-centos8-aarch64/gcc-8.3.1/perl-5.32.1-2s3unjl3vzun64kvy54peyqyutnjf7m5/lib/perl5 /home/spack/spack/opt/spack/linux-centos8-aarch64/gcc-8.3.1/perl-5.32.1-2s3unjl3vzun64kvy54peyqyutnjf7m5/lib/site_perl/5.32.1/aarch64-linux-thread-multi /home/spack/spack/opt/spack/linux-centos8-aarch64/gcc-8.3.1/perl-5.32.1-2s3unjl3vzun64kvy54peyqyutnjf7m5/lib/site_perl/5.32.1 /home/spack/spack/opt/spack/linux-centos8-aarch64/gcc-8.3.1/perl-5.32.1-2s3unjl3vzun64kvy54peyqyutnjf7m5/lib/5.32.1/aarch64-linux-thread-multi /home/spack/spack/opt/spack/linux-centos8-aarch64/gcc-8.3.1/perl-5.32.1-2s3unjl3vzun64kvy54peyqyutnjf7m5/lib/5.32.1 .) at t/testutil.pm line 31.
BEGIN failed--compilation aborted at t/testutil.pm line 31.
Compilation failed in require at t/cli.t line 28.
BEGIN failed--compilation aborted at t/cli.t line 28.
# Looks like your test exited with 2 before it could output anything.
t/cli.t .................... Dubious, test returned 2 (wstat 512, 0x200)
Failed 3/3 subtests
t/defer.t .................. Can't locate IO/Scalar.pm in @INC (you may need to install the IO::Scalar module) (@INC contains: bin lib ./t /home/spack/spack/opt/spack/linux-centos8-aarch64/gcc-8.3.1/perl-5.32.1-2s3unjl3vzun64kvy54peyqyutnjf7m5/lib/perl5 /home/spack/spack/opt/spack/linux-centos8-aarch64/gcc-8.3.1/perl-5.32.1-2s3unjl3vzun64kvy54peyqyutnjf7m5/lib/site_perl/5.32.1/aarch64-linux-thread-multi /home/spack/spack/opt/spack/linux-centos8-aarch64/gcc-8.3.1/perl-5.32.1-2s3unjl3vzun64kvy54peyqyutnjf7m5/lib/site_perl/5.32.1 /home/spack/spack/opt/spack/linux-centos8-aarch64/gcc-8.3.1/perl-5.32.1-2s3unjl3vzun64kvy54peyqyutnjf7m5/lib/5.32.1/aarch64-linux-thread-multi /home/spack/spack/opt/spack/linux-centos8-aarch64/gcc-8.3.1/perl-5.32.1-2s3unjl3vzun64kvy54peyqyutnjf7m5/lib/5.32.1 .) at t/testutil.pm line 31.
BEGIN failed--compilation aborted at t/testutil.pm line 31.
Compilation failed in require at t/defer.t line 25.
BEGIN failed--compilation aborted at t/defer.t line 25.
t/defer.t .................. Dubious, test returned 2 (wstat 512, 0x200)
No subtests run
t/dotfiles.t ............... Can't locate IO/Scalar.pm in @INC (you may need to install the IO::Scalar module) (@INC contains: bin lib ./t /home/spack/spack/opt/spack/linux-centos8-aarch64/gcc-8.3.1/perl-5.32.1-2s3unjl3vzun64kvy54peyqyutnjf7m5/lib/perl5 /home/spack/spack/opt/spack/linux-centos8-aarch64/gcc-8.3.1/perl-5.32.1-2s3unjl3vzun64kvy54peyqyutnjf7m5/lib/site_perl/5.32.1/aarch64-linux-thread-multi /home/spack/spack/opt/spack/linux-centos8-aarch64/gcc-8.3.1/perl-5.32.1-2s3unjl3vzun64kvy54peyqyutnjf7m5/lib/site_perl/5.32.1 /home/spack/spack/opt/spack/linux-centos8-aarch64/gcc-8.3.1/perl-5.32.1-2s3unjl3vzun64kvy54peyqyutnjf7m5/lib/5.32.1/aarch64-linux-thread-multi /home/spack/spack/opt/spack/linux-centos8-aarch64/gcc-8.3.1/perl-5.32.1-2s3unjl3vzun64kvy54peyqyutnjf7m5/lib/5.32.1 .) at t/testutil.pm line 31.
BEGIN failed--compilation aborted at t/testutil.pm line 31.
Compilation failed in require at t/dotfiles.t line 25.
BEGIN failed--compilation aborted at t/dotfiles.t line 25.
t/dotfiles.t ............... Dubious, test returned 2 (wstat 512, 0x200)
No subtests run
t/examples.t ............... Can't locate IO/Scalar.pm in @INC (you may need to install the IO::Scalar module) (@INC contains: bin lib ./t /home/spack/spack/opt/spack/linux-centos8-aarch64/gcc-8.3.1/perl-5.32.1-2s3unjl3vzun64kvy54peyqyutnjf7m5/lib/perl5 /home/spack/spack/opt/spack/linux-centos8-aarch64/gcc-8.3.1/perl-5.32.1-2s3unjl3vzun64kvy54peyqyutnjf7m5/lib/site_perl/5.32.1/aarch64-linux-thread-multi /home/spack/spack/opt/spack/linux-centos8-aarch64/gcc-8.3.1/perl-5.32.1-2s3unjl3vzun64kvy54peyqyutnjf7m5/lib/site_perl/5.32.1 /home/spack/spack/opt/spack/linux-centos8-aarch64/gcc-8.3.1/perl-5.32.1-2s3unjl3vzun64kvy54peyqyutnjf7m5/lib/5.32.1/aarch64-linux-thread-multi /home/spack/spack/opt/spack/linux-centos8-aarch64/gcc-8.3.1/perl-5.32.1-2s3unjl3vzun64kvy54peyqyutnjf7m5/lib/5.32.1 .) at t/testutil.pm line 31.
BEGIN failed--compilation aborted at t/testutil.pm line 31.
Compilation failed in require at t/examples.t line 25.
BEGIN failed--compilation aborted at t/examples.t line 25.
t/examples.t ............... Dubious, test returned 2 (wstat 512, 0x200)
No subtests run
t/find_stowed_path.t ....... Can't locate IO/Scalar.pm in @INC (you may need to install the IO::Scalar module) (@INC contains: bin lib ./t /home/spack/spack/opt/spack/linux-centos8-aarch64/gcc-8.3.1/perl-5.32.1-2s3unjl3vzun64kvy54peyqyutnjf7m5/lib/perl5 /home/spack/spack/opt/spack/linux-centos8-aarch64/gcc-8.3.1/perl-5.32.1-2s3unjl3vzun64kvy54peyqyutnjf7m5/lib/site_perl/5.32.1/aarch64-linux-thread-multi /home/spack/spack/opt/spack/linux-centos8-aarch64/gcc-8.3.1/perl-5.32.1-2s3unjl3vzun64kvy54peyqyutnjf7m5/lib/site_perl/5.32.1 /home/spack/spack/opt/spack/linux-centos8-aarch64/gcc-8.3.1/perl-5.32.1-2s3unjl3vzun64kvy54peyqyutnjf7m5/lib/5.32.1/aarch64-linux-thread-multi /home/spack/spack/opt/spack/linux-centos8-aarch64/gcc-8.3.1/perl-5.32.1-2s3unjl3vzun64kvy54peyqyutnjf7m5/lib/5.32.1 .) at t/testutil.pm line 31.
BEGIN failed--compilation aborted at t/testutil.pm line 31.
Compilation failed in require at t/find_stowed_path.t line 27.
BEGIN failed--compilation aborted at t/find_stowed_path.t line 27.
# Looks like your test exited with 2 before it could output anything.
t/find_stowed_path.t ....... Dubious, test returned 2 (wstat 512, 0x200)
Failed 18/18 subtests
t/foldable.t ............... Can't locate IO/Scalar.pm in @INC (you may need to install the IO::Scalar module) (@INC contains: bin lib ./t /home/spack/spack/opt/spack/linux-centos8-aarch64/gcc-8.3.1/perl-5.32.1-2s3unjl3vzun64kvy54peyqyutnjf7m5/lib/perl5 /home/spack/spack/opt/spack/linux-centos8-aarch64/gcc-8.3.1/perl-5.32.1-2s3unjl3vzun64kvy54peyqyutnjf7m5/lib/site_perl/5.32.1/aarch64-linux-thread-multi /home/spack/spack/opt/spack/linux-centos8-aarch64/gcc-8.3.1/perl-5.32.1-2s3unjl3vzun64kvy54peyqyutnjf7m5/lib/site_perl/5.32.1 /home/spack/spack/opt/spack/linux-centos8-aarch64/gcc-8.3.1/perl-5.32.1-2s3unjl3vzun64kvy54peyqyutnjf7m5/lib/5.32.1/aarch64-linux-thread-multi /home/spack/spack/opt/spack/linux-centos8-aarch64/gcc-8.3.1/perl-5.32.1-2s3unjl3vzun64kvy54peyqyutnjf7m5/lib/5.32.1 .) at t/testutil.pm line 31.
BEGIN failed--compilation aborted at t/testutil.pm line 31.
Compilation failed in require at t/foldable.t line 25.
BEGIN failed--compilation aborted at t/foldable.t line 25.
t/foldable.t ............... Dubious, test returned 2 (wstat 512, 0x200)
No subtests run
t/ignore.t ................. Can't locate IO/Scalar.pm in @INC (you may need to install the IO::Scalar module) (@INC contains: bin lib ./t /home/spack/spack/opt/spack/linux-centos8-aarch64/gcc-8.3.1/perl-5.32.1-2s3unjl3vzun64kvy54peyqyutnjf7m5/lib/perl5 /home/spack/spack/opt/spack/linux-centos8-aarch64/gcc-8.3.1/perl-5.32.1-2s3unjl3vzun64kvy54peyqyutnjf7m5/lib/site_perl/5.32.1/aarch64-linux-thread-multi /home/spack/spack/opt/spack/linux-centos8-aarch64/gcc-8.3.1/perl-5.32.1-2s3unjl3vzun64kvy54peyqyutnjf7m5/lib/site_perl/5.32.1 /home/spack/spack/opt/spack/linux-centos8-aarch64/gcc-8.3.1/perl-5.32.1-2s3unjl3vzun64kvy54peyqyutnjf7m5/lib/5.32.1/aarch64-linux-thread-multi /home/spack/spack/opt/spack/linux-centos8-aarch64/gcc-8.3.1/perl-5.32.1-2s3unjl3vzun64kvy54peyqyutnjf7m5/lib/5.32.1 .) at t/testutil.pm line 31.
BEGIN failed--compilation aborted at t/testutil.pm line 31.
Compilation failed in require at t/ignore.t line 28.
BEGIN failed--compilation aborted at t/ignore.t line 28.
# Looks like your test exited with 2 before it could output anything.
t/ignore.t ................. Dubious, test returned 2 (wstat 512, 0x200)
Failed 287/287 subtests
t/join_paths.t ............. ok
t/parent.t ................. ok
t/rc_options.t ............. Can't locate IO/Scalar.pm in @INC (you may need to install the IO::Scalar module) (@INC contains: bin lib ./t /home/spack/spack/opt/spack/linux-centos8-aarch64/gcc-8.3.1/perl-5.32.1-2s3unjl3vzun64kvy54peyqyutnjf7m5/lib/perl5 /home/spack/spack/opt/spack/linux-centos8-aarch64/gcc-8.3.1/perl-5.32.1-2s3unjl3vzun64kvy54peyqyutnjf7m5/lib/site_perl/5.32.1/aarch64-linux-thread-multi /home/spack/spack/opt/spack/linux-centos8-aarch64/gcc-8.3.1/perl-5.32.1-2s3unjl3vzun64kvy54peyqyutnjf7m5/lib/site_perl/5.32.1 /home/spack/spack/opt/spack/linux-centos8-aarch64/gcc-8.3.1/perl-5.32.1-2s3unjl3vzun64kvy54peyqyutnjf7m5/lib/5.32.1/aarch64-linux-thread-multi /home/spack/spack/opt/spack/linux-centos8-aarch64/gcc-8.3.1/perl-5.32.1-2s3unjl3vzun64kvy54peyqyutnjf7m5/lib/5.32.1 .) at t/testutil.pm line 31.
BEGIN failed--compilation aborted at t/testutil.pm line 31.
Compilation failed in require at t/rc_options.t line 27.
BEGIN failed--compilation aborted at t/rc_options.t line 27.
# Looks like your test exited with 2 before it could output anything.
t/rc_options.t ............. Dubious, test returned 2 (wstat 512, 0x200)
Failed 34/34 subtests
t/stow.t ................... Can't locate Test/Output.pm in @INC (you may need to install the Test::Output module) (@INC contains: bin lib ./t /home/spack/spack/opt/spack/linux-centos8-aarch64/gcc-8.3.1/perl-5.32.1-2s3unjl3vzun64kvy54peyqyutnjf7m5/lib/perl5 /home/spack/spack/opt/spack/linux-centos8-aarch64/gcc-8.3.1/perl-5.32.1-2s3unjl3vzun64kvy54peyqyutnjf7m5/lib/site_perl/5.32.1/aarch64-linux-thread-multi /home/spack/spack/opt/spack/linux-centos8-aarch64/gcc-8.3.1/perl-5.32.1-2s3unjl3vzun64kvy54peyqyutnjf7m5/lib/site_perl/5.32.1 /home/spack/spack/opt/spack/linux-centos8-aarch64/gcc-8.3.1/perl-5.32.1-2s3unjl3vzun64kvy54peyqyutnjf7m5/lib/5.32.1/aarch64-linux-thread-multi /home/spack/spack/opt/spack/linux-centos8-aarch64/gcc-8.3.1/perl-5.32.1-2s3unjl3vzun64kvy54peyqyutnjf7m5/lib/5.32.1 .) at t/stow.t line 26.
BEGIN failed--compilation aborted at t/stow.t line 26.
# Looks like your test exited with 2 before it could output anything.
t/stow.t ................... Dubious, test returned 2 (wstat 512, 0x200)
Failed 118/118 subtests
t/unstow_orig.t ............ Can't locate Test/Output.pm in @INC (you may need to install the Test::Output module) (@INC contains: bin lib ./t /home/spack/spack/opt/spack/linux-centos8-aarch64/gcc-8.3.1/perl-5.32.1-2s3unjl3vzun64kvy54peyqyutnjf7m5/lib/perl5 /home/spack/spack/opt/spack/linux-centos8-aarch64/gcc-8.3.1/perl-5.32.1-2s3unjl3vzun64kvy54peyqyutnjf7m5/lib/site_perl/5.32.1/aarch64-linux-thread-multi /home/spack/spack/opt/spack/linux-centos8-aarch64/gcc-8.3.1/perl-5.32.1-2s3unjl3vzun64kvy54peyqyutnjf7m5/lib/site_perl/5.32.1 /home/spack/spack/opt/spack/linux-centos8-aarch64/gcc-8.3.1/perl-5.32.1-2s3unjl3vzun64kvy54peyqyutnjf7m5/lib/5.32.1/aarch64-linux-thread-multi /home/spack/spack/opt/spack/linux-centos8-aarch64/gcc-8.3.1/perl-5.32.1-2s3unjl3vzun64kvy54peyqyutnjf7m5/lib/5.32.1 .) at t/unstow_orig.t line 27.
BEGIN failed--compilation aborted at t/unstow_orig.t line 27.
# Looks like your test exited with 2 before it could output anything.
t/unstow_orig.t ............ Dubious, test returned 2 (wstat 512, 0x200)
Failed 37/37 subtests
t/unstow.t ................. Can't locate Test/Output.pm in @INC (you may need to install the Test::Output module) (@INC contains: bin lib ./t /home/spack/spack/opt/spack/linux-centos8-aarch64/gcc-8.3.1/perl-5.32.1-2s3unjl3vzun64kvy54peyqyutnjf7m5/lib/perl5 /home/spack/spack/opt/spack/linux-centos8-aarch64/gcc-8.3.1/perl-5.32.1-2s3unjl3vzun64kvy54peyqyutnjf7m5/lib/site_perl/5.32.1/aarch64-linux-thread-multi /home/spack/spack/opt/spack/linux-centos8-aarch64/gcc-8.3.1/perl-5.32.1-2s3unjl3vzun64kvy54peyqyutnjf7m5/lib/site_perl/5.32.1 /home/spack/spack/opt/spack/linux-centos8-aarch64/gcc-8.3.1/perl-5.32.1-2s3unjl3vzun64kvy54peyqyutnjf7m5/lib/5.32.1/aarch64-linux-thread-multi /home/spack/spack/opt/spack/linux-centos8-aarch64/gcc-8.3.1/perl-5.32.1-2s3unjl3vzun64kvy54peyqyutnjf7m5/lib/5.32.1 .) at t/unstow.t line 26.
BEGIN failed--compilation aborted at t/unstow.t line 26.
# Looks like your test exited with 2 before it could output anything.
t/unstow.t ................. Dubious, test returned 2 (wstat 512, 0x200)
Failed 39/39 subtests

Test Summary Report
-------------------
t/chkstow.t              (Wstat: 512 Tests: 0 Failed: 0)
  Non-zero exit status: 2
  Parse errors: No plan found in TAP output
t/cleanup_invalid_links.t (Wstat: 512 Tests: 0 Failed: 0)
  Non-zero exit status: 2
  Parse errors: Bad plan.  You planned 6 tests but ran 0.
t/cli_options.t          (Wstat: 512 Tests: 0 Failed: 0)
  Non-zero exit status: 2
  Parse errors: Bad plan.  You planned 10 tests but ran 0.
t/cli.t                  (Wstat: 512 Tests: 0 Failed: 0)
  Non-zero exit status: 2
  Parse errors: Bad plan.  You planned 3 tests but ran 0.
t/defer.t                (Wstat: 512 Tests: 0 Failed: 0)
  Non-zero exit status: 2
  Parse errors: No plan found in TAP output
t/dotfiles.t             (Wstat: 512 Tests: 0 Failed: 0)
  Non-zero exit status: 2
  Parse errors: No plan found in TAP output
t/examples.t             (Wstat: 512 Tests: 0 Failed: 0)
  Non-zero exit status: 2
  Parse errors: No plan found in TAP output
t/find_stowed_path.t     (Wstat: 512 Tests: 0 Failed: 0)
  Non-zero exit status: 2
  Parse errors: Bad plan.  You planned 18 tests but ran 0.
t/foldable.t             (Wstat: 512 Tests: 0 Failed: 0)
  Non-zero exit status: 2
  Parse errors: No plan found in TAP output
t/ignore.t               (Wstat: 512 Tests: 0 Failed: 0)
  Non-zero exit status: 2
  Parse errors: Bad plan.  You planned 287 tests but ran 0.
t/rc_options.t           (Wstat: 512 Tests: 0 Failed: 0)
  Non-zero exit status: 2
  Parse errors: Bad plan.  You planned 34 tests but ran 0.
t/stow.t                 (Wstat: 512 Tests: 0 Failed: 0)
  Non-zero exit status: 2
  Parse errors: Bad plan.  You planned 118 tests but ran 0.
t/unstow_orig.t          (Wstat: 512 Tests: 0 Failed: 0)
  Non-zero exit status: 2
  Parse errors: Bad plan.  You planned 37 tests but ran 0.
t/unstow.t               (Wstat: 512 Tests: 0 Failed: 0)
  Non-zero exit status: 2
  Parse errors: Bad plan.  You planned 39 tests but ran 0.
Files=16, Tests=19,  2 wallclock secs ( 0.05 usr  0.02 sys +  0.90 cusr  0.18 csys =  1.15 CPU)
Result: FAIL
Failed 14/16 test programs. 0/19 subtests failed.
make[1]: *** [Makefile:1498: check-TESTS] Error 2
make[1]: Leaving directory '/tmp/root/spack-stage/spack-stage-stow-2.3.1-file4ivvcsvkwadvhc7qluufgxkqltvt/spack-src'
make: *** [Makefile:1234: check-am] Error 2

I don't know why these errors are reported. Can you tell me why?

Information on your system

• Python: 3.6.8
• Platform: linux-centos8-aarch64
• Concretizer: original

Heh, I just figured it out while writing this (is there a "rubberduck" label ?). So it's not really a bug report anymore, but I'd like to discuss it anyway - feel free to close at any time.

I was trying to stow ~/.gitconfig and ~/.gitignore . The first worked, but I just could not make it work with .gitignore !

Turning on -vvvvv revealed the explanation :

Using built-in ignore list
    Ignore list regexp for paths:    /(?^:(^|/)(^/README.*|^/LICENSE.*|^/\.stow\-local\-ignore$|^/COPYING)(/|$))/
    Ignore list regexp for segments: /(?^:^(\.hg|CVS|.+,v|\.gitignore|\.svn|#.*#|\.cvsignore|\.#.+|_darcs|.+~|\.git|RCS)$)/

I understand the reason for ignoring those in the root of the "stow directory", but I'm not sure when they would be a problem coming from within a package ?
Unless those regexp are mainly so that --adopt doesn't pick up all that trash ?

I know how to work around this ; just add --dotfiles in .stowrc , and rename files to dot-gitconfig and dot-gitignore, so as I said this isn't really an issue.

Seems that --dotfiles was not added to the sub usage { help text when the option was added. Mea culpa for missing this.

Currently Stow is built by pre-processing *.in files into corresponding files with the .in prefix dropped. For example:

• bin/stow is generated from bin/stow.in,
• lib/Stow.pm is generated from lib/Stow.pm.in

and so on.

Why is this done? The answer can be seen from the very simple pre-processor in Makefile.am:

edit = sed -e 's|[@]PERL[@]|$(PERL)|g'       \
           -e 's|[@]VERSION[@]|$(VERSION)|g' \
           -e "s|[@]USE_LIB_PMDIR[@]|$$use_lib_pmdir|g"

In other words, it's done in order to ensure that:

1. the correct shebang line at the start of bin/stow and bin/chkstow is correct (#!/usr/bin/perl in many cases, but could be something else if your Perl installation is elsewhere)
2. $Stow::VERSION and $Stow::Util::VERSION are set to the correct version number (the same as the Stow release version)
3. bin/stow has a use lib line pointing to the location of the Stow and Stow::Util modules, so that it always finds them.

This seems to work OK, but has several disadvantages:

• Development has to occur in *.in files, which confuses code editors.
• Testing of code modifications requires the pre-processor to be run in between every modification and the next test run. make watch is a hack to make this slightly more convenient, but it would be better if it wasn't necessary.
• Testing of code modifications to the libraries in lib/ not only requires the pre-processor run, but also make install, because the use lib line in the stow script ensures that the final location of the modules is first on the @INC load path at run-time. So even if you try to test by running make (not make install) and then something like perl -Ilib bin/stow, it will pick up the installed Stow.pm, not the one you just built in lib/.
• It's a non-standard approach.
• It just all feels more complicated than it should need to be.

One obvious question is: why on earth did I do it this way? Unfortunately I can't remember; maybe there was a good reason, or maybe I just wasn't experienced enough at the time to make the right choice. Perhaps digging through git history will answer this.

A related but more important question is: can we ditch this, and adopt a simpler, more standard approach, e.g.:

• Remove the embedded use lib line and trust the user to set the right PERL5LIB if installing into a per-user or non-standard location which isn't system-wide.
• Switch shebang lines to #!/usr/bin/env perl and trust the user to set the right $PATH.
• Change Makefile.am to write the version string to a separate file such as Stow/version.pm, and import that where needed.

None of this is specific to Stow, and applies to pretty much any CPAN module, so we should probably adopt whatever is the standard approach these days.

However this may require removing support for the autotools-based installation route, and I don't know how many people use that vs. the Module::Build installation route. Worse, I don't even know how I can effectively poll the userbase to find out one way or the other. Suggestions welcome.

(It's interesting to note that other "scripting" languages such as Python and Ruby can solve this by auto-generating wrapper stub scripts.)

Suppose you have a package "app", which keeps its configurations settings in ~/.config/app/settings.json.

Let's say you want to use stow to keep the app's settings file in a ~/dotfiles/ directory, and create a symlink from the home folder. You want to use the --dotfiles option so that the dotfiles directory isn't full of hidden files. So you move the configuration settings to ~/dotfiles/app/dot-config/app/settings.json and then run stow --dotfiles app from the dotfiles directory to create the symlinks.

I think this should work, but it raises the error: stow: ERROR: stow_contents() called with non-directory path: dotfiles/app/.config.

Have I made an error, or is this a bug?

Reproducible code:

#!/bin/bash

# Set up
mkdir -p homedir/.config
mkdir -p homedir/dotfiles/app/dot-config/app
touch homedir/dotfiles/app/dot-config/app/settings.json
cd homedir/dotfiles

# Doesn't work!
stow --dotfiles app

# Tidy up
cd ../..
rm -r homedir

Hi all,

Just recently installed a new system, and any stow command will output the same warning:

$ stow -V
Possible precedence issue with control flow operator at /usr/share/perl5/Stow.pm line 1736.
stow (GNU Stow) version 2.2.0

Is this known? Are there any workaround?

Hello!

Thank you for stow -- I'm enjoying it a lot. It has become the first tool that I install on a new machine after git. Also, I hope github is an OK channel for sending feature requests.

Here's my request: It'd be nice to have a new command line option --orig (or similar) to make backups of conflicting files in the target directory instead of failing on conflict. For example:

• hosts => hosts.orig
• ntp.conf => ntp.conf.orig
• .bashrc => .bashrc.orig

I often use stow to link files from a git repo into $HOME or /etc, and Linux distributions ship with default configuration files in these locations that stow will trip over. The --adopt option does not solve my problem because I don't want to copy the OS default configs into my git repo - I want to do the opposite and overwrite the OS default configs (but keep backups of them).

Leaving each backup file in the same directory as the original and using a constant backup extension (.orig) has the nice effect that one can do e.g. find /etc -name "*.orig" to find all overwritten configs. Likewise, it's fairly easy to run diff to see changes from the OS defaults.

Here's a demonstration of what currently happens:

$ mkdir demo
$ mkdir -p demo/stow/test
$ touch demo/foo demo/stow/test/foo
$ tree demo --charset ascii
demo
|-- foo
`-- stow
    `-- test
        `-- foo

2 directories, 2 files
$ (cd demo/stow && stow test)
WARNING! stowing test would cause conflicts:
  * existing target is neither a link nor a directory: foo
All operations aborted.

This is what I would like to have:

$ (cd demo/stow && stow --orig -vv test)
...
RENAME: foo => foo.orig
LINK: foo => stow/test/foo
...
$ tree demo --charset ascii
demo
|-- foo -> stow/test/foo
|-- foo.orig
`-- stow
    `-- test
        `-- foo

2 directories, 3 files

Here's a succint description of the behavior that --orig would have, covering edge cases:

• IF dst already exists THEN
  • IF dst.orig already exists THEN give up and stop with an error
  • ELSE rename dst to dst.orig(even if dst is a symlink, a directory, etc.)
    • IF the rename fails due to permissions etc. THEN give up and stop with an error

The option could also be named --backup or similar, but I personally like --orig because it's short and mnemonic (it reminds the user that the backup filename will have the extension .orig, which is also a de facto standard extension for such files).

Would you accept a feature like this into stow?

Kind regards,
Lassi

?

Stow is not a package manager in the normal, modern sense:

• http://lists.gnu.org/archive/html/info-stow/2016-11/msg00008.html

The man page and docs should be made clearer about this.

Making

--target='~'

possible.

Can we have an option to create symlinks with absolute path? When your stow dir is not in the default location which is /usr/local/stow, I think it's more efficient to use absolute path in the target path when creating symlinks

$ cd /opt/stow/jvm
$ stow -v1 -n -t /usr/local jre1.8.0_05
...
LINK: bin/java => ../../../opt/stow/jvm/jre1.8.0_05/bin/java

EDIT: Clarification from @aspiers:

• This issue is about the symlinks which Stow manages in the target directory being absolute symlinks.
• #11 is about the Stow directory being a symlink.
• #51 is about package trees containing absolute symlinks.

They're all separate issues despite appearing similar on the surface.

stow --foo correctly displays that it doesn't know the option Unknown option: foo but the exit code is still 0. It should be non 0 like other common commands.

Allow stow --adopt to adopt a folder if I try to stow a folder that already exists.

mkdir -p /usr/local/Cellar/app/0.36.2/{bin,etc}

touch /usr/local/Cellar/app/0.36.2/{LICENSE,README.md}
touch /usr/local/Cellar/app/0.36.2/bin/cmd

ln -s  /usr/local/Cellar/app/0.36.2  /usr/local/opt/app


mkdir -p ~/dotfiles/app-config/opt/app/

touch  ~/dotfiles/app-config/opt/app/homebrew.mxcl.app.plist

cd ~/dotfiles/app-config/opt/
stow -v5 -n --no-folding --dir=. --target=/usr/local/opt/

Output

  read_a_link(app): real link
  Evaluate existing link: app => ../Cellar/app/0.36.2
  is path ../Cellar/app/0.36.2 owned by stow?
    no - either ../Cellar/app/0.36.2 not under ../../../Users/issenn/dotfiles/app-config/opt or vice-versa
CONFLICT when stowing .: existing target is not owned by stow: app

As originally mentioned in http://lists.gnu.org/archive/html/info-stow/2016-11/msg00004.html:

texi2html is part of the Texinfo source repository but apparently it's no longer maintained and not included in the Texinfo distribution.

Despite that, some distributions do include it within their texinfo packages, e.g. openSUSE,
from which you can see that the separate distributions are still available, but have not been updated since 2010.

However there is a partially compatible drop-in replacement which is a simple wrapper around texi2any (also an outdated svn link). Perhaps we need to convert the build process to use that. I have no idea how well it would work right now.

Just found https://www.gnu.org/prep/maintain/html_node/License-Notices-for-Documentation.html#License-Notices-for-Documentation and then discovered this TODO which led me to find some ancient email:

• [Stow-devel] RFC: moving to GPL v3 and FDL 1.3
• a private conversation from Dec 2011 with Karl Berry about needing permission from existing copyright holders on the manual to change it to FDL.

See also #44 (Apply GPL v3 to all files).

It's good to have ~/.stowrc to specify default command line options, it would better to have perpackage .stowrc file, so perpackage command line options can be set in config file without remember it and issue every time.

Such as, some package's config files path is under ~/Library/Preferences/ on macos, but it has more simplicity to organize stow files like this:

dotfiles/package_name/file

and restore with `stow -t path package_name.

Hi,

When stowing packages, I need to only override all normal files but split all dirs. If use option --override='.*', it will make all folded dirs to be overrided as a whole link, not splitted. So how to do this or need a new option?

When using --adopt and --dotfiles together, files are not adopted correctly.

Steps to reproduce:

touch .dotfiles-test
mkdir test
cd test
mkdir test
touch test/dot-dotfiles-test
stow -n --adopt --dotfiles -v test

This results in the following print:

MV: .dotfiles-test -> test/test/.dotfiles-test
LINK: .dotfiles-test => test/test/dot-dotfiles-test
WARNING: in simulation mode so not modifying filesystem.

The file is moved to .dotfiles-test and the link is to dot-dotfiles-test. These are two different files, and the result is that the original file is no longer used.

#17

(Also posted to https://unix.stackexchange.com/questions/445712/how-to-sync-files-and-symbolic-links-between-original-dir-and-symbolic-directory)

For instance, I put symbolic links into ~/.local/bin/ which point to real executable files in ~/Dotfiles.d/local/.local/bin/.

I use the following instructions to do that:

$ cd ~/Dotfiles.d/
$ stow -v local

so stow will create links for all files in local (which contains .local/bin/*) into ~/.local/bin/*

But when I need to add new files into the bin directory, whether I add file in ~/.local/bin/ or ~/Dotfiles.d/local/.local/bin/, stow is not able to sync files between these two directories.

What I want is:

1. If add new file into ~/.local/bin/ directly, it will actually add new file into ~/Dotfiles.d/local/.local/bin automatically, and create a symbolic link into ~/.local/bin/ automatically.
2. If I add new file into ~/Dotfiles.d/local/.local/bin/, it will automatically create a symbolic link of this file into ~/.local/bin/.

Is stow able to do that?

System Information

$ stow --version
stow (GNU Stow) version 2.3.1
$ perl -v
This is perl 5, version 30, subversion 0 (v5.30.0) built for x86_64-linux-thread-multi
$ uname -a
Linux garry 5.2.9-arch1-1-ARCH #1 SMP PREEMPT Fri Aug 16 11:29:43 UTC 2019 x86_64 GNU/Linux

Description

Since this change, everytime I unstow package foo it gives be this message:

$ stow -D --verbose=3 foo
stow dir is /home/user/dotfiles
stow dir path relative to target /home/user is dotfiles
cwd now /home/user
Planning unstow of package foo...
Unstowing from . (cwd=/home/user, stow dir=dotfiles)
Unstowing dotfiles/foo/.foorc
UNLINK: .foorc
BUG in find_stowed_path? Absolute/relative mismatch between Stow dir dotfiles
and path /home/user/.bar/somerandom_bar_related_dir at /usr/share/perl5/vendor_perl/Stow.pm line 966, <DATA> line 22.
and path /home/user/.bar/somerandom_different_bar_related_dir at /usr/share/perl5/vendor_perl/Stow.pm line 966, <DATA> line 22.
Planning unstow of package foo... done
cwd restored to /home/user/dotfiles
cwd now /home/user

I will isolate the warning to make it clearer:

$ stow -D foo
BUG in find_stowed_path? Absolute/relative mismatch between Stow dir dotfiles
and path /home/user/.bar/somerandom_bar_related_dir at /usr/share/perl5/vendor_perl/Stow.pm line 966, <DATA> line 22.
and path /home/user/.bar/somerandom_different_bar_related_dir at /usr/share/perl5/vendor_perl/Stow.pm line 966, <DATA> line 22.

I understand this is supposedly added for some unit test edge case but with normal usage is indeed creating a minor annoyance.

At the default verbosity level, --simulate is quite useless, which confused me (see #81).

I think that either --simulate should imply -v, or the warning --simulate prints should be modified when the verbosity level is 0. It could say something like:

WARNING: in simulation mode so not modifying filesystem.
WARNING: The verbosity level is 0. Simulation results will not be shown.

Should we support the issue raised at Unix & Linux Stack Exchange: "symlink - Can GNU Stow use a stow directory that is a symbolic link?" ?

It seems that former Stow developers had this in mind, base on the comment in canon_path

EDIT: Clarification from @aspiers:

• This issue is about the Stow directory being a symlink.
• #51 is about package trees containing absolute symlinks.
• #3 is about the symlinks which Stow manages in the target directory being absolute symlinks.

stow is a great software, thank you for your continuous work. I encountered a problem while using it and hope to be helped.

mkdir -p project/.project/folder
touch  project/.project/folder/file

if ~/.project doesn't exist before run stow project, it will symbolic link directory ~/.project to project/.project , not file ~/.project/folder/file to project/.project/folder/file.

~/.project/folder/subfolder will be generated after run otehr software. The new folder will be copied from ~/.project/folder/subfolder to project/.project/folder/subfolder. But I want to ignore subfolder.

I tried writing \subfolder in project/.stow-local-ignore but it didn't work. Since ~/.project was added as a soft link first, ~/.project/folder/subfolder will still serve as a soft link to project/.project/folder/subfolder

My current solution is to build the directory mkdir -p ~/.project/folder before stow project

I am trying to backup nvim config with the following command, but it does absolutely nothing, what I'm I doing wrong?

mkdir -p dotfiles/nvim/.config/nvim
cd dotfiles
stow nvim

It looks like the it is stuck on "processing tasks", has anyone experienced the same thing?

[user@user-tm1701 dotfiles]$ stow -S nvim -v 3
stow dir is /home/user/dotfiles
stow dir path relative to target /home/user is dotfiles
cwd now /home/user
cwd restored to /home/user/dotfiles
cwd now /home/user
Planning stow of package nvim...
Stowing contents of dotfiles/nvim (cwd=/home/user)
Stowing dotfiles / nvim / .config
Stowing contents of dotfiles/nvim/.config (cwd=/home/user)
Stowing dotfiles / nvim / .config/nvim
Stowing contents of dotfiles/nvim/.config/nvim (cwd=/home/user)
Planning stow of package nvim... done
cwd restored to /home/user/dotfiles
Processing tasks...

This page mentions that it is possible to make a global ~/.stow-global-ignore, but it does not seem to work when I make one. I copied this from one of my (working) .stow-local-ignore files which I then deleted, but the ignores do not apply:

\.git
\.gitignore
.*\.(bak|tmp|notes)

The ~/.stow-global-ignore file is actually a stow symlink itself, but it's the same when making it into an actual file.

I'm using stow (GNU Stow) version 2.3.1.

I'm writing a tool to act similarly to https://github.com/lra/mackup, but without reinventing any of stow's features. But I'm afraid I'm reinventing stow's adoption logic to allow me to adopt a single file into a package.

Is there a way to do this presently? If so, could we add it to the doc? If not, would we be interested in adding it?

I'm not quite sure how far down the path of #19 I want to go, but mackup's database currently contains many directories, so I'll be figuring out some sort of approach.

As to why this is less terrible than mv $target_dir/bin $stow_package, I'm not sure it is. But here's some of the logic I'm currently using:

• verify that the target_dir file is not a symlink (which needs to be smarter, it should actually check if it's a non-stow symlink)
• verify that the stow_package contains the appropriate parent dirs (essentially mkdir -p $(dirname ...))
• require a flag to overwrite a file (I want to add a diff comparison tool)

(Initially posted on the help-stow mailing list.)

Like many others, I use stow to manage my dotfiles across multiple machines. In particular, a small exerpt of my stow tree includes

~/dotfiles/vim/plugin
~/dotfiles/vim/syntax
...

so I can just cd ~/dotfiles && stow -S vim after git-cloning dotfiles to a new machine.

But that'll just do a symlink ~/.vim -> ~/dotfiles/.vim, which is not what I want: this will cause e.g. ~/.vim/undo to end up in ~/dotfiles as well. So I always want to split open ~/.vim. In this specific case I could alternatively get away with gitignoring all other directories in ~/.vim, but this is less optimal for dotfiles which reside e.g. in ~/.config, as I really don't want ~/.config to be a symlink but rather ~/.config/foo to be one.
So I need to first create ~/.vim myself and manually add a directory into it (e.g. ~/.vim/undo) before stowing my dotfiles, to force splitting that directory. It would be nice it it was possible to create e.g. ~/dotfiles/vim/.stow-force-split (name is up to bikeshedding) to say, "you are not allowed to symlink this directory directly, but must split it" (and that file shouldn't get symlinked itself).

Looking forward to your thoughts.

GitHub is not a suitable choice of hosting service for GNU projects, since it is non-free in many ways, and scored an F in the GNU Ethical Repository Criteria Evaluations.

Savannah scored an A in the same evaluations, but it is so old and clunky that realistically it does not support development of Stow well enough for me to maintain it in my limited spare time.

GitLab CE scored a C, and there are efforts to get it to score higher. Additionally it offers easy migration from GitHub, so I think it's a good idea to move there. Feedback welcome.

I keep forgetting the TODO file exists, and anyway it's an ineffective place to track TODOs relative to a web-based issue tracker, so I think we should migrate its contents here.

See also #43 but moving the issue tracker elsewhere is an orthogonal problem.

Originally reported here:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806915

Summary

The chkstow --list command only works when the stow directory is called 'stow'. This is mentioned in a "FIXME" comment in the current version of the source code.

# FIXME: what if the stow dir is not called 'stow'?

http://git.savannah.gnu.org/cgit/stow.git/tree/bin/chkstow.in?id=cc0767597e5f9e23400323b42550e4672160b3c0#n97

Below is a shell script to reproduce the behavior. The chkstow invocation outputs only

package1

when it should output

package1
package2

Suggested fix: let the chkstow command take a --dir flag like stow does.

Shell script

#! /usr/bin/env bash
mkdir -p target

mkdir -p stow/package1
touch stow/package1/file1
stow --verbose --dir=./stow --target=./target package1

mkdir -p stow2/package2
touch stow2/package2/file2
stow --verbose --dir=./stow2 --target=./target package2

chkstow --target ./target/ --list

Explanation:

There are two files, one in stow/ and one in stow2/, like this:

$ tree stow stow2
stow
└── package1
    └── file1
stow2
└── package2
    └── file2

which produces a target like this:

$ file target/*
target/file1: symbolic link to ../stow/package1/file1
target/file2: symbolic link to ../stow2/package2/file2

But chkstow only recognizes the symlink pointing to stow/, not the one pointing to stow2/ as well:

$ chkstow --target ./target/ --list
package1

On downloading latest release stow 2.2.0 tar.gz file, unpacking, autoreconf -fiv to generate configure, followed by ./configure --prefix=/usr/local, make, and then

make prefix=/usr/local/stow/Utilities/stow-2.2.0  install
 Not in a git repository; can't update ChangeLog.
 make[1]: Entering directory `/usr/src/build/stow-2.2.0'
  /bin/mkdir -p '/usr/local/stow/Utilities/stow-2.2.0/bin'
  /usr/bin/install -c bin/stow bin/chkstow '/usr/local/stow/Utilities/stow-2.2.0/bin'
 Not in a git repository; can't update ChangeLog.
  /bin/mkdir -p '/usr/local/stow/Utilities/stow-2.2.0/share/doc/stow'
  /usr/bin/install -c -m 644 README doc/manual.pdf doc/manual-single.html doc/version.texi ./ChangeLog doc/ChangeLog.OLD '/usr/local/stow/Utilities/stow-2.2.0/share/doc/stow'
 /usr/bin/install: cannot stat './ChangeLog': No such file or directory
 make[1]: *** [install-dist_docDATA] Error 1
 make[1]: Leaving directory `/usr/src/build/stow-2.2.0'
 make: *** [install-am] Error 2

Surely it should be possible to build and install from the latest relase tar file without such an error?

Stow currently will not work with some directories contains trailing and leading spaces, that because the sanitize_path_options removed those spaces:

    if (exists $options->{dir}) {
        $options->{dir}    =~ s/\A +//;
        $options->{dir}    =~ s/ +\z//;
    }

and:

    if (exists $options->{target}) {
        $options->{target} =~ s/\A +//;
        $options->{target} =~ s/ +\z//;
        usage("--target value '$options->{target}' is not a valid directory")
            unless -d $options->{target};

    }

So with two distinct directories " 123" and "123", stow will treat them as the same.

I'm not sure it's intended behavior or not. I attempted a commit to fix it. If it's okay, I will go with a pull request.

Apparently INSTALL.md is incomplete and/or there are other issues with building from git rather than from a distribution tarball:

• [ ] #1 (stow release 2.2.0 install fails because no ChangeLog created because not a git repository) (irrelevant to this issue which is about building from git)
• issues with aclocal
• issues with texi2html (refiled as #21)
• configure and Makefile are missing (fixed by running autoreconf)

We should be able to steal stuff from HOWTO-RELEASE to address this.

Currently, running stow --simulate does not report files that would be adopted with --adopt. For example,

$ mkdir -p stow/test && cd stow
$ echo Text > ../file
$ touch test/file
$ stow --adopt test --simulate
WARNING: in simulation mode so not modifying filesystem.

No actions that stow would perform are reported, even though actually running stow --adopt test would adopt the file file:

$ stow -v --adopt test
MV: file -> stow/test/file
LINK: file => stow/test/file

Currently, empty STOW_DIR cause stow dir to be set to user home directory, specified by $ENV{HOME} variable:

$ pwd
/tmp
$ STOW_DIR= stow -v3 -n -D vim74
Possible precedence issue with control flow operator at /usr/share/perl5/Stow.pm line 1736.
Use of chdir('') or chdir(undef) as chdir() is deprecated at /usr/share/perl5/Stow/Util.pm line 183, <DATA> line 18.
stow dir is /home/cuonglm
stow dir path relative to target . is ../home/cuonglm
cwd now .
stow: ERROR: The stow directory ../home/cuonglm does not contain package vim74 (No such file or directory)

This can lead to un-expected behavior and security problem.

This pull request fix the issue by setting stow dir to current working directory and give a message warning.

Do you have a recommendation?

Paging @jvkersch in case he has any insight.

I use stow to manage my dotfiles. If I am trying to stow my config for zathura, I run stow --dotfiles zathura from ~/dotfiles, which contains zathura/dot-config/zathura/zathurarc. This outputs:

stow: ERROR: stow_contents() called with non-directory path: dotfiles/zathura/.config

I have no problem if I change the path to zathura/.config. Furthermore, stow --dotfiles bash works fine on the file bash/dot-bashrc. It only fails with directories.

I'll freely admit I know little of the internals here, so I'm sorry if I'm just misunderstanding how to use it. But the error message makes it seem like stow is converting the path before getting the path contents and stowing, when it should be getting the path contents, then converting the path, and finally stowing.

Thanks for any insight you can provide.

This is important because of the new "--dotfiles" option.
I searched the entire Internet the best as I could, can't find an answer
Apologies if I missed something.

in 2016:

http://git.savannah.gnu.org/cgit/stow.git/commit/?id=94b155d99b9276d9ead42f5fd2ed88663dca39c1
author | Adam Spiers [email protected] | 2016-11-20 21:45:17 +0000
+* Changes in version 2.3.0
+** New --dotfiles option

in 2017:

[Stow-devel] Release 2.3.0?
http://lists.gnu.org/archive/html/stow-devel/2017-10/msg00000.html
Date: Fri, 27 Oct 2017 23:12:56 +0200
Hi,Would it be possible to have 2.3.0 released?
Regards, Leo

in 2018:

https://savannah.gnu.org/bugs/?54272
Submitted on:  Sun 08 Jul 2018 09:30:10 PM UTC
GNU Stow - Bugs: bug #54272, Version 2.3.0 untagged [Savannah]
I would like to second that a new release be made.

Or at least that's what I suspect because after using stow with -R the last modified date of the links does not change. Whereas if I run a -D and an -S after eachother it does (because then it really removes and adds it back).

And because the help page claims -R is like an -S after a -D but this proves otherwise

The only other flags I'm using is -d and -t

With perl v5.20.2 (eg on Debian 8.6), the latest version of stow r.c171ca8 builds just fine.

However, with a more uptodate recent version of perl v5.22.1 (eg on Linux Mint 18, Ubuntu 16.04), building of the manual page fails.

[ -d doc ] || mkdir doc # required in vpath mode
sed -e 's|[@]PERL[@]|/usr/bin/perl|g' -e 's|[@]VERSION[@]|2.2.2|g' -e   "s|[@]USE_LIB_PMDIR[@]|$use_lib_pmdir|g" < bin/stow.in | pod2man > doc/stow.8
IO::File=IO(0x829a3c4) around line 1: No name given for document
POD document had syntax errors at /usr/bin/pod2man line 68.
Makefile:1530: recipe for target 'doc/stow.8' failed
make: *** [doc/stow.8] Error 255

Thanks to Robert Munteanu providing the solution on Stackoverflow, adding a --name parameter with a document name (eg stow.8) resolves the issue.

Here is a patch to Makefile.am to add the necessary parameter to pod2man

001_Makefile.am.patch.txt

As --name is not compulsory for pod2man, it seems that it is because of the pipeline being used that the newer version of pod2man now falls over.

Splitting the line into two and using a temporary file

 sed -e 's|[@]PERL[@]|/usr/bin/perl|g' -e 's|[@]VERSION[@]|2.2.2|g' -e "s|[@]USE_LIB_PMDIR[@]|$use_lib_pmdir|g" < bin/stow.in > XXX

 pod2man XXXtmpfileXXX > doc/stow.8

works just fine without giving pod2man the --name stow.8 parameter, whereas

cat XXXtmpfileXXX | pod2man

complains with

IO::File=IO(0x9420284) around line 1: No name given for document

[This feature request was originally confused with #11 and reported there; moving here to stop the confusion.]

Example use case given by @dmarcoux is a Stow package containing dotfiles for $HOME, in which .mysql_history, .bash_history, and .less_history are symlinks to /dev/null.

Currently Stow refuses to stow these absolute symlinks:

WARNING! stowing home would cause conflicts:
  * source is an absolute symlink dotfiles/home/.bash_history => /dev/null
  * source is an absolute symlink dotfiles/home/.lesshst => /dev/null
  * source is an absolute symlink dotfiles/home/.mysql_history => /dev/null
All operations aborted.

To clarify:

• This issue is about package trees containing absolute symlinks.
• #11 is about the Stow directory being a symlink.
• #3 is about the symlinks which Stow manages in the target directory being absolute symlinks.

They're all separate issues despite appearing similar on the surface.

Hi, Apologies if this is a dumb question/issue

My usecase is this:
I have a directory called "dotfiles" in my homedir, this is managed by stow and all packages in it are located in my homedir so no stowrc tinkering is needed

I have another directory called "dotfiles-extra" which manages packages outside of the homedir
Since the packages here need to be in /etc which is outside of my homedir and starts with a /, i need to use a stowrc to manually set the target.

So i use --target=/ ssh in my stowrc to stow my ssh config file to /etc/ssh with the contents of "ssh" being etc/ssh/sshd_config

The issue I'm having is I am trying to merge both directories into one big dotfile directory for ease of use/access but I can't seem to use stow with both homedir targets and targets outside of the homedir, this could possibly be solved if stow could check if the first directory in a package is called ROOT or another keyword and this would indicate to stow that the package should be linked outside of the users home directory, that way you could just run stow ssh as normal.

This would mean if I wanted to stow my ssh config the package dir would look like this ROOT/etc/ssh/sshd_config and would symlink to /etc/ssh/sshd_config

(I'd try implement this myself but my perl knowledge is very limited)

I've read through the manpage a few times and experimented many times with various methods but my best solution is to keep packages that require a location outside of the homedir in a separate repo with a stowrc that specifies the target outside of $HOME.

Would it be possible to use stow on a single repo that contains both non-homedir packages and homedir packages without using a different stow command for each package?

Apologies if this sounds like gibberish, I thought it'd be easier to explain before I typed all this up.

Using $ENV{HOME} to get the user home directory is not always safe, example:

unset HOME; perl -le 'print $ENV{HOME}'

and also using glob with tilde expansion, since when it's relied on HOME variable, and the result is unspecified when HOME is unset.

Should we add a method to get the user home directory more safely, using something like getpwnam?

The function that parses .stowrc files, get_config_file_options, splits .stowrc file on spaces. Thus, if a file path or regex has a space, the option breaks because get_config_file_options treats it as two options instead of one. In order to get the correct behavior, a more complicated split function that respects escapes would need to be implemented.

Stow doesn't want to stow absolute symlinks because of this code. Why?

To reproduce:

$ mkdir -p /tmp/temp/stow ; cd /tmp/temp/stow
$ mkdir pkg
$ ln -s /run/systemd/resolve/resolv.conf pkg/resolv.conf
$ stow -t /tmp/temp -d . -S pkg
WARNING! stowing pkg would cause conflicts:
  * source is an absolute symlink stow/pkg/resolv.conf => /run/systemd/resolve/resolv.conf
All operations aborted.

$ find /tmp/temp '!' -type d -printf "%p -> %l\n"
/tmp/temp/stow/pkg/resolv.conf -> /run/systemd/resolve/resolv.conf

Well, I can create a temporary directory with this absolute link and make the stow-ed link relative to that link, like:

$ cd /tmp/temp/stow
$ mkdir -p /tmp/temp/stow/somedir
$ ln -s  /run/systemd/resolve/resolv.conf somedir/resolv.conf
$ ln -sf ../somedir/resolv.conf pkg/resolv.conf
$ stow -t /tmp/temp -d . -v -S pkg
LINK: resolv.conf => stow/pkg/resolv.conf

$ find /tmp/temp '!' -type d -printf "%p -> %l\n"
/tmp/temp/resolv.conf -> stow/pkg/resolv.conf
/tmp/temp/stow/stupid/resolv.conf -> /run/systemd/resolve/resolv.conf
/tmp/temp/stow/pkg/resolv.conf -> ../stupid/resolv.conf

but that looks strange as it requires a temporary directory that does nothing really. Alternatively a directory may be added with the absolute symlink, relative symlink to that directory and that directory is listed in --ignore rules.

Is there specific reason why absolute symlinks from stow directory can't be stow-ed? If so, is a symlink to an absolute symlink going to cause any harm? Why care and not just stow a symlink to that absolute symlink just as-if it would be a file?

Another alternative is making my symlink relative to repo location, like ln -s ../../../../constant_count_of_../../../run/systemd/resolve/resolv.conf, but that's assuming I will clone my repo to the same dir.

I tried searching/reading https://lists.gnu.org/archive/html/stow-devel/2009-11/msg00000.html and the issues here, but didn't find anything, I would appreciate some pointers.