Wskazówki dotyczące zapamiętywania kolejności parametrów dla ln?

Od lat lnpiszę dowiązania symboliczne, ale wciąż nie rozumiem kolejności parametrów.

Zwykle piszę:

ln -s a b

a następnie patrząc na wyniki, aby sobie przypomnieć.

Zawsze wyobrażam sobie, że będę a -> btak, jak to czytam, kiedy faktycznie jest odwrotnie b -> a. Jest to sprzeczne z intuicją, więc uważam, że zawsze się zastanawiam.

Czy ktoś ma jakieś wskazówki, które pomogą mi zapamiętać prawidłową kolejność?

Używam następujących: lnma formę jednoparametrową (druga forma wymieniona na stronie podręcznika ), w której wymagany jest tylko cel (ponieważ jak lnw ogóle może działać bez znajomości celu) i lntworzy łącze w bieżącym katalogu. Forma dwuargumentowa jest dodatkiem do formy jednargumentowej, dlatego cel jest zawsze pierwszym argumentem.

Mówię „ lnjest jak cp.„ Źródło ”musi być na pierwszym miejscu”.

Większość Uniksów dokumentuje lnpolecenie jako

ln source target

(Pomijam tutaj opcje itp.)

Przykłady:

• Standard POSIX

  ln [-fs] [-L|-P] source_file target_file
  

• OpenBSD :

  ln [-fhLnPs] source [target]
  

• NetBSD i FreeBSD

  ln [-L | -P | -s [-F]] [-f | -iw] [-hnv] source_file [target_file]
  

• System operacyjny Mac

  ln [-Ffhinsv] source_file [target_file]
  

• Solaris

  /usr/bin/ln [-fns] source_file [target]
  

• AIX

  ln [ -f | -n ] [ -s ] SourceFile [ TargetFile ]
  

Podręcznik GNU lnwywołuje source cel i nazwę target linku .

• Podręcznik GNU dla ln

  ln [option]… [-T] target linkname
  

Ignorując wybór słów GNU, lnnarzędzie stosuje taką samą semantykę jak np. mvI cptym, że celem jest to, co jest tworzone ze źródła .

W związku z tym,

ln -s a b

utworzy dowiązanie symboliczne bwskazujące na a.

Zauważ też, że podczas tworzenia dowiązań symbolicznych źródłem jest po prostu ciąg znaków reprezentujący to, na co powinno wskazywać dowiązanie symboliczne. Zazwyczaj nie sprawdza się, czy wskazuje na coś przydatnego:

$ ln -s "hello world" README.txt
$ ls -l
total 0
lrwxr-xr-x  1 kk  wheel  11 Sep 15 11:39 README.txt -> hello world

Gdyby to pomogło komukolwiek: przyzwyczaiłem się myśleć o tym jako „ln what where ”, co pomaga mi pamiętać, że pierwszy argument („what”) to istniejący plik, drugi („where”) to miejsce umieścić (link do) go. W przeciwieństwie do rozumowania w większości innych odpowiedzi, jest to nic innego, jak tylko zwięzłe zdanie, które mogę sobie w myślach recytować, pisząc polecenie, które służy jako pamięć. Prawdopodobnie nie będzie to przydatne dla wszystkich, ale podejrzewam, że pomoże niektórym ludziom.

Pomaga to, że inne standardowe komendy manipulacji plikami używają tej samej konwencji, więc mogę zrobić to samo dla cpi mv.

Niedawno usłyszałem świetny sposób na zapamiętanie tej konkretnej rzeczy: rymu

Coś starego, coś nowego,

coś pożyczonego, coś niebieskiego,

i sześć pensów w jej bucie.

Pierwszym wierszem są argumenty ln: coś starego, po którym następuje nazwa nowego wpisu katalogu.

NAME    ln -- make a link
SYNOPSIS    ln name1[ name2 ]
DESCRIPTION ln creates a link to an existing file name1. 
            If name2 is given, the link has that name; 

Od podręczników Unix First Edition 1971 .

Istnieje druga prosta forma składni.

edit: I umieścić plik lub FILENAME zamiast TARGET --- zobaczyć komentarze itd. patrz również bardzo długi dodatek na dole, zwracając się do góry lodowej, twarde i miękkie z ln, a nie tylko czubek niego.

GNU lnma to:

ln [opt] FILENAME

In the 2nd form, create a link to FILENAME in the current directory.

gdzie nie potrzebujesz nazwy linku. Po ln -s /usr/lib/modulesotrzymaniu

modules -> /usr/lib/modules

o tej samej nazwie co FILENAME („target” lub „source”), dokładnie tam, gdzie jesteś. Bez wyboru, bez zamieszania.

Teraz, jeśli jesteś bardziej wymagający i chcesz utworzyć link pod inną nazwą i / lub gdzieś indziej , dodaj to życzenie jako nazwę lub ścieżkę. Prawdziwy cel jest na pierwszym miejscu, a druga fantastyczna nazwa nowego linku.

Albo mówisz: „Znam ten zapis strzałki ls -ldla linków. Nie mam strzałki w powłoce, która wskazywałaby kierunek mojego linku. Więc muszę go odwrócić”.

Tworzysz go w jednym kierunku, dzięki czemu możesz go używać w drugim.

(ZAKOŃCZENIE CZĘŚCI ODPOWIEDZI NA PYTANIE)

Na innym poziomie samo słowo „link” ma głęboko ukryte podwójne znaczenie. Powiązania symboliczne pojawiły się później, więc na początku link był tylko linkiem. Nie było miękkiego i twardego, żadnej -sopcji. A teraz używam nawet symboliki target-źródło:

mv    A B   --- move the whole file to B (dir or new name)
cp    A B   --- copy whole file (mv and cp are "the same" here)    
ln    A B   --- copy whole file MINUS data blocks (=copy only inode and name), and increase "link count" for track keeping

Na tym etapie istnieją linki, ale nie ma twardych i miękkich i ls -lnie pokazuje strzałek, ponieważ nie ma kierunku w (twardym) łączu. „Link” na tym etapie ewolucji unixa oznaczał, że nazwa pliku „B” (pozycja katalogu „B”) w systemie plików wskazuje ten sam i-węzeł, na który wskazuje nazwa pliku „A”.

Pliki A i B są „połączone” razem, ponieważ dzielą te same bloki. Więc teraz przy każdym rm jądro musi sprawdzać: czy usuwam / zwalniam bloki tego pliku na dysku, czy też jest inny plik powiązany z tymi samymi blokami? W tym celu wykorzystywany jest licznik linków.

Powiedz, że chcesz zachować duży plik na / tmp grom, który chcesz usunąć ln /tmp/bigfile. Teraz masz duży plik bigfile w swoim reż. Po wyczyszczeniu / tmp i przeniesieniu „oryginału” z przyjemnością korzystasz z tych samych bloków danych. Nie dostajesz martwego lub wiszącego linku, masz normalny plik. Wskazuje brak pliku, a tylko bloki systemu plików, jak robi to każdy wpis katalogu. Dopiero teraz „czyszczenie” / tmp nie jest tak skuteczne jak wcześniej. Wygląda na pustą i jest, ale bloki na partycji nie zwalniają się.

Chociaż twardy link nie kosztuje samego miejsca, jak cp, pośrednio może to zrobić.

Dodanie ln -sdo powyższej sekwencji:

ln -s A B   --- copy only the file's name to "B"   

Teraz „B”, miękkie łącze, ma tylko ciąg znaków z nazwą ścieżki. To są „miękkie” informacje. Technicznie „A” i „B” nie są ze sobą powiązane. Ale nadal B jest „linkiem” w nowym sensie, że można użyć zapisanej nazwy ścieżki jako skrótu do „A”. Teraz jest to „link do A” (kropka), a nie „ link do i -węzła pliku A”

Oba rodzaje linków mogą mylić nie tylko ludzi, ale także jądro / fs. Strona podręcznika użytkownika z 1971 r. Zauważa: „BŁĘDY: linki są dwukrotnie archiwizowane i odtwarzane jako osobne pliki z osobnymi i-węzłami”.

Twarde linki do katalogów (rzadkie / niedozwolone) mogą łatwo doprowadzić do zatkania.

Miękkie linki do katalogów (bardzo często) mogą prowadzić do wiecznych pętli - musi to być rozpoznane przez narzędzia / jądro.

Praktyczny przykład w bash

Począwszy od zwykłego pliku „F” ...

ln F Fhard

... sprawia, że ​​Fhard ma taki sam rozmiar jak F, ale ZARÓWNO pojawiają się teraz w kolorze ciemnoczerwonym BEZ strzałek w ls -l --color. Ze względu na statwyświetlanie „Links: 2” w połączeniu z „Inode: xyz”. Twarde linkowanie F powoduje, że sam F staje się twardym linkem. Oba są / pozostaną typem pliku „zwykły plik”. Ale oba mają i-węzeł z liczbą linków powyżej 1.

   ln -s F Fsoft

... tworzy mały „nieregularny” plik „Fsoft” z typem pliku „dowiązanie symboliczne” - nawet więcej miejsca niż pusty reż. A ls -lnie pokazuje nic specjalnego dla „F”. W przypadku Fsoft wyświetlany rozmiar to 1 bajt, ponieważ ciąg znaków to „F” i Fsoft -> Fjest wyświetlany jako nazwa. Nie trzeba pokolorować miękkiego linku, aby go rozpoznać. Ponieważ w krótkiej formie dołączany ls -Fjest zwinięty łańcuch @:Fsoft@

Z ls -lwygląda to tak:

-rw-r--r-- 2 root root 6070340 Sep 16 16:28 F
-rw-r--r-- 2 root root 6070340 Sep 16 16:28 Fhard
lrwxrwxrwx 1 root root       1 Sep 16 16:31 Fsoft -> F

Fhard ma rozmiar i typ F.

Fsoft ma nazwę F i długość nazwy F jako rozmiar i inny typ pliku.

Krótkie ls -sF:

5932 F    5932 Fhard     0 Fsoft@

dodanie --block-size=1nie daje również takich samych rozmiarów. Fsoft ma rozmiar „jeden bajt, zero bloków”. F i Fhard odchylają równolegle:

6074368 F  6074368 Fhard    0 Fsoft@

Aby sprawdzić, czy Fsoft zwisa, czy nie, lsmożesz użyć kolorów.

ORPHAN 40;31;01 # symlink to nonexistent file, or non-stat'able file

Naprawdę warto pamiętać, że nazwa linku jest opcjonalna. Jeśli nie jest podany, używana jest basename obiektu docelowego łącza.

ln -s /path/to/file1 file1

jest identyczny z całkowitym usunięciem nazwy linku:

ln -s /path/to/file1

Nie miałoby to sensu, gdyby cel linku był wymieniony jako ostatni.

Wystarczy pomyśleć o Unixie -> AT&T -> miejscu docelowym po prawej:

mov %eax, %ebx  ;; AT&T style assembler syntax: %ebx register gets value of %ecx

mv foo bar    ;; foo renamed to bar

cp foo bar    ;; contents of foo go to bar

foo | bar     ;; data moves left to right in pipeline

ln abc def    ;; link to abc installed as def

Osobiście wolę unikać zapamiętywania X, na rzecz wiedzy, gdzie szukać X, gdy jej potrzebuję. Jestem także fanem postawy „lepiej, niż przepraszam”, dlatego zawsze lubię uważnie sprawdzać, co piszę, zwłaszcza jako root.

W takim przypadku odpowiedź znajduje się dosłownie w pierwszych wierszach strony podręcznika:

   ln [OPTION]... [-T] TARGET LINK_NAME
   (...)
   In the 1st form, create a link to TARGET with the name LINK_NAME.

Nie zasugerowałbym tego, gdyby wymagało to zagłębienia się na stronie podręcznika, ale ponieważ jest to na samym początku, IMHO jest warte 3 sekund, które potrzeba na wpisanie man lni wyjście.

Podobnie do cp, który mentalnie czytam jako „skopiuj to do tego”, czytam polecenia ln jako „link do tego”.

Tak to pamiętam: zapomnij o celu. Innymi słowy, jeśli jestem w katalogu 1 i chcę utworzyć tutaj dowiązanie symboliczne do pliku 1, który istnieje w katalogu / some / other / dir /, po prostu zrobiłbym:

ln -s /some/other/dir/file1

Otrzymasz dowiązanie symboliczne o nazwie plik1 w katalogu 1, które wskazuje na / some / other / dir / file1. Ze strony podręcznika użytkownika dla ln:

ln [OPCJA] ... TARGET (2. formularz) ... W 2. formularzu utwórz łącze do TARGET w bieżącym katalogu.

Pamiętaj tylko, że działa to tylko wtedy, gdy chcesz, aby dowiązanie symboliczne miało taką samą nazwę jak cel (co najprawdopodobniej ma miejsce).

Chciałbym rozwinąć odpowiedź na @ gary.

Oprócz jego odpowiedzi: lnpolecenie może przyjmować dowolną liczbę argumentów, dzięki czemu można utworzyć wiele dowiązań symbolicznych w jednym wywołaniu (co jest przydatne, gdy jest to potrzebne).

1. Z tą wiedzą, kiedy napotkasz ln -s foo bar baz, jakie jest najbardziej logiczne wyjaśnienie, które argumenty oznaczają?
2. Kiedy znajdziesz odpowiedź na pytanie nr 1, ln -s foo barjakie jest najbardziej logiczne wyjaśnienie, które argumenty oznaczają?

Wyobraź sobie wersję, lnktóra pozwoliła na utworzenie wielu (symbolicznych) łączy w jednym poleceniu.

Synopsis: ln -s TARGET NEW_LINK...
Example: ln -s target_file  new_link_1  new_link_2  new_link_3

Odwróciłoby to wszystko, ponieważ dowiązanie symboliczne może wskazywać tylko jeden TARGETna raz, a normalna konwencja wiersza poleceń polega na umieszczaniu powtarzającej się części na końcu wiersza poleceń, np.grep PAT [FILE]...

„ lspokazuje a -> btak ln a b”

Pamiętaj tylko, że to źle.