Erstellen Sie in Bash einen Symlink mit zwei relativen Pfaden

2510
nettux443

Ich habe zwei Verzeichnisse in meinem Zuhause: ~/dir1und ~/dir2mit einer Datei im ersten: ~/dir1/file.txtGibt es eine Möglichkeit, aus der ich einen Symlink erstellen kann, ~/dir2ohne zu wechseln, ~/und wenn nicht, warum ist dies der Fall?

Ich habe es vom ~/Laufen aus versucht :

$ ln -s ./dir1/file.txt ./dir2/file.txt

Aber wie ich es erwartet hätte, zeigt der resultierende Symlink effektiv auf ~/dir1/dir2/file.txtdas, was sinnvoll ist, aber nicht das, was ich eigentlich will.

Ich habe auch versucht:

$ ln -s ./dir1/file.txt ../dir2/file.txt

Welche gibt zurück:

ln: failed to create symbolic link `../dir2/file.txt': No such file or directory

Ich würde erwarten, dass dies nur einen Symlink erstellt ~/dir2/file.txt, der auf zeigt~/../dir1/file.txt

Ich nehme an, meine eigentliche Frage lautet: Kann ich lneinen Symlink zu einer Datei erstellen, von der sie glaubt, dass sie nicht existiert?

Edit: Um noch mehr Klarheit darüber zu haben, was ich erreichen möchte, möchte ich einen einzigen Befehl, den ich von meinem Home-Verzeichnis aus ausführen kann.

pushd dir2/ && ln -s ../dir1/file.txt && popd

oder in Python (das ist das, was ich am nächsten habe, was ich will):

echo "import os; os.symlink('../dir1/file.txt', './dir2/file.txt')" | python
1

2 Antworten auf die Frage

2

Ihre Frage ist etwas verwirrend.

  1. Sie fragten: "Gibt es eine Möglichkeit, dass ich von ~/dir1[...] aus einen Symlink darauf setzen kann ?" Ich nehme an, Sie meinten "von ~/dir2", basierend auf dem Rest Ihres Beitrags?

  2. Dein erster Befehl

    $ ln -s ./dir1/file.txt ./dir2/file.txt

    tut nicht das, was Sie denken. Wenn Sie sich noch in Ihrem Heimatverzeichnis befinden, erstellt der obige Befehl einen Symlink, dessen eigener Pfad ist ~/dir2/file.txt, und dieser Symlink verweist buchstäblich auf den Pfad ./dir1/file.txt. Da sich der Symlink im Verzeichnis befindet ~/dir2, wird dieser Zielpfad in aufgelöst ~/dir2/./dir1/file.txt, was sich weiter auflöst ~/dir2/dir1/file.txt(wahrscheinlich nicht vorhanden und nicht das, was Sie möchten). Ich bezweifle also, warum Sie gesagt haben, dass sich das löst ~/dir1/dir2/file.txt.

  3. Ihr 2. Befehl schlägt fehl, da es kein Verzeichnis gibt, ../dir2in das der Symlink eingefügt werden kann. Dies bedeutet, dass die Fehlermeldung dies bedeutet.

  4. Um deine Frage zu beantworten, ja. Dem Betriebssystem ist es egal, ob Ihr Symlink auf einen Pfad verweist, für den kein gültiges Dateisystemobjekt vorhanden ist.

Wahrscheinlich ist das, was Sie wirklich wollen, etwas 

ln -s ../dir1/file.txt ./dir2/file.txt

Ich vermute? Dieser Befehl erstellt einen Symlink, dessen eigener Pfad ist ./dir2/file.txt, und sein Ziel ist der relative Literalpfad ../dir1/file.txt. Der letzte, absolute Pfad, auf den der Symlink verweist, ist der ~/dir2/../dir1/file.txt, der sich in auflöst ~/dir1/file.txt.

Beachten Sie, dass das ~Symbol ein durch die Shell erweiterbares Zeichen ist, das sich zum absoluten Pfad Ihres Home-Verzeichnisses erweitert. ~-Erweiterung ist nicht Teil der OS-Pfadauflösung.

Vorgeschlagene Literatur

Linux Manpages von path_resolution(7), symlink(7), ln(1)und ln(1p).

Bearbeiten

Klarstellungen und empfohlenes Lesen.

Ich verstehe, warum mein erster Befehl nicht funktioniert, dass ich nicht erwartet hätte zu arbeiten, aber ich dachte, ich würde es versuchen. Der zweite Befehl, den ich fühle, würde funktionieren, wenn ich ihn dazu zwingen könnte, die Verknüpfung herzustellen. Beachten Sie, dass die Argumente Ihres Befehls falsch sind. `` `ln -s / path / to / file / path / to / new / link```` Der Befehl, den Sie geschrieben haben, versucht einen Link` `` `~ / dir1 / file.txt`` zu erstellen `` zeigt auf `` `~ / dir2 / file.txt```` (rückwärts !!) :) nettux443 vor 10 Jahren 0
In meiner bearbeiteten Frage finden Sie ausführlichere Informationen dazu, was ich erreichen möchte. nettux443 vor 10 Jahren 0
1
terdon

Sie können entweder tun

  1. Verwenden Sie absolute Pfade

    $ ln -s ~/dir1/file.txt ~/dir2 $ readlink dir2/file.txt  /home/terdon/dir1/file.txt

  2. Verwenden Sie die richtigen relativen Pfade 

    $ ln -s ../dir1/file.txt dir2/ $ readlink dir2/file.txt  ../dir1/file.txt

Je nach Anwendungsfall ist einer möglicherweise besser als der andere. Denken Sie daran, dass beim Erstellen von Links mit relativen Pfaden die Pfade relativ zum Ziel und nicht zum aktuellen Standort sein müssen.

Danke für deine Antwort. Ihr erster Vorschlag funktioniert, wenn ich absolute Pfade hätte, aber ich interessiere mich speziell für relative Pfade. Ihr zweiter Vorschlag bezieht sich auch auf meinen zweiten versuchten Befehl (der Dateiname fehlt), aber ich habe einen Fehler gefunden, der nicht gefunden wurde (siehe oben). Kann ich fragen, welche Linux-Distribution Sie verwenden? nettux443 vor 10 Jahren 0
@ nettux443 huh, das ist seltsam. Ich bin bei LMDE (hauptsächlich Debian Testing) und bash `4.2.45`. Beachten Sie, dass mein zweiter Vorschlag _nicht_ das gleiche wie Ihr ist. Sie haben `. / Dir` verwendet und ich verwende` ../dir`. Die Idee ist, dass der Pfad relativ zum Ziel sein muss. Wenn Sie den Namen des Links angeben möchten, verwenden Sie `ln -s ../dir1/file.txt ~ / dir2 / foo`, das weiterhin funktioniert. Es funktioniert auch unabhängig davon, wo Sie sich befinden. Ich habe gerade das oben aus `/ etc` ausprobiert und es wurde korrekt eine Datei unter` ~ / dir2 / foo` erstellt, die auf `~ / dir1 / file.txt` zeigt. terdon vor 10 Jahren 0
@ nettux443 Nein, `ln` prüft nur, ob die erstellte Datei existiert. Es ist Ihre Aufgabe sicherzustellen, dass das Ziel wirklich ist. Dies gibt zum Beispiel keinen Fehler: `ln -s / fruble / bargle / bob / tmp / foo`, es wird glücklich und still ein defekter Link erstellt. terdon vor 10 Jahren 0
Entschuldigung, Sie haben Recht, meine zweite Antwort stimmt nicht mit Ihrem Vorschlag überein. Darin liegt das Problem. Dein Vorschlag ist das, was ich * meinte *, um es zu versuchen ... hoffentlich wird dieser Fehler nicht mehr gemacht! nettux443 vor 10 Jahren 0
@ nettux443 lol, passiert dem Besten von uns :) terdon vor 10 Jahren 0

Verwandte Probleme