![GNU Stow 可以使用作为符号链接的 stow 目录吗?](https://linux22.com/image/78644/GNU%20Stow%20%E5%8F%AF%E4%BB%A5%E4%BD%BF%E7%94%A8%E4%BD%9C%E4%B8%BA%E7%AC%A6%E5%8F%B7%E9%93%BE%E6%8E%A5%E7%9A%84%20stow%20%E7%9B%AE%E5%BD%95%E5%90%97%EF%BC%9F.png)
考虑这个脚本。
#! /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
, on后mylink
,我期望它看起来像这样:
.
├── mydir
│ └── package
│ └── file
├── mylink -> mydir
└── target
└── file -> ../mylink/package/file
然而,它看起来像这样:
.
├── mydir
│ └── package
│ └── file
├── mylink -> mydir
└── target
└── file -> ../mydir/package/file
该命令似乎stow
解析了包目录的实际路径,因此不是指向../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/vim64
版本 6.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 目录的绝对规范路径,因此像这样的调用
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
stow
(使用on 的动机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
行为中,它将把 stow 目录视为常规目录。
该功能适用于以下场景
1) stow 目录必须是符号链接,并且
2)最好在生成的符号链接中保留该链接。
虽然我不认为缺乏此功能是 的重大缺陷stow
,但我希望这个示例能够阐明并不总是解析规范路径的潜在用处。
答案1
目前来说,没有办法。
在内部,stow
通过使用查找给定路径的绝对规范路径目录移动到路径中,然后使用获取cwd()POSIX 模块中的函数,它是 Perl 接口POSIX getcwd(),获取绝对路径名。
正如 POSIX 所规定的,路径名不应包含.
或..
、 或 符号链接的组件。