O GNU Stow pode usar um diretório de armazenamento que é um link simbólico?

Considere este 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

A saída é

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

Antes de executar stow, fica assim:

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

Depois de executar stow, mylinkeu esperava que fosse assim:

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

No entanto, em vez disso, fica assim:

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

Parece que o stowcomando resolve o caminho real do diretório do pacote; portanto, em vez de apontar para ../mylink/package/fileele, aponte para ../mydir/package/file.

Isso faz sentido para evitar muita indireção, mas acontece silenciosamente e nem sempre é desejável. Existe uma maneira de contornar esse comportamento?

Editar: conforme solicitação, descreverei um exemplo de caso de uso em que a resolução do caminho real é inconveniente.

Links simbólicos às vezes são usados ​​para compatibilidade . O Debian até fala sobre isso na política oficial . Geralmente, o destino é um único arquivo, mas às vezes é um diretório . Por acaso, tenho algumas centenas no meu sistema /usr/share/doc/sozinho:

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

O comportamento padrão de stowé bom, desde que o destino do link simbólico não seja movido. Mas, às vezes, o diretório de destino desejado é movido. Por exemplo, no Debian, o vim-runtimepacote instala arquivos em / usr / share / vim / em um diretório que depende da versão, como /usr/share/vim/vim64na versão 6.4. No entanto, o pacote também atualizar um link simbólico em /usr/share/vim/vimcurrentque apontava para a versão atual. Isso significa que um link simbólico apontando para, digamos

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

quebraria quando o próximo lançamento do Debian o atualizasse para

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

mas um link simbólico para

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

funcionaria em ambas as versões.

Como stowusa o caminho canônico absoluto do diretório stow, uma chamada como

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

resultaria em links simbólicos como, por exemplo, este:

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

Assim não:

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

(A motivação para usar stowon vimcurrent/docs é poder misturar minhas próprias notas do vim com links simbólicos para a documentação atual.) Observe que o vimcurrentlink simbólico de compatibilidade não está mais presente nas distribuições atuais do Debian , embora possa estar em outras como o Arch Linux ; Não tenho certeza. De qualquer forma, aqui está um script que fornece a idéia geral da documentação do 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

A saída é:

LINK: dist => ../../../../../usr/share/vim/vim80/pack/dist
target/dist: symbolic link to ../../../../../usr/share/vim/vim80/pack/dist

Hipoteticamente, stowpoderia ter uma bandeira chamada, digamos --no-realpath, para que a saída se parecesse com isso:

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

Para outros exemplos de links simbólicos de compatibilidade que mudam a cada versão, aqui estão mais dois que eu conheço no meu 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

Para abordar o caso de links simbólicos para links simbólicos:

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

produz:

f: mylink2
 l mylink2 -> mylink
   l mylink -> mydir
     d mydir

e depois:

$ stow --verbose --dir=./mylink2 --target=./target package
$ file target/file

produz:

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

enquanto que

$ stow --no-realpath --verbose --dir=./mylink2 --target=./target package
$ file target/file

produziria o seguinte:

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

Portanto, no --no-realpathcomportamento hipotético , ele trataria o diretório stow como um diretório regular.

Esse recurso seria aplicável em um cenário em que

1) o diretório stow deve ser um link simbólico e

2) é desejável preservar esse link nos links simbólicos gerados.

Embora eu não considere a falta desse recurso uma grande deficiência stow, espero que este exemplo esclareça a utilidade potencial de nem sempre resolver caminhos canônicos.

Por enquanto, não há como.

Internamente, stowencontre o caminho canônico absoluto de determinado caminho usando chdir para ir para o caminho e use a função getcwd () do módulo POSIX, que é a interface Perl do POSIX getcwd () , para obter o nome absoluto do caminho.

Como POSIX especificado, o nome do caminho não deverá conter componentes que são .ou .., ou são links simbólicos.