GNU Stow può usare una directory stow che è un collegamento simbolico?

Considera questo 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

L'output è

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

Prima di correre stow, si presenta così:

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

Dopo l'esecuzione stow, mylinkmi aspettavo che fosse così:

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

Tuttavia, invece si presenta così:

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

Sembra che il stowcomando risolva il percorso reale della directory del pacchetto, quindi invece di puntare a ../mylink/package/fileesso punta a ../mydir/package/file.

Questo ha senso per evitare troppe indirette, ma accade in silenzio e potrebbe non essere sempre desiderabile. C'è un modo per aggirare questo comportamento?

Modifica: come da richiesta, descriverò un caso d'uso di esempio in cui la risoluzione del percorso reale è scomoda.

I collegamenti simbolici vengono talvolta utilizzati per la compatibilità . Debian ne parla persino nella politica ufficiale . Spesso la destinazione è un singolo file, ma a volte è una directory . Mi capita di avere poche centinaia sul mio sistema /usr/share/doc/da solo:

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

Il comportamento predefinito di stowva bene finché la destinazione del collegamento simbolico non viene spostata. Ma a volte viene spostata la directory di destinazione desiderata. Ad esempio, su Debian, il vim-runtimepacchetto installa i file in / usr / share / vim / in una directory che dipende dalla versione, come /usr/share/vim/vim64per la versione 6.4. Tuttavia, il pacchetto aggiornerebbe anche un collegamento simbolico a /usr/share/vim/vimcurrentquello puntato alla versione corrente. Ciò significa che un collegamento simbolico che punta a, diciamo

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

si spezzerebbe quando la prossima versione di Debian lo aggiornerà a

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

ma un link simbolico a

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

funzionerebbe in entrambe le versioni.

Dato che stowutilizza il percorso canonico assoluto della directory stow, una chiamata come

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

si tradurrebbe in collegamenti simbolici come, ad esempio, questo:

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

non così:

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

(La motivazione per usare stowon vimcurrent/docs è quella di essere in grado di mescolare le mie note vim con i collegamenti simbolici alla documentazione corrente.) Si noti che il vimcurrentcollegamento simbolico di compatibilità non è più presente nelle attuali distribuzioni Debian , sebbene possa essere in altri come Arch Linux ; Non ne sono sicuro. In ogni caso, ecco uno script che dà l'idea generale per la documentazione di 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

L'output è:

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

Ipoteticamente, stowpotrebbe avere un flag chiamato, diciamo --no-realpath, quindi l'output dovrebbe assomigliare a questo:

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

Per altri esempi di collegamenti simbolici di compatibilità che cambiano con ogni versione, ecco altri due che conosco sul mio 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

Per affrontare il caso symlink-points-to-symlink:

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

produce:

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

e poi:

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

produce:

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

mentre

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

produrrebbe questo:

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

Quindi, nell'ipotetico --no-realpathcomportamento, la directory stow verrebbe trattata come una directory normale.

Questa funzionalità sarebbe applicabile in uno scenario in cui

1) la directory stow deve essere un collegamento simbolico e

2) è desiderabile conservare quel link nei symlink generati.

Anche se non considero la mancanza di questa funzionalità una grande carenza di stow, spero che questo esempio chiarisca la potenziale utilità di non risolvere sempre i percorsi canonici.

Per ora, non c'è modo.

Internamente, stowtrova il percorso canonico assoluto di un determinato percorso usando chdir per spostarsi nel percorso, quindi usa la funzione getcwd () dal modulo POSIX, che è l'interfaccia Perl per POSIX getcwd () , per ottenere il nome del percorso assoluto.

Come specificato da POSIX, il nome del percorso non deve contenere componenti che sono .o ..o sono collegamenti simbolici.