Angenommen, ich habe einige Verzeichnisse:
/Users/user1/ApplicationThing/
/Users/user1/Documents/
/Users/user1/other/directory/it/doesnt/matter/
Angenommen, es gab eine Datei main.shin .../ApplicationThing/, die auch von einer anderen Datei abhängt dependancy.sh.
main.shIch möchte in der Lage sein, in jedem anderen Verzeichnis zu sein und mit WD als meinem CWD ausführen zu können , als ob sich das .../ApplicationThing/Inhaltsverzeichnis in jedem anderen Verzeichnis des Systems befände. Nicht wie bei $PATH, sondern als ob sich der Inhalt tatsächlich im Verzeichnis befände, aber nicht in Autovervollständigungen oder sogar auftauchen sollte ls -l.
Antwort1
Das klingt, als ob das ApplicationThing repariert werden sollte, um seine Abhängigkeiten von einem bestimmten Speicherort aus zu finden, selbst wenn es mit einem anderen Arbeitsverzeichnis aufgerufen wird.
Sie können dies tun, indem Sie eine Umgebungsvariable festlegen:
export ApplicationThingHome=/Users/user1/ApplicantionThing
und verweist auf alle Abhängigkeiten der main.shVerwendung des Wertes dieser Variable (mit optional einem guten Standardwert, wenn die Variable nicht gesetzt ist), zB
${ApplicationThingHome:-/usr/local/ApplicationThingDefaultDir}/dependancy.sh
anstatt
./dependancy.sh
Anschließend können Sie main.shdas Verzeichnis einfügen $PATHund es von jedem beliebigen Verzeichnis aus verwenden.
Ihre vorgeschlagene Lösung hätte ein Problem: Wenn Sie sich in einem anderen Verzeichnis befinden und dort eine Datei mit dem Namen main.shoder erstellen möchten dependency.sh, würden Sie stattdessen die entsprechenden Dateien von ApplicationThing überschreiben. Sie könnten buchstäblich keine andere Datei haben/verwenden main.shals die, die zu ApplicationThing gehört ... und Verzeichnisse wurden genau erfunden, um solche Probleme zu vermeiden!
Sie könnten natürlich die Bedingung stellen, dass die „Pseudodateien“ nur vorhanden sind, wenn main.shzuerst ausgeführt wird. Dann bräuchten Sie jedoch einen weiteren Satz an Tools, um zu sehen, was es main.shsieht, um Fehler zu beheben, wenn es nicht das erwartete Verhalten zeigt.
Wenn Sie ApplicationThing nicht reparieren können, können Sie ein Wrapper-Skript erstellen, um ApplicationThing von überall im System aufzurufen undDasSkript in einem Verzeichnis, das in Ihrem $PATH enthalten ist:
#!/bin/sh
# set the correct working directory for silly ApplicationThing
cd /Users/user1/ApplicationThing
# if ApplicationThing has any other environment requirements,
# this would be a great place to ensure they're satisfied too.
# Now execute the main.sh of ApplicationThing, giving it any
# command line arguments that were given to this script, exactly as-is.
exec ./main.sh "$@"
Da dieses Skript als separater Prozess ausgeführt wird, cdhat der Befehl im Skript keinerlei Auswirkungen auf die Sitzung, die das Skript aufruft. Das execSchlüsselwort beim Ausführen von main.shvermeidet, dass ein zusätzlicher Prozess zwischen der aufrufenden Shell und dem main.sh. verbleibt.
Bei diesem Ansatz main.shmüssen Sie, wenn Dateinamen als Parameter verwendet werden, diese als absolute Pfadnamen angeben, da alle relativen Pfadnamen als main.shrelativ zum Verzeichnis von ApplicationThing und nicht als relativ zum CWD der aufrufenden Sitzung interpretiert würden.
Wenn dies ein Problem darstellt, können Sie eine ausführlichere Vorverarbeitung für die Befehlszeilenparameter schreiben, bevor Sie sie übergeben main.sh.Diese StackExchange-Fragehat einige Ideen, die Sie vielleicht anwendbar finden.