Diskussion:Ln (Unix)

Die Löschung der Seite „Ln (Unix)“ wurde ab dem 5. Dezember 2008 diskutiert und abgelehnt. Für einen erneuten Löschantrag müssen gemäVorlage:SS den Löschregeln neue Argumente vorgebracht werden.

Anzahl der Argumente

ln muss immer mit mindestens zwei Argumenten aufgerufen werden? Wenn ich unter Linux oder Darwin in einem Verzeichnis ln /pfad/zu/datei eingebe, habe ich hinter im aktuellen Arbeitsverzeichnis datei als Link auf /pfad/zu/datei liegen. --Robb der Physiker 11:33, 29. Sep. 2008 (CEST)

Hallo Robb,

du hast völlig Recht, der Artikel ist falsch. --Benji 19:57, 4. Okt. 2008 (CEST)

Ich habe es korrigiert. --Robb der Physiker 11:12, 5. Okt. 2008 (CEST)

Eselsbrücke

Ich habe festgestellt, dass die Syntax von ln weniger selbstverständlich ist als die von cp oder mv. Wer naiv darangeht, denkt, er könne mit ln <link-Datei> <Ursprungs-Datei> einen Link auf die Ursprungs-Datei setzen, was natürlich falsch ist. Es muss umgekehrt sein, was klar wird, wenn man jeweils daran denkt, dass die Reihenfolge stets alteDatei neueDatei ist, genau wie bei cp und mv. Ich denke, diese Eselsbrücke hilft, vor allem Link-Neulingen. Wenn Ihr das auch denkt, werde ich das in ein paar Worte fassen. --Pleoni 13:26, 15. Okt. 2008 (CEST)

Hallo Pleoni,

gute Idee. Ich hab den Artikel mal etwas überarbeitet bzw. umstrukturiert und denke, dass er jetzt den Anforderungen eher gerecht wird, denn letztlich sind die Argumente ja exakt wie bei mv/cp, nur der Ein-Argumenten-Syntax stellt die Besonderheit dar. --Benji 19:09, 15. Okt. 2008 (CEST)

Die Besonderheit von ln gegenüber anderen Befehlen wie cp, mv, ... kommt meiner Meinung nach immer noch nicht hervor. Zieldatei meint bei allen Befehlen (ln,cp,mv) den neu zu erzeugenden Knoten. Bei ln denkt man bei "Ziel" aber schnell an den Knoten, auf den man nach erzeugen des neuen Knoten zeigen möchte -- das erwünschte Ergebnis steht also dem Verständnis im Weg. Beim Schreiben diese Absatzes, kommt mir meine eigene Erläuterung mißverständlich vor; das lasse ich aber mal "veranschaulichend" für die Verwirrung stehen, denen Anfängern ausgeliefert sind. Diese Verwirrung kommt eigentlich nur bei "-s" zu Tage, aber symbolische Links sind fast immer die von Anfängern erwünschten Links. Mir hilft die Vorstellung, dass ein symbolischer Links nicht weiter als eine einzeilige Textdatei ist, die einen besonderen Typ hat. So erzeugt im Prinzip der Befehl "ln -s 'sinnloser und beliebiger Text' mylink" einen Knoten mylink mit dem Inhalt "sinnloser und beliebiger Text\0" und dem speziellen Typ "l". D.h. strenggenommen hat der erste Parameter erstmal nichts mit Objekten auf dem Dateisystem zu tun, sondern erst im nachhinein als ein Verweis interpretiert. Zur veranschaulichung mal fogendes Beispiel: Gegeben sind zwei Verzeichnisse "Holger" und "Elfriede". In "Holger" liegen die Dateien "Bello" und "Mieze". Der Befehl ( cd Holger; for file in Bello Mieze; do ln -s $file ../Elfriede/; done ). Dieser Befehl erzeugt Unsinn, nämlich: In Elfriede liegen die symb. Links Bello -> Bello und Mieze -> Mieze, was für Anfänger nicht verständlich ist. --92.76.103.147 21:21, 11. Nov. 2008 (CET)

Hallo,

Du bringst jetzt den Begriff des (Ziel)knotens ins Spiel – eine Eindeutschung für Inode?

Fassen wir mal ein bisschen zusammen:

Zunächst definiere ich meine Notation:

  X(y) := sei definiert als der Dateiname X, der auf den Inode (Datenblock) y zeigt.
  X(*) := Ein Dateiname X, der kein Link auf einen Inode repräsentiert, sondern ein Verzeichnis.
W/X(y) := Eine Datei namens X im Verzeichnis W, auf den Inode y zeigend.
  _( ) := eine nicht existierender Dateiname (Platzhalter)

mv, cp und ln verhalten sich nun wie folgt:

Kommando   | Vorher         |  Nachher
-----------+----------------+-------------
mv A B     |  A(y)   _( )   | _( )   B(y)
cp A B     |  A(y)   _( )   | A(y)   B(z) mit z als Kopie von y
ln A B     |  A(y)   _( )   | A(y)   B(y)

soweit ist alles klar und der Syntax doch durchaus einleuchtend: Drei Befehle mit drei grundlegend verschiedenen Ergebnissen. Vielleicht könnte ich ja bei Zeiten mal ein Bildchen zeichnen, was genau das visualisiert, wenn du mit soetwas im Artikel gerne Klarheit schaffen möchtest. Mit mehreren Parametern wandelt sich das Bild so:

Kommando   | Vorher                |  Nachher
-----------+-----------------------+-------------
mv A B C D | A(w) B(x) C(y) D(*)   | _( ) _( ) _( ) D(*) und D/A(w), D/B(x), D/C(y)
cp A B C D | A(w) B(x) C(y) D(*)   | A(w) B(x) C(y) D(*) und D/A(k), D/B(l), D/C(m)
           |                       |                     mit k,l,m als Kopien von w,x,y
ln A B C D | A(w) B(x) C(y) D(*)   | A(w) B(x) C(y) D(*) und D/A(w), D/B(x), D/C(y)

Analog zur obigen Tabelle sieht man, dass die Verwendung absolut identisch abläuft, d.h. die (mv A B) verhält sich zu (ln A B) wie (mv A B C D) sich zu (ln A B C D) verhält. Zusatzparameter wie -r bei mv/cp oder -s bei ln ändern an dem Grundschema nichts: Rekursion oder "Weichheit" sind nur Zusatzattribute. Anders ist es z.B. bei der GNU-Erweiterung --target-directory=D, welches das ganze Schema über den Kopf wirft. Diese seien daher außer Acht gelassen.

Ich denke, dass das das war, was Leonie ausdrücken wollte.

Die Verwirrungen, die entstehen, sind doch letzlich auf die ungünstige Nomenklatur für A und B zurückzuführen. Ich zitiere aus den Manpages (lokalisiert):

       | Namen für A       | Namen für B
       | (Original)        | (engl. Original)
-------+-------------------+--------------
mv     | Quelle  (source)  | Ziel  (target)
cp     | Quelle  (file)    | Ziel  (path)
ln     | Ziel    (source)  | Verknüpfungsname (destination)

Da kann ja gar keiner durchblicken: Keine einheitliche Übersetzung bzw. verdrehte Übersetzung. Generell ist es ein Spiel mit der Ziel-Metapher, wie du (IP) schon sagst. So stellt ein Hyperlink ja auch die Quelle zu einem Ziel (URL) dar – warum ist es beim (Soft/hard-)link dann andersrum?

Vielleicht würde ein einfaches, aber ins Auge springendes Bild diese Fragen echt ein für alle mal klären. --Benji 00:39, 12. Nov. 2008 (CET)

Ich oute mich erstmal als "die IP" oben, bin ein Neuzugang hier. Deine Auseinandersetzung mit diesem Thema hat mich beeindruckt und ich habe zunächst gedacht, dass die Sache mit den Inodes (Ja, die meinte ich mit Knoten.) zu komplex für diesen Artikel wäre. Aber ich glaube, dass es für das Verständnis der Sache durchaus notwendig ist. Meiner Meinung nach hat der Befehl ln eine besondere semantische "Tiefe", die eben mit der Natur der Inodes zusammenhängt. Ich finde es zumindest immer schade, wenn symbolische Links mit dem Vorteil gegenüber harten Links dargestellt werden, dass man mit ihnen auch auf Verzeichnisse verweisen könne. In solch verkürzter Darstellung gerät ein harter Link zu einem historischen Überbleibsel und der symbolische rückt in die Nähe der, im Vergleich lächerlichen, .lnk-Dateien unter Windows.

Die seltsame Nomenklatur der Gnu-Manpages ist in der Tat irreführend. --Karlos77 18:59, 23. Nov. 2008 (CET)

Ich habe mich mal an einem Textbaustein versucht. Dieser hat allerdings diverse Macken:

Links, Dateien und Verzeichnisse

Objekte (Dateien, Verzeichnisse) in einem UNIX-Dateisystem bestehen grundsätzlich aus zwei Komponenten: Einem Knoten (Inode) und einem Link. Ein Knoten repräsentiert, vereinfacht dargestellt, die Meta- und Nutzdaten des Datenobjektes selbst. Dieser Knoten ist in mindestens einem Verzeichnis verlinkt. Mit dem Befehl ln wird ein neuer Link in einem Verzeichnis auf einen Knoten erzeugt. Das bedeutet, dass die selbe "Datei" mehrere gleichrangige Repräsentationen im Dateisystem besitzen. Erst wenn sämtliche dieser Repräsentationen im Dateisystem gelöscht wurden, wird der eigentliche Knoten freigegeben, d. h. endgültig gelöscht. Das Erzeugen und Zerstören eines Links im Dateisystem ist also ein grundlegender Vorgang zum Erzeugen und Zerstören von Dateien überhaupt und daher heißen die entsprechenden C-Lib-Funktionen link() und unlink(). Mit dem Befehl ln können zwar keine neuen Dateien erzeugt werden, aber es übernimmt den Spezialfall, zu einem bestehenden Dateiobjektes zusätzliche, gleichberechtigte Verzeichniseinträge zu erzeugen.

Symbolische Links, auch Softlinks genannt, die mit dem Schalter "-s" erzeugt werden, unterscheiden sich technisch grundlegend von Hardlinks. Hier wird nicht ein Link im Sinne eines Verzeichniseintrages auf einen bestehenden Inode erzeugt. Stattdessen wird ein eigenständiger Inode eines besonderen Typs "l" erzeugt und analog verzeichnet. Inhalt dieses Inodes ist ein symbolischer Verweis auf einen Verzeichniseintrag.

Zusamenfassend kann man sagen, dass ein Hardlink ein Verweis auf einen Inode ist und ein Softlink ist ein Verweis auf einen Verzeichniseintrag mit Hilfe eines l-Inodes. --Karlos77 19:36, 23. Nov. 2008 (CET)

Hola Karlos,

erst einmal volle Zustimmung zu dem oben Gesagtem. Ich finde deinen Textvorschlag für den Artikel sehr gut. Der Absatz sollte (aber) auch Bezug nehmen auf bereits existierende Artikel um diesen Themenkreis, und zwar Inode, Symbolische Verknüpfung und Harter Link. Es sollten also einerseits Redundanzen zugunsten dem Hinweis auf jene Artikel verwiesen werden, andererseits muss aber weit genug ausgeholt werden, um den Sachverhalt für Laien auch auf den ersten Blick verständlich zu machen. Ein schwieriger Spagat – mit deinem Text ist ein erster Schritt in die richtige Richtung gegangen worden.

Vielleicht könnten wir uns ja mal vornehmen, dieses Gefüge zu entzerren. Während Inode quasi über eine knappe komplexe technische Vorstellung der Datenstruktur nicht hinausgeht, treffen den Leser auf Symbolische Verknüpfung regelrechte Textmassen, kaum verlinkt und vor allem unbebildert, an. So ähnlich sieht es mit Harter Link aus: Jeder Artikel fängt irgendwie bei Adam und Eva an. Dummerweise hab ich in letzter Zeit auch recht wenig Zeit, um mich ausgiebig den Artikeln zu widmen oder Bildchen zu zeichnen. -Benji 23:59, 23. Nov. 2008 (CET)