क्या ग्नू स्टो एक स्टोव निर्देशिका का उपयोग कर सकता है जो एक प्रतीकात्मक लिंक है?


10

इस लिपि पर विचार करें।

#! /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ठीक है, जब तक कि सिमलिंक लक्ष्य स्थानांतरित नहीं हो जाता है। लेकिन कभी-कभी वांछित लक्षित निर्देशिका स्थानांतरित हो जाती है। उदाहरण के लिए, डेबियन पर, vim-runtimeपैकेज एक निर्देशिका में / usr / share / vim / के तहत फाइलों को इंस्टॉल करता है जो संस्करण पर निर्भर करता है, जैसे कि /usr/share/vim/vim64संस्करण 6.4 के लिए। हालांकि, पैकेज भी होगा एक सिमलिंक अद्यतन पर /usr/share/vim/vimcurrentवर्तमान संस्करण में कि उठाई। इसका मतलब यह है कि एक सिमलिंक की ओर इशारा करते हुए, कहते हैं

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

तब टूटेगा जब डेबियन की अगली रिलीज ने इसे अपग्रेड किया

/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

(उपयोग करने के लिए प्रेरणा stowपर vimcurrent/docs कि नोट। वर्तमान प्रलेखन के लिए सिमलिंक के साथ-साथ अपने ही vim नोट्स आपस में मिलना करने में सक्षम होना है) vimcurrentअनुकूलता सिमलिंक है कोई मौजूदा डेबियन वितरण में लंबे समय तक वर्तमान , हालांकि यह आर्क लिनक्स जैसे अन्य लोगों में हो सकता है ; मुझे यकीन नहीं है। किसी भी स्थिति में, यहां एक स्क्रिप्ट है जो विम प्रलेखन के लिए सामान्य विचार देती है:

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

Hypothetically, 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, लेकिन मुझे उम्मीद है कि यह उदाहरण हमेशा कैनोनिकल रास्तों को हल न करने की संभावित उपयोगिता को स्पष्ट करता है।


क्या आप एक उदाहरण उपयोग का मामला दे सकते हैं जहां इस अप्रत्यक्षता से बचना सहायक होगा? क्या होगा अगर mylinkबजाय सांकेतिक रूप से लिंक करने के लिए mylink2है जो बदले में सांकेतिक रूप से लिंक mydir? कैसे स्टो तय करना चाहिए कि क्या यह की तरफ निर्देशित सिमलिंक बनाने चाहिए ../mylink/package/fileया ../mylink2/package/fileया ../mydir/package/file?
एडम स्पियर्स

@AdamSpiers मुझे उम्मीद है कि कुछ हद तक मदद मिलेगी। मैं इसे जीथब इश्यू ट्रैकर पर भी रख सकता हूं, यदि आप चाहें तो।
नाथनील एम। बीवर

धन्यवाद @ नथनियल हाँ, कृपया मददगार होगा!
एडम स्पियर्स

जवाबों:


7

अभी के लिए, कोई रास्ता नहीं है।

आंतरिक रूप से, stowपथ में जाने के लिए chdir का उपयोग करके दिए गए पथ के निरपेक्ष विहित पथ को खोजें , फिर POSIX मॉड्यूल से getcwd () फ़ंक्शन का उपयोग करें , जो कि POSIX getcwd () के लिए पर्ल इंटरफ़ेस है , निरपेक्ष पथ नाम प्राप्त करने के लिए।

जैसा कि POSIX निर्दिष्ट किया गया है, पथ नाम में ऐसे घटक नहीं होंगे जो .या हैं .., या प्रतीकात्मक लिंक हैं।


1
इसे सही ढंग से संभालने के लिए कार्यान्वयन को कैसे ठीक किया जाए, इस पर सुझाव बहुत स्वागत योग्य हैं। पुल अनुरोधों का और भी स्वागत है! :-) संदर्भ के लिए, इस मुद्दे को यहां बताया गया है: github.com/aspiers/stow/issues/11
एडम स्पियर्स
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.