Tipps zum Erinnern an die Reihenfolge der Parameter für ln?

Ich habe lnjahrelang symbolische Links geschrieben, aber die Reihenfolge der Parameter ist immer noch falsch.

Das bringt mich normalerweise zum Schreiben:

ln -s a b

und dann auf die Ausgabe schauen, um mich zu erinnern.

Ich stelle mir immer vor, a -> bwie ich es lese, wenn es eigentlich das Gegenteil ist b -> a. Das fühlt sich kontraintuitiv an und ich stelle fest, dass ich mich immer selbst nachdenke.

Hat jemand Tipps, die mir helfen, mich an die richtige Reihenfolge zu erinnern?

Ich benutze folgendes: lnHat ein Ein-Argument-Formular (2. Formular in der Manpage aufgeführt ), in dem nur das Ziel benötigt wird (wie könnte das überhaupt lnfunktionieren, ohne das Ziel zu kennen) und lnerstellt den Link im aktuellen Verzeichnis. Die Form mit zwei Argumenten ist eine Ergänzung zur Form mit einem Argument, daher ist das Ziel immer das erste Argument.

Ich gehe vorbei " lnist wie cp. Die" Quelle "muss zuerst kommen."

Die meisten Unices dokumentieren den lnBefehl als

ln source target

(Ich lasse hier Optionen usw. weg)

Beispiele:

• Der POSIX-Standard

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

• OpenBSD :

  ln [-fhLnPs] source [target]
  

• NetBSD und FreeBSD

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

• Mac OS

  ln [-Ffhinsv] source_file [target_file]
  

• Solaris

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

• AIX

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

Das GNU- lnHandbuch nennt das source Ziel und den target Linknamen .

• GNU Handbuch für ln

  ln [option]… [-T] target linkname
  

Das Ignorieren der GNU Wortwahl, die lnfolgt Dienstprogramm , um die gleiche Art von Semantik wie zB mvund cpdass in dem Ziel ist das, was aus der erzeugt wird Quelle .

Deshalb,

ln -s a b

würde den symbolischen Link erstellen, auf den bverwiesen wird a.

Beachten Sie auch, dass beim Erstellen von symbolischen Links die Quelle lediglich eine Zeichenfolge ist, auf die der symbolische Link zeigen soll. Es wird normalerweise keine Überprüfung durchgeführt, um zu bestätigen, dass es auf etwas Nützliches hinweist:

$ 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

Für den Fall, dass dies jemandem hilft: Ich habe mich daran gewöhnt, es als "ln what where " zu betrachten, was mir hilft, mich daran zu erinnern, dass das erste Argument ("what") die vorhandene Datei ist, das zweite ("where") der Ort es verlinken. Im Gegensatz zu den Überlegungen in den meisten anderen Antworten ist dies nichts anderes als ein markiger Satz, den ich mir mental vortragen kann, wenn ich einen Befehl eingebe, der als Erinnerungshilfe dient. Dies wird wahrscheinlich nicht für alle von Nutzen sein, aber ich vermute, dass es einigen Menschen helfen wird.

Es hilft, dass die anderen Standardbefehle zur Dateibearbeitung dieselbe Konvention verwenden, sodass ich das Gleiche für cpund tun kann mv.

Ich habe kürzlich eine großartige Möglichkeit gehört, mich an diese besondere Sache zu erinnern: einen Reim

Etwas Altes, etwas Neues,

etwas Geliehenes, etwas Blaues,

und ein Sixpence in ihrem Schuh.

Der erste Vers ist das, was die Argumente von ln sind: etwas Altes, gefolgt von einem Namen des neuen Verzeichniseintrags.

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; 

Ab 1971 Unix First Edition-Handbücher .

Es gibt eine zweite , einfache Syntaxform.

edit: Ich habe FILE oder die Dateinamen anstelle von TARGET --- siehe Kommentare usw. siehe auch sehr lange hinaus an der Unterseite, die Adressierung Eisberg, hart und weich von ln, nicht nur die Spitze davon.

Also hat GNU folgendes ln:

ln [opt] FILENAME

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

wo du den Linknamen nicht brauchst. Nachdem ln -s /usr/lib/modulesSie eine bekommen

modules -> /usr/lib/modules

mit dem gleichen Namen wie FILENAME ("Ziel" oder "Quelle"), genau dort, wo Sie sind. Keine Wahl, keine Verwirrung.

Wenn Sie anspruchsvoller sind und den Link unter einem anderen Namen und / oder an einem anderen Ort erstellen möchten , fügen Sie diesen Wunsch als Namen oder Pfad hinzu. Das eigentliche Ziel steht an erster Stelle, der neue Linkname an zweiter Stelle.

Oder Sie sagen: "Ich kenne diese Pfeilnotation ls -lfür Links. Ich habe keinen Pfeil in der Shell, der die Richtung meines Links anzeigt. Also muss ich ihn umdrehen."

Sie erstellen es in die eine Richtung, damit Sie es in der anderen verwenden können.

(ENDE DES ANTWORTEN-DER-FRAGE-TEILS)

Auf einer anderen Ebene hat das Wort "Verbindung" selbst eine tief verborgene doppelte Bedeutung. Symbolische Links kamen später, so dass ein Link in den Anfängen nur ein Link war. Es gab keine weichen und harten, keine -sOption. Und jetzt verwende ich sogar die Quell-Ziel-Symbolik:

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

Zu diesem Zeitpunkt gibt es Verknüpfungen, aber keine harten und weichen, und ls -les werden keine Pfeile angezeigt, da es in einer (harten) Verknüpfung keine Richtung gibt. Eine "Verknüpfung" in dieser Phase der Unix-Entwicklung bedeutete, dass der Dateiname "B" (Verzeichniseintrag "B") im Dateisystem auf denselben Inode verweist, auf den der Dateiname "A" verweist.

Die Dateien A und B sind miteinander "verknüpft", da sie dieselben Blöcke verwenden. Nun muss der Kernel bei jedem rm überprüfen: Lösche / befreie ich die Blöcke dieser Datei auf der Festplatte oder gibt es eine andere Datei, die mit denselben Blöcken verknüpft ist? Dafür wird ein Linkzähler verwendet.

Angenommen, Sie möchten eine große Datei auf / tmp grom behalten, die gelöscht werden soll, und tun dies ln /tmp/bigfile. Jetzt haben Sie eine große Bigfile in Ihrem Arbeitsverzeichnis. Nachdem Sie / tmp gesäubert und das "Original" entfernt haben, können Sie weiterhin dieselben Datenblöcke verwenden. Sie bekommen keinen toten oder baumelnden Link, Sie haben eine normale Datei. Der Verweis auf keine Datei, sondern nur das Dateisystem blockiert, wie es jeder Verzeichniseintrag tut. Erst jetzt ist "cleaning" / tmp nicht mehr so ​​effektiv wie es war. Es sieht leer aus und ist es auch, aber die Blöcke auf der Partition werden nicht freigegeben.

Auch wenn eine harte Verbindung nicht wie cp indirekt Speicherplatz kostet, kann sie dies.

Hinzufügen ln -szu der obigen Sequenz:

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

Jetzt hat "B", der Softlink, nur eine Zeichenfolge mit einem Pfadnamen. Das ist "soft" info. Technisch gesehen sind "A" und "B" nicht miteinander verbunden. Dennoch ist B ein "Link" in dem neuen Sinne, dass Sie diesen gespeicherten Pfadnamen als Verknüpfung zu "A" verwenden können. Jetzt ist es "eine Verknüpfung zu A" (Punkt) und nicht "verknüpft mit der Inode von Datei A".

Beide Arten von Links können nicht nur Menschen verwirren, sondern auch den Kernel / fs. In der Manpage von 1971 heißt es: "BUGS: Links werden zweimal gesichert und als separate Dateien mit separaten Inodes wiederhergestellt."

Harte Links zu Verzeichnissen (selten / nicht erlaubt) können leicht zu einem Verstopfen führen.

Softlinks zu Verzeichnissen (sehr häufig) können zu ewigen Schleifen führen - müssen von Utilities / Kernel erkannt werden.

Praktisches Beispiel in Bash

Beginnend mit einer regulären Datei "F" ...

ln F Fhard

... macht Fhard genauso groß wie F, aber beide erscheinen jetzt in einem dunklen Rot OHNE Pfeile ls -l --color. Wegen der statAnzeige von "Links: 2" in Verbindung mit "Inode: xyz". Feste Verknüpfung F macht F selbst zu einer festen Verknüpfung. Beide sind / stay Dateityp "reguläre Datei". Beide haben jedoch eine Inode mit einer Linkanzahl über 1.

   ln -s F Fsoft

... erstellt eine winzige "unregelmäßige" Datei "Fsoft" mit dem Dateityp "symbolischer Link" - noch platzsparender als ein leeres Verzeichnis. A ls -lzeigt nichts spezielles für "F". Für Fsoft beträgt die angezeigte Größe 1 Byte, da die Zeichenfolge 'F' ist und Fsoft -> Fals Name angezeigt wird. Es ist nicht erforderlich, einen Softlink einzufärben, um einen zu erkennen. Weil in der Kurzform ls -Feine aufgerollte Kette @ angehängt wird:Fsoft@

Damit ls -lsieht es so aus:

-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 hat Fs Größe und Typ.

Fsoft hat den Namen von F und die Länge von F als Größe und einen anderen Dateityp.

Kurz ls -sF:

5932 F    5932 Fhard     0 Fsoft@

das Hinzufügen --block-size=1ergibt auch nicht die gleichen Größen. Fsoft hat die Größe "ein Byte, null Blöcke". F und Fhard weichen parallel ab:

6074368 F  6074368 Fhard    0 Fsoft@

Um zu sehen, ob Fsoft baumelt oder nicht, lskönnen Sie Farben verwenden.

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

Es ist sehr hilfreich, sich daran zu erinnern, dass der Name des Links optional ist. Wenn es nicht angegeben wird, wird der Basisname des Verbindungsziels verwendet.

ln -s /path/to/file1 file1

ist identisch mit dem vollständigen Löschen des Linknamens:

ln -s /path/to/file1

Dies würde keinen Sinn ergeben, wenn das Linkziel zuletzt genannt würde.

Denken Sie nur an Unix -> AT & T -> Ziel auf der rechten Seite:

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

Persönlich bevorzuge ich es, mich nicht an X zu erinnern , um zu wissen, wo ich nach X suchen soll, wenn ich es brauche. Ich bin auch ein Fan der "Better Safe than Sorry" -Einstellung, daher schaue ich immer gerne genau nach, was ich schreibe, insbesondere als Root.

In diesem Fall steht die Antwort buchstäblich in den ersten Zeilen der Manpage:

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

Ich hätte es nicht vorgeschlagen, wenn es erforderlich wäre, in der Manpage nachzulesen, aber da es direkt am Anfang ist, lohnt es sich meiner Meinung nach die 3 Sekunden, die es braucht, um zu tippen man lnund zu beenden.

Ähnlich wie bei cp, das ich mental als „kopiere dies nach dem anderen“ las, las ich in Befehlen als „verbinde dies nach dem anderen“.

So erinnere ich mich daran: Vergiss das Ziel. Mit anderen Worten, wenn ich in dir1 bin und hier einen Symlink zu file1 erstellen möchte, der in / some / other / dir / vorhanden ist, würde ich einfach Folgendes tun:

ln -s /some/other/dir/file1

In dir1 wird ein Symlink mit dem Namen file1 angezeigt, der auf / some / other / dir / file1 verweist. Aus der Manpage für ln:

In [OPTION] ... TARGET (2. Formular) ... erstellen Sie im 2. Formular einen Link zu TARGET im aktuellen Verzeichnis.

Beachten Sie jedoch, dass dies nur funktioniert, wenn der Symlink denselben Namen wie das Ziel haben soll (was höchstwahrscheinlich der Fall ist).

Ich würde gerne die Antwort von @ gary erläutern.

Zusätzlich zu seiner Antwort: Der lnBefehl kann eine beliebige Anzahl von Argumenten akzeptieren, so dass Sie mehrere Symlinks in einem Aufruf erstellen können (was praktisch ist, wenn Sie es benötigen).

1. Wenn Sie auf dieses Wissen stoßen ln -s foo bar baz, was ist die logischste Erklärung, welche Argumente bedeuten was?
2. ln -s foo barWas ist bei der Antwort auf # 1 die logischste Erklärung, welche Argumente bedeuten was?

Stellen Sie sich eine Version vor, mit lnder Sie mehrere (symbolische) Links in einem Befehl erstellen können.

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

Es würde keinen Sinn machen, dies umzukehren, da ein Symlink immer nur auf einen Punkt TARGETgleichzeitig zeigen kann und die normale Befehlszeilen-Konvention darin besteht, den sich wiederholenden Teil am Ende der Befehlszeile einzufügen, zgrep PAT [FILE]...

" lszeigt a -> bso ln a b"

Denken Sie daran, dass dies falsch ist.