GNU Stow可以使用作为符号链接的stow目录吗？

考虑这个脚本。

#! /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

输出是

mylink: symbolic link to mydir
LINK: file => ../mydir/package/file
target/file: symbolic link to ../mydir/package/file

在运行之前stow，它看起来像这样：

.
├── mydir
│   └── package
│       └── file
├── mylink -> mydir
└── target

运行后stow，上mylink，我希望它看起来像这样：

.
├── mydir
│   └── package
│       └── file
├── mylink -> mydir
└── target
    └── file -> ../mylink/package/file

但是，它看起来像这样：

.
├── mydir
│   └── package
│       └── file
├── mylink -> mydir
└── target
    └── file -> ../mydir/package/file

似乎该stow命令解析了软件包目录的realpath，因此../mylink/package/file与其指向它而不是指向../mydir/package/file。

这对于避免过多的间接访问是有道理的，但是它是默默发生的，可能并不总是希望的。有没有一种方法可以解决此问题？

编辑：根据请求，我将描述解决实际路径不方便的示例用例。

符号链接有时用于兼容性。Debian甚至在官方政策中谈到了这一点。目标通常是一个文件，但有时它是一个目录 。我碰巧/usr/share/doc/独自在系统上有几百个：

$ find /usr/share/doc -xtype d -type l | wc -l
325

stow只要没有移动符号链接目标，默认行为就很好。但是有时所需的目标目录确实被移动了。例如，在Debian上，该vim-runtime软件包将文件安装在/ usr / share / vim /下的依赖于版本的目录中，例如/usr/share/vim/vim646.4版。但是，包也将更新一个符号链接 在/usr/share/vim/vimcurrent该尖到最新版本。这意味着符号链接指向

/usr/share/vim/vim64/doc/cmdline.txt

在下一版本的Debian升级到

/usr/share/vim/vim70/doc/cmdline.txt

而是一个符号链接

/usr/share/vim/vimcurrent/doc/cmdline.txt

在两个版本中都可以使用。

由于stow使用存储目录的绝对规范路径，因此调用类似于

stow --dir=/usr/share/vim/vimcurrent --target=./my-vim-docs doc

会导致符号链接，例如：

$ file cmdline.txt
cmdline.txt: symbolic link to ../../../../../usr/share/vim/vim64/doc/cmdline.txt

不像这样：

$ file cmdline.txt
cmdline.txt: symbolic link to ../../../../../usr/share/vim/vimcurrent/doc/cmdline.txt

（使用stowon 的动机vimcurrent/docs 是能够将我自己的vim注释与当前文档的符号链接混合在一起。）请注意，vimcurrent兼容性符号链接 在当前的Debian发行版中不再存在， 尽管它可能在诸如Arch Linux之类的其他版本中出现；我不确定。无论如何，下面的脚本给出了vim文档的一般概念：

#! /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可能有一个称为的标志--no-realpath，因此输出看起来像这样：

LINK: dist => ./vimcurrent/pack/dist
target/dist: symbolic link to ./vimcurrent/pack/dist

有关随版本不同而变化的兼容性符号链接的其他示例，以下是我在笔记本电脑上了解的两个：

$ 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

要解决符号链接到符号链接的情况：

#! /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

会产生这个：

LINK: file => ../mylink2/package/file
target/file: symbolic link to ../mylink2/package/file

因此，在假设的--no-realpath行为中，它将把存放目录视为常规目录。

此功能适用于以下情况

1）存放目录必须是一个符号链接，并且

2）希望在生成的符号链接中保留该链接。

尽管我不认为缺少此功能会导致严重不足stow，但我希望该示例阐明并非总是解决规范路径的潜在用处。

目前，还没有办法。

在内部，stow使用chdir进入路径，找到给定路径的绝对规范路径，然后使用POSIX模块的getcwd（）函数（即POSIX getcwd（）的Perl接口）获取绝对路径名。

按照POSIX的规定，路径名不得包含.或..或符号链接的任何组件。