Diese Seite ist der Entwurf für eine Beschreibung, die letzendlich in die Knowledge-Base wandern soll. Solange sie hier lagert, ist sie bei weitem noch nicht fertig!

/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

Es ist klar, daß beide Anforderungen früher oder später in Timeouts laufen würden; aber wem der Chef schon mal während der Fehlersuche in den Nacken geatmet hat, weiß, wie lange diese Zeiten sein können …

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.

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).

wüste Konstruktion

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.

Anfang der Seite


Disclaimer:

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