Symlink'in hedefi hedefin üst dizinine göreli midir ve öyleyse neden?


14

Aşağıdaki dosya yapısına sahibim:

build/
client/
  –> index.js

Ve cwd'deki istemci dizinine atıfta bulunan derleme dizininde "client" adlı sembolik bir bağlantı oluşturmaya çalıştığımda

// Fails
$ pwd
/home/user/
$ ln -s client build/client 
$ stat build/client/index.js
stat: build/client/index.js: stat: Too many levels of symbolic links

Yukarıda görüntülenen ELOOP hatasını alıyorum. Hedef yolu hedef yola göre olacak şekilde değiştirdiğimde, hepsi iyi:

// Works
$ pwd
/home/user/
$ ln -s ../client build/client 
$ stat build/client/index.js
stat: <outputs file stats>

Bu amaçlanan davranış mı ve lütfen nedenini açıklayın ...


bunun muhtemelen ../ kullanmanın bağıl yol yerine yol bildirmek için mutlak yol kullanmasıyla bir ilgisi vardır. iyi bir uygulama her zaman mutlak yolu kullanmaktır
Kiwy

Hem hedef hem de hedef için her zaman mutlak yollar kullandığım için en iyi uygulamayı kabul ediyorum. Ancak, man sayfaları göreli yolların her ikisi için de kullanılabileceğini
belirtiyor

Yanıtlar:


13

Çalışmayan için, ls -lsonuca bakarsak, aşağıdakileri elde ederiz:

[sparticvs@sparta test]$ ls -l build/
total 0
lrwxrwxrwx. 1 sparticvs sparticvs 6 Dec 17 16:08 client -> client

Şimdi burada neler olduğunu anlamak için. Aradığın komuta bakalım:

ln -s client build/client

Man Sayfasına göre, bu format için iki olası eşleşme var

SYNOPSIS
       ln [OPTION]... [-T] TARGET LINK_NAME   (1st form)
       ln [OPTION]... TARGET... DIRECTORY     (3rd form)

İlk formda eşleşecektir (ilkinden beri). Şimdi, "hedef adı" veya clientsizin durumunuzda, (tüm lnkılavuza göre) rastgele dizeler olabilir. Şu anda hiçbir şeye çözüm bulmak zorunda değiller, ancak gelecekte bir şeye çözüm bulabilirler. Çağrınızla yarattığınız şey "sarkan bir sembolik bağlantıdır" ve sistem bunları oluşturmanızı engellemez.

Şimdi ikinci çağrınız ln -s ../client build/client"göreceli symlink" (kendi mesajınızda belirttiğiniz gibi). İkinci bir tür var ve bu "çağrılan" mutlak bir sembolik bağlantıdır ln -s /home/user/client build/client.

Bu bir hata değil . El kitabına göre şunları belirtiyor:

Geçerli dizinden farklı bir konumda göreli bir sembolik bağlantı oluştururken, sembolik bağlantının çözünürlüğü, aynı dizenin geçerli dizinden çözünürlüğünden farklı olacaktır. Bu nedenle, birçok kullanıcı önce dizinleri göreli symlink'in oluşturulacağı konuma değiştirmeyi tercih eder, böylece sekme tamamlama veya başka bir dosya çözünürlüğü, sembolik bağlantıya yerleştirilecek hedefle aynı hedefi bulur.

- itibaren info coreutils 'ln invocation'

Bununla birlikte, hedefe göreli veya mutlak yolu kullanmanız GEREKİR .


5

Gerçekten de amaçlanan davranış budur. Gönderenln(1) adam sayfası:

Sembolik bağlantılar keyfi metin içerebilir; daha sonra çözümlenirse, göreli bir bağlantı üst dizinine göre yorumlanır.

Bunun nedenine gelince, sembolik bağın yerine hedefinden ziyade kaynağına göre yorumlanıp yorumlanmadığını hayal edin. Daha sonra çözerken, imkansız olan, saçma olan CWD'nizin ne zaman yaratıldığını bilmeniz gerekir.

Dahası, bu şekilde, sembolik bağlantıları bozmadan dizin ağacının herhangi bir yerine bırakabileceğiniz iskelet dizin yapısı oluşturmak için düzgün ve kompakt bir yöntem elde edersiniz.

Ne demek istediğime bir örnek vermek için, bir proje üzerinde çalıştığınızı ve bunun için kurulmuş bir dizin yapınızın olduğunu varsayalım:

$ ls -1 /home/you/project
thingummies/
widgets/
wizardry/

Şimdi widgets/içeride bir simge bağlantısı oluşturmak istediğinizi varsayalım wizardry/. İki seçeneğiniz var:

$ ln -s /home/you/project/widgets /home/you/project/wizardry

veya

$ ln -s ../widgets /home/you/project/wizardry

Daha sonra /home/you/projectbaşka bir yere taşınmayı denerseniz , ilk formla oluşturulan bir symlink aradığı için kesilir /home/you/project/widgets. İkinci form, sembolik bağlantının işlevselliğini koruyacaktır, çünkü o yerin dizin ağacında nerede olabileceğine bakılmaksızın, bulunduğu yere ../widgets göre arar .

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.