Consider this script.
#! /usr/bin/env bash mkdir -p target mkdir -p mydir/package/ touch mydir/package/file ln --symbolic mydir mylink file mylink stow --verbose --dir=./mylink --target=./target package file target/file
The output is
mylink: symbolic link to mydir LINK: file => ../mydir/package/file target/file: symbolic link to ../mydir/package/file
stow, it looks like this:
. ├── mydir │ └── package │ └── file ├── mylink -> mydir └── target
mylink, I expected it to look like this:
. ├── mydir │ └── package │ └── file ├── mylink -> mydir └── target └── file -> ../mylink/package/file
However, instead it looks like this:
. ├── mydir │ └── package │ └── file ├── mylink -> mydir └── target └── file -> ../mydir/package/file
It seems that the
stow command resolves the realpath of the package directory, so instead of pointing to
../mylink/package/file it points to
This makes sense for avoiding too much indirection, but it happens silently and may not always be desirable. Is there a way to work around this behavior?
Edit: As per request, I will describe an example use case where resolving the realpath is inconvenient.
Symbolic links are sometimes used for compatibility.
Debian even talks about this in official policy.
Often the target is a single file,
but sometimes it is a directory
I happen to have a few hundred on my system in
$ find /usr/share/doc -xtype d -type l | wc -l 325
The default behavior of
stow is fine
as long as the symlink target doesn't get moved.
But sometimes the desired targeted directory does get moved.
For example, on Debian, the
installs files under /usr/share/vim/
in a directory that depends on the version,
/usr/share/vim/vim64 for version 6.4.
However, the package would also update a symlink
/usr/share/vim/vimcurrent that pointed to the current version.
This means that a symlink pointing to, say
would break when the next release of Debian upgraded it to
but a symlink to
would work in both versions.
stow uses the absolute canonical path of the stow directory,
an invocation like
stow --dir=/usr/share/vim/vimcurrent --target=./my-vim-docs doc
would result in symbolic links like, e.g. this:
$ file cmdline.txt cmdline.txt: symbolic link to ../../../../../usr/share/vim/vim64/doc/cmdline.txt
not like this:
$ file cmdline.txt cmdline.txt: symbolic link to ../../../../../usr/share/vim/vimcurrent/doc/cmdline.txt
(The motivation for using
is to be able to mingle my own vim notes alongside symlinks to the current documentation.)
Note that the
vimcurrent compatibility symlink is
no longer present in current Debian distributions,
though it may be in others like Arch Linux;
I'm not sure.
In any case, here's a script that gives the general idea for vim documentation:
#! /usr/bin/env bash mkdir -p target ln --symbolic /usr/share/vim/vim80 vimcurrent stow --verbose --dir=./vimcurrent --target=./target pack file target/dist
LINK: dist => ../../../../../usr/share/vim/vim80/pack/dist target/dist: symbolic link to ../../../../../usr/share/vim/vim80/pack/dist
stow could have a flag called, say,
so the output would look something like this instead:
LINK: dist => ./vimcurrent/pack/dist target/dist: symbolic link to ./vimcurrent/pack/dist
For other examples of compatibility symlinks that change with each version, here are two more I know of on my laptop:
$ file /usr/share/go /usr/share/go: symbolic link to go-1.10 $ file /usr/share/mscore /usr/share/mscore: symbolic link to mscore-2.1
To address the symlink-points-to-symlink case:
#! /usr/bin/env bash mkdir -p target mkdir -p mydir/package/ touch mydir/package/file ln --symbolic mydir mylink ln --symbolic mylink mylink2 namei mylink2
f: mylink2 l mylink2 -> mylink l mylink -> mydir d mydir
$ stow --verbose --dir=./mylink2 --target=./target package $ file target/file
LINK: file => ../mydir/package/file target/file: symbolic link to ../mydir/package/file
$ stow --no-realpath --verbose --dir=./mylink2 --target=./target package $ file target/file
would produce this:
LINK: file => ../mylink2/package/file target/file: symbolic link to ../mylink2/package/file
So in the hypothetical
--no-realpath behavior it would treat the stow directory as a regular directory.
This feature would be applicable in a scenario where
1) the stow directory has to be a symlink, and
2) it is desirable to preserve that link in the generated symlinks.
While I don't consider the lack of this feature a great deficiency of
I hope that this example clarifies the potential usefulness
of not always resolving canonical paths.