/client/scripts und dortige Skripte
Die Ursprünge dieser Skripte gehen bis in meine Vor-Rechenzentrums-Zeit (in der Informatik) zurück.
Im Rechenzentrum angekommen habe ich sie dann den hiesigen Bedürfnissen angepasst. Zu Beginn war jeder Rechner “sein eigenes Blech”; damals gab es noch keine virtuellen Maschinen. Außerdem standen an den Außenstandorten Rechner mit denen Konnektivität überwacht und Funktionalitäten überprüft werden konnten. Zudem stand damit vor Ort jeweils ein Rechner für eine eventuell notwendige Fehlersuche zu Verfügung.
Letzteres führt zwangsläufig zu der Forderung, daß jeder dieser Rechner vollkommen autark laufen muß. Das bedeutet
Da von einem anderen Projekt (“SW-Baum”, inzwischen ausgestorben)
die Kataloge /local und /client schon vorhanden waren,
wurden die Skripte unterhalb von /client/scripts abgelegt.
(In der Zwischenweit sind /local und /client jweils
symbolische Links auf denselben realen Pfad.)
Irgendwann wurde mir nach der Rückkehr aus dem Urlaub erklärt,
daß es auf den Systemer-Rechner die Pfade /local und
/client nicht mehr gäbe. Punkt!
Also wurden auf diesen Rechnern die Skripte nach
~gskalla/client/scripts verlagert und eine (m. E. ziemlich)
wüste Konstruktion eingebaut.
Diese liefert in ${GSK_TOPDIR} den scripts-Katalog
zurück, in dem sich seinerseits Unterkataloge wie bin,
lib, etc und andere befinden.
bin
enthält (hoffentlich nützliche) Programme,
die im täglichen Gebrauch aufgerufen werden können sollen.
Dazu wird auf den Netzer-Rechnern dieser Katalog standardmäßig
in den Suchpfad mit aufgenommen.
etc
enthält Programme, die nicht über den Suchpfad aufrufbar
sein sollen.
lib
enthält Shell-Funktionen, awk-Programme, perl-Module usw.,
die von den Skripten der obigen Kataloge verwendet werden.
Die (interessanten Teile der) Skripte werden unter den obigen Katalogen
angerissen. Die zentralsten darunter sind
etc/transfer,
etc/every.hour, etc/every.night
und etc/periodical
(siehe jeweils dort).
Da sich der scripts-Unterbaum auf verschiedenen Rechnern an
verschiedenen Stellen im Dateibaum wiederfindet, muß aus
dem voll qualifizierten Pfad des aufgerufenen Programms diese Stelle
extrahiert werden um Shell-Funktionen u. ä. aus .../scripts/lib
nachladen zu können.
Dieses Konstrukt muß — leider!! — in jedem Skript stehen:
| 1: | SED_SCRIPT=':start | |||
| 2: | s@^\./@'"‘pwd‘"'/@ | |||
| 3: | h;s@/[^/][^/]*$@@;t decide | |||
| 4: | b end | |||
| 5: | :decide | |||
| 6: | x;/\/bin$/b break | |||
| 7: | /\/etc$/b break | |||
| 8: | /\/lib$/b break | |||
| 9: | /\/cisco$/b break | |||
| 10: | x;b start | |||
| 11: | :break | |||
| 12: | x;:end | |||
| 13: | s@^$@/@;p' | |||
| 14: | ||||
| 15: | : ${GSK_TOPDIR:=‘echo $0 | sed -n "$SED_SCRIPT"‘} |
Alternativ hätten die Skripte auf den Netzer- und Mail-Rechnern
getrennt gepflegt werden können; dann hätte obige
Konstruktion entfallen und ${GSK_TOPDIR} direkt auf den
“richtigen” Pfad gesetzt werden können.
Klingt einfacher, allerdings um den Preis, daß dann
alle Änderungen und Erweiterungen an zwei Stellen
eingepflegt werden müsssten.
Oder man sorgt dafür, daß die Skripte auf allen beteiligten
Rechnern unter demselben Pfad zu erreichen sind. Das wäre
inzwischen sogar wieder denkbar.
Die auf diesen Seiten zum Ausdruck gebrachten Meinungen sind die meinigen, nicht notwendigerweise die der Universität Osnabrück. (Es sei denn, sie würden zufällig übereinstimmen oder wären entsprechend gekennzeichnet.)
Zum Thema "Links":
Bei "Links" handelt es sich stets um "lebende" (dynamische) Verweisungen. Gernot Skalla hat bei der erstmaligen Verknüpfung zwar den fremden Inhalt daraufhin überprüft, ob durch ihn eine mögliche zivilrechtliche oder strafrechtliche Verantwortlichkeit ausgelöst wird. Er überprüft aber die Inhalte, auf die er in seinem Angebot verweist, nicht ständig auf Veränderungen, die eine Verantwortlichkeit neu begründen könnten. Wenn er feststellt oder von anderen darauf hingewiesen wird, daß ein konkretes Angebot, zu dem er einen Link bereitgestellt hat, eine zivil- oder strafrechtliche Verantwortlichkeit auslöst, wird er den Verweis auf dieses Angebot aufheben.
(Quelle: Impressum/Disclaimer des Berliner Beauftragten für Datenschutz und Informationsfreiheit Stand: 09/2002)
Last change: Mon Dec 18 21:47:48 CET 2023