Чи може 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команда вирішує реальний шлях каталогу пакунків, тому замість вказівки на ../mylink/package/fileнього вказує на ../mydir/package/file.

Це має сенс уникати занадто великої непрямості, але це відбувається мовчки і може не завжди бути бажаним. Чи є спосіб обійти цю поведінку?

Редагувати: Відповідно до запиту я опишу приклад використання випадків, коли вирішення дійсного шляху незручне.

Для сумісності іноді використовуються символьні посилання . Дебіан навіть говорить про це в офіційній політиці . Часто ціль - це один файл, але іноді це каталог . Я, мабуть, у своїй системі кілька сотень /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в 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

Щоб вирішити випадок sylink-point-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

виробляє:

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, я сподіваюся, що цей приклад роз'яснює потенційну корисність не завжди вирішення канонічних шляхів.

Поки що немає способу.

Внутрішньо stowзнайдіть абсолютний канонічний шлях заданого шляху, використовуючи chdir для переміщення в шлях, а потім використовуйте функцію getcwd () з модуля POSIX, що є інтерфейсом Perl для POSIX getcwd () , щоб отримати абсолютну назву шляху.

Як зазначено POSIX, ім'я шляху не повинно містити компоненти , які є .або .., або є символічними посиланнями.