Interne News

Bash-Script: mil.sh (Mila – v1) veröffentlicht

Aus einem sehr kleinen Bash-Script wurde ein Monster namens Mila. Die Rede ist von einem Bash-Script für das automatische Kopieren, Verarbeiten und Importieren von Logdateien für Matomo, welches heute in Version 1 veröffentlicht wurde.

Inhaltsverzeichnis:

1. [EN] Foreword
2. [DE] Vorwort
3. Bash-Script-Metadaten
4. Bash-Script-Übersicht (Abschnitte p0 bis pb)
5. Mila's Entstehung
6. Mila's Rattenschwanz
7. Arbeiten an diesem Bash-Script

[DE] Vorwort:

Diese interne News ist auf Deutsch verfasst. Angaben betreffend Titel, Copyright, Lizenz, Metadaten, Changelog und einer Übersicht über den Inhalt des Bash-Scripts sind im Abschnitt p0 im entsprechenden Bash-Script sowie in den nachfolgenden Abschnitten "Bash-Script-Metadaten" und "Bash-Script-Übersicht (Abschnitte p0 bis pb)" in dieser internen News ersichtlich. Der restliche Teil dieser internen News enthält lediglich Hintergrundinformationen über die Entstehung dieses Bash-Scripts. Das Bash-Script "mil.sh" selber kann im Abschnitt Bash-Scripts auf der Downloads-Seite in Version 1 seit heute kostenlos heruntergeladen werden. Aktualisierungen dieses Bash-Scripts werden in internen News, deren Titel stets mit "Bash-Script" beginnen, angekündigt. Alle internen News können hier als RSS-Feed abonniert werden.

Bash-Script-Metadaten:

• Dateiname: mil.sh
• Bash-Script-Codename: Mila
• [DE] Titel: Automatisches Kopieren, Verarbeiten und Importieren von Logdateien für Matomo
• [EN] Title: Automatic Copying, Processing and Importing Logfiles for Matomo
  
  
• Autor: Daniel Mayr (alias Dr. Sooom)
• Website des Autors: https://danielmayr.at/
• Erstelldatum: 2023-09-02 08:16 (UTC+2)
• Erstveröffentlichung: 2024-02-01 01:30 (UTC+1)
• Letztes Update: 2024-02-01 01:20 (UTC+1)
• Lizenz: © 2023-2024 Daniel Mayr (alias Dr. Sooom), GPLv3
• Lizenz-URL: https://www.gnu.org/licenses/gpl-3.0.html
  
  
• Benötigte Datei: "import_logs.py" aus Matomo (>= 4.0.0)
• Benötigte Pakete: openssh (>= 7.9p1), python3 (>= 3.5)
• Optionales Paket: 7zip (>= 21.06)
• Veraltete, optionale Pakete: p7zip-full (16.02), p7zip (16.02)
• Dateien, die gelöscht werden:
  • *.gz, *.log, {curr_date}.mclog, *.pylog
• Dateien, die erstellt und behalten werden:
  • {matomo_lila_file}.mclog, {date_range}|{curr_date}.7z|.tar.xz

Bash-Script-Übersicht (Abschnitte p0 bis pb):

• 0. Angaben betreffend Titel, Copyright, Lizenz, Metadaten, Changelog und dieser Übersicht hier.
• 1. Durchführung etlicher Teil-Aufgaben (ausgenommen Logdatei-Import in Matomo) ein- bzw. ausschalten.
  Matomo-Auth-Token, -Website-ID, -URL und -Pfad festlegen.
  SSH-/SCP-Benutzername, -Server und Pfad nebst Dateinamens-Präfix zu den Logdateien festlegen.
  Pfad nebst Dateinamens-Präfix zu den Logdateien für den lokalen Kopiervorgang festlegen.
  Aufteilungs-Punkte und Zeitstempel für die Logdatei-Sortierung-/Löschung festlegen.
  Anonymisierungsgrad bei IPv4- und IPv6-Adressen und Ersetzungszahl hierfür festlegen.
  Durchführungs-Variable für die SCP-/SSH-Sitzung und p1-Prüfungs-Variable festlegen.
• 2. Prüft, ob Variablen im Abschnitt p1 angepasst wurden.
  Prüft, ob 7-Zip (7zz/7z/7za/7zr), tar, xz (xz-utils), grep und sed vorhanden sind.
  Prüft, ob OpenSSH (scp und ssh), Python3 und die Datei "import_logs.py" vorhanden sind.
  
  
• 3. Alle Logdateien (inkl. GZ-Archive) vom Webserver via SCP herunterladen.
  Alle Logdateien (inkl. GZ-Archive) aus einem anderen Verzeichnis hierher kopieren.
  Allerdings nur, wenn keine im aktuellen Verzeichnis vorhanden sind.
• 4. Alle GZ-Archive entpacken und gleich daraufhin wieder löschen.
  Logdateien mit mehr als 50.000 Einträgen aufteilen.
  Logdateien, die definitiv schon in Matomo importiert wurden, löschen.
  Wenn jenes Datum nicht verfügbar, so werden keine Logdateien gelöscht.
  Die Logdateien mit "1.log", "2.log" usw. chronologisch sortieren bzw. umbenennen.
• 5. Die Buchstaben "X" und "x" in IPv4- und IPv6-Adressen während der Anonymisierung durch Ersetzungszahl ersetzen.
  Die letzten beiden Oktette (16 Bits) aller IPv4-Adressen in allen Logdateien anonymisieren.
  Die letzten sechs Blöcke (96 Bits) aller IPv6-Adressen in allen Logdateien anonymisieren.
  IPv6-Adressen mit IPv4-Notation für die letzten beiden Blöcke werden ebenfalls anonymisiert.
  Verkürzte Notationen von IPv6-Adressen (z.B. ::1) werden hingegen nicht anonymisiert.
  
  
• 6. Alle Logdateien im aktuellen Verzeichnis in Matomo importieren.
  Die Terminal-Ausgaben des Python-Scripts werden in Python-Logdateien (*.pylog) geschrieben.
  Die Anzahl der importierten Einträge und die Import-Dauer werden im Terminal ausgegeben.
  Der Zeitstempel des zuletzt importierten Log-Eintrags wird in die andere Matomo-Logdatei geschrieben, sofern auslesbar.
• 7. Eine Matomo-Archivierung wird lokal oder via SSH durchgeführt.
  Fragt, ob hierfür eine SSH-Sitzung zum Webserver gestartet werden soll.
• +9 Dieselbe Frage wird ebenfalls gestellt, wenn keine Logdateien vorhanden sind.
  Die Terminal-Ausgaben der Matomo-Archivierung werden in einer Matomo-Logdatei ({heutiges Datum}.mclog) geschrieben.
  Die Anzahl der API-Aufrufe sowie der Fehler und die Archivierungs-Dauer werden im Terminal ausgegeben.
  Das "zuletzt geändert"-Datum jener Matomo-Logdatei wird in die andere Matomo-Logdatei geschrieben.
  
  
• 8. Alle Log-, Python-Log- und Matomo-Logdateien werden in ein 7z-Archiv gepackt.
  Der Dateiname des 7z-Archivs besteht aus dem Start- und Enddatum der importierten Logdateien, sofern auslesbar.
• +a Wenn keine Logdateien vorhanden, besteht der Dateiname des 7z-Archivs aus dem heutigem Datum.
  Wenn die Pakete 7zip/p7zip-full/p7zip nicht installiert sind, so wird ein TAR-XZ-Archiv erstellt.
  Danach werden alle Log-, Python-Log- und Matomo-Logdateien gelöscht.
  Hiervon ausgenommen ist die andere Matomo-Logdatei mit den beiden Zeitstempeln.
• b. Abschluss-Nachricht nebst Gesamtdauer des Bash-Scripts ausgeben.

Mila's Entstehung:

Meine allerersten Arbeiten an Bash-Scripts überhaupt begannen am Mittwoch, dem 26. Juli 2023, da mir die stets repetitiven Arbeitsabläufe betreffend dem zusammenführen mehrseitiger Scans, die zuvor ebenfalls manuell durch Tesseract OCR gejagt werden mussten, ziemlich auf den Senkel gingen, zumal dies auch noch anstrengend und viel Konzentration von mir abverlangte. So entstand damals das Bash-Script, welches mittlerweile den Codename "Oscar" trägt. Aber um Oscar geht's heute nicht, sondern um Mila, welches am Samstag, dem 2. September 2023, das Licht der Welt erblickte. Denn auch der ursprüngliche Grund für dessen Entstehung ist exakt derselbe wie bei Oscar: periodisch wiederkehrende, repetitive Arbeitsabläufe. Diesmal jedoch dreht sich alles um das Herunterladen von Apache-Access-Logdateien, das lokale Verarbeiten jener und anschließend das Importieren jener in Matomo.

Zu Beginn schrieb ich allerdings nur ein sehr kleines Bash-Script (1,63 KB), welches in allen Logdateien (*.log) die Zeichenfolge ".X.X - " durch ".0.0 - " ersetzt, sodass die Länder-Erkennung anhand der anonymisierten IPv4-Adressen korrekt in Matomo funktionieren konnte. Dass ich diese Apache-Access-Logdateien nicht per Cronjob täglich automatisch in Matomo importieren lasse – wie bereits hier und hier berichtet –, liegt übrigens auch daran, dass deren Dateinamen täglich irgendwann zwischen 01:00 und 03:00 Uhr unbenannt und rund alle fünf Tage darüber hinaus noch in ein GZ-Archiv gepackt werden. Nichts, was sich mit einem einfachen Cronjob automatisieren ließe. Zumindest musste ich diese Zeichenersetzungen seit her nicht mehr händisch in Notepad++ machen, was mich schon ziemlich genervt hatte, da anstrengend.

Als ich am Freitag, dem 3. November 2023, jene Logdateien in Matomo abermals importieren wollte, wobei dieser Vorgang stets auf demselben Webserver, auf dem auch Matomo installiert ist, angestoßen wurde, funktionierte es auf einmal nicht mehr. Am Sonntag-Vormittag fand ich zudem noch heraus, dass auch curl und wget am Webserver scheinbar nicht mehr funktionierten und ich bei beiden stets einen Timeout-Fehler erhielt. Den Grund hierfür fand ich zwei Tage später heraus, und zwar aktualisierte mein Webhoster das OS des Webservers am Dienstag, dem 10. Oktober 2023, auf Debian 11 (Bullseye), was vielleicht damit zusammenhängen könnte – oder auch nicht. Den zu meiner Verwunderung funktionierten curl und wget eh wie erwartend, solange keine Dateien heruntergeladen werden sollen, die just auf demselben Webserver, über die der Abruf initialisiert wurde, liegen. Tja, und genau das machte auch das Python-Script für den Logfile-Import, nur halt in umgekehrter Richtung via HTTP-POST. Am Mittwoch, dem 27. September 2023, funktionierte es noch problemlos, seit Dienstag, dem 7. November 2023, hingegen muss ich jenes Python-Script in meiner Linux Mint 21-VM hierfür ausführen lassen. Ja, das funktionierte, bedurfte allerdings der Angabe eines Auth-Tokens für Matomo. Das steht so übrigens auch in der Readme-Datei zu diesem Python-Script.

The script will automatically read your config.inc.php file to get the authentication token and communicate with your Matomo install to import the lines. If your Matomo install is on a different server, use the --token-auth=>SECRET< parameter to specify your API token.

Die Matomo-Archivierung selber ist von dieser von meinem Webhoster neu gesetzten Firewall-Regel für diesen Webserver, wobei es sich hierbei ja um ein Shared Webhosting-Paket handelt, erfreulicherweise nicht negativ betroffen. Diese Archivierung, an dessen Anschluss weitere geplante Aufgaben, wie z.B. Datenbank-Einträge aufräumen, abgearbeitet werden, muss meines Wissens nach im Terminal des Webservers, auf dem Matomo installiert ist, angestoßen werden. Sprich: Man braucht einen SSH-Zugriff, der übrigens stets fehlerfrei funktionierte. Interessanterweise funktionierte seit diesem OS-Upgrade bzw. seit der Implementierung jener Firewall-Regel auf diesem Webserver der automatische Versand der monatlichen Matomo-Berichte via E-Mail nicht mehr. Erst nach Durchführung der Matomo-Archivierung werden nun jene im Rahmen der Abarbeitung der geplanten Aufgaben versandt. Ist das Tragisch: Jein, da auch Matomo-Update-Benachrichtigungen via E-Mail hiervon betroffen sind – ich jene allerdings auch dessen RSS-Feed in Mozilla Thunderbird abonniert habe. Was allerdings aufgrund dieser Blockade seither nicht mehr funktioniert ist der hauseigene Systemcheck von Matomo betreffend der Prüfung privater Verzeichnisse am Webserver, die über das Internet nicht erreichbar sein sollen. Das ist etwas blöd, wenn dort nun u.a. folgendes steht:

Unable to execute check for https://danielmayr.at/matomo/tmp/: curl_exec: Connection timed out after 2001 milliseconds. Hostname requested was: danielmayr.at

Nachdem nun am Dienstag, dem 7. November 2023, der Befehl für den Logfile-Import in PuTTY via SSH über die Linux Mint 21-VM für jede Logdatei noch einzeln angestoßen werden musste – wie dies seit jeher auch am Webserver der Fall gewesen war –, wurde u.a. dieser nervige Schritt nebst dem Befehl zur Durchführung der Matomo-Archivierung im Bash-Script nun so implementiert, dass alle Logdateien in einem Rutsch nacheinander importiert werden. Und als ich jenes Bash-Script mit diesen Änderungen am Sonntag, dem 3. Dezember 2023, um 10:20 Uhr fertig hatte und um 10:32 Uhr zum ersten Mal testen wollte, funktionierte der Logfile-Import nicht, da ein $-Zeichen im entsprechenden python3-Befehl fehlte und somit die Variable "matomo_idsite" nicht aufgelöst werden konnte. Im Terminal wurde mir hier dann 10 Mal folgende Fehlermeldung ausgegeben, wobei das "x" für die aktuell zu importierende Logdatei, also 1 bis 10, steht:

Importiere x von 10 Logdateien. Fatal error: cannot get the main URL of this site: An unexpected website was found in the request: website id was set to 'matomo_idsite' .
Kein Eintrag in weniger als einer Sekunde.

Das war jetzt allerdings nicht der einzige Fehler. Denn nachdem dann das Bash-Script erfolgreich von 10:36 bis 10:59 Uhr durchlief, wollte ich einen Blick in die Matomo-Logdatei (*.mclog) werfen, in der ich die Terminal-Ausgaben der Matomo-Archivierung umleiten ließ. Nur fand ich jene im 7z-Archiv nicht, da ich jenen Dateityp in der Auflistung der zu komprimierenden Dateien (Log-, Python-Log- und Matomo-Logdateien) vergessen gehabt hatte anzugeben – bei den Lösch-Befehlen war sie aber bereits vorhanden gewesen. Blöd gelaufen. Nachdem dieser kleine Fehler ebenfalls unmittelbar danach korrigiert wurde, baute ich gleich noch eine Funktion ein, die die Dauer, die jenes Bash-Script gelaufen ist, am Ende im Terminal ausgibt. Um 11:50 Uhr an diesem Tag war ich folglich damit fertig gewesen und das Bash-Script wuchs auf 11,0 KB an. Bei den Python-Logdateien handelt es sich übrigens um die Terminal-Ausgaben des Logfile-Imports, aus denen die Anzahl der importierten Log-Einträge und die Dauer hierfür herausgefiltert und im Terminal dann nur diese beiden Werte ausgegeben werden. Diese ganzen Logdateien, die allesamt keine personenbezogenen Daten enthalten, lasse ich nur Zwecks Fehlerdiagnose in ein 7z-Archiv packen, sollte etwas mal nicht wie erwartet funktionieren.

Während des Dezembers entschied ich mich dann dieses Bash-Script zu veröffentlichen, sodass ich nun im Jänner 2024 nach und nach zahlreiche Funktionen einbaute, die oben im Abschnitt "Bash-Script-Übersicht (Abschnitte p0 bis pb)" nachgelesen werden können. Eine Auflistung der Zeitspannen der 20-teiligen Arbeiten an diesem Bash-Script habe ich übrigens am Ende dieser internen News angefügt, da jene Angaben in der veröffentlichten Version des Bash-Scripts meiner Ansicht nach nichts zu suchen haben. Worauf ich nämlich gezielt aufgrund der Veröffentlichung geachtet gehabt habe, war dieses Bash-Script so flexibel wie möglich zu gestalten, sodass einzelne Teil-Aufgaben, wie z.B. der Download der Apache-Access-Logdateien vom Webserver via SCP oder das Komprimieren der Log-, Python-Log- und Matomo-Logdateien vor deren Löschung gezielt ein- bzw. ausgeschaltet werden können. Zudem versuchte ich die Terminal-Ausgaben allesamt so zu gestalten, dass jene problemlos mittels Sprachausgabe von einem Screenreader vorgelesen werden können. Daher gibt's hier auch etliche if-Abfragen betreffend der Anzahl bestimmter Werte, damit am Ende im Terminal z.B. entweder "2 Sekunden", "einer Sekunde" oder "weniger als einer Sekunde" steht. Würde dort nämlich nur "1 Sekunde(n)" stehen, so würden die meisten TTS-Engines – abhängig der Screenreader- und TTS-Einstellungen – "Eins Sekunden" oder gar "Eins Sekunde Klammer auf Enn Klammer zu" vorlesen, was halt eben nicht korrekt ist.

Am Donnerstag, dem 11. Jänner 2024, von 10:20 bis 10:23 Uhr, während ich an diesem Bash-Script weiterarbeitete, kam es übrigens ohne Vorwarnung zu einem Strom-Ausfall im gesamten Ortszentrum in Pichl bei Wels, wodurch ich gleich mal rund 14 Minuten an nicht gespeicherter Arbeit erleichtert wurde. Gut, dass ich den Großteil dieser Zeit mit logischem Denken verbracht hatte, sodass die verloren gegangenen Zeilen rasch erneut dem Bash-Script wieder händisch hinzugefügt werden konnten. Jepp, auch wenn ich für dieses Bash-Script – wie auch schon bei Oscar – vereinzelt auf Phind, eine mit KI-Sprachmodellen angereicherte Suchmaschine für Entwickler und technische Fragen, zurückgriff, war der Großteil des gesamten Bash-Scripts nur mit menschlichen, logischen Denken möglich gewesen. Wobei Phind für die Umsetzung einiger Aufgaben durchaus extrem nützlich und vor allem zeitsparend war, zumal man sich dort auch alternative Lösungen sowie genauere Erklärungen ausgeben lassen kann. Womit es damit allerdings derzeit noch arge Probleme gibt, sind die korrekte Platzierung von Backslashes bei einzelnen Kommandos sowie das Produzieren halbwegs sicherem Code. Hier sprang dann ShellCheck, ein Lint-Tool u.a. für Bash-Scripts, zur Seite, wobei auch dieses Lint-Tool nicht alles an teils unsicheren Code (z.B. aufgrund fehlender Anführungszeichen) erkennen kann.

Nachdem am Mittwoch, dem 24. Jänner 2024, um 00:30 Uhr jenes Bash-Script auf satte 72,7 KB und exakt 1.500 Zeilen angewachsen war und alles bis auf einen Punkt implementiert war, ließ ich jenes nun am Freitag, dem 26. Jänner 2024 von 23:34 bis 23:45 Uhr erneut laufen. Zudem konnte ich diesmal die Apache-Access-Logdateien mittels SCP-Befehl in diesem Bash-Script direkt herunterladen lassen, da die Funktion zum Löschen bereits in Matomo importierter Logdateien mittlerweile vollständig implementiert gewesen war. Jepp, und hier traten erfreulicherweise keine Fehler auf – bis auf sieben Mal "./mil.sh: Zeile 860: Ausständig: Befehl nicht gefunden", da in Abschnitt p5 "(Ausständig)", also nicht auskommentiert, in jener Zeile stand. Dieser Abschnitt, in der IPv4- und IPv6-Adressen in allen Logdateien anonymisiert werden, wurde nämlich erst am vergangenen Samstag, dem 27. Jänner 2024, sowie zwei Tage darauf quasi fast neu geschrieben. Ja, jener Abschnitt, mit dem alles am 2. September 2023 einst begann, wurde nun ebenfalls schön gemacht – sofern man bei in Summe 42 sed-Kommandos mit einer Länge von bis zu 305 Zeichen von "schön" sprechen kann.

Ohne ein Braille-Display mit 80 Braille-Modulen (in nur einer Zeile) wäre ich hier aufgrund der zahlreichen runden, eckigen und geschweiften Klammern nebst etlichen Backslashes und all den anderen Zeichen komplett aufgeschmissen gewesen. Nein, mit reiner Sprachausgabe kann man meiner Ansicht nach diese Ungetüme nicht erfassen. Das wäre viel zu mühselig, wobei für mich das haptische Lesen mit rund 3 Zeichen pro Sekunde bzw. mit nur lausigen 25 bis 30 Wörtern in der Minute ebenfalls äußerst anstrengend ist. Deshalb war ich nach den meisten Arbeiten an diesem Bash-Script danach auch ziemlich bis komplett K.O. und konnte den restlichen Tag quasi in die Tonne treten. Die Sprechgeschwindigkeit der Sprachausgabe am Stand-PC (IBM ViaVoice TTS) liegt seit Dienstag, dem 19. November 2013, 13:35 Uhr übrigens bei 426 Wörtern/Minute, wobei ich in NVDA die Ausführlichkeitsstufe von Symbolen und Satzzeichen auf "Einige" eingestellt habe, sodass mir auch nur "einige" Zeichen mit deren Bezeichnung vorgelesen werden.

Und Klammern fallen hier bei meiner Screenreader-Konfiguration übrigens nicht darunter, weshalb jene erst dann vorgelesen werden, wenn ich den Cursor mit den Pfeiltasten zeichenweise dorthin bewege. Jepp, dass dauert dann halt seine Zeit, insbesondere wenn man bedenkt, dass Menschen mit einem Visus von 1,0 oder knapp darunter in der Regel rund 30 Zeichen in der Sekunde bzw. rund 250 bis 300 Wörter in der Minute visuell lesen können. Ich selber schaffte damals bei einem Visus links von gerade einmal 0,035 eine visuelle Lesegeschwindigkeit von rund 80 Wörtern pro Minute, also rund dem 3-fachen meiner jetzigen haptischen Lesegeschwindigkeit. Und nein, die Sprachausgabe mittels TTS-Synthesizern hat nichts mit Lesen zu tun, denn die Sprachausgabe ist ein linearer Informationskanal. Daher ist und bleibt Lesen – egal ob visuell oder haptisch – meiner Meinung nach ein absolutes Grundbedürfnis, vor allem am Anfang des 21. Jahrhunderts, wozu ich mich hier in der HUC-Braille-Tabellen-Dokumentation bereits ausführlich geäußert habe.

Warum habe ich das dann alles gemacht, wenn es derart anstrengend war? Das hat viele Gründe: 1. Weil ich es konnte und wollte, zumal die Erstellung eines Bash-Scripts eine aktive – und auch kreative – Tätigkeit ist. 2. Weil es trotz alledem extrem Spaß gemacht hatte Probleme und Aufgabenstellungen erfolgreich gelöst haben gekonnt zu haben, insbesondere da die Bash echt coole Funktionen zur Text-Manipulation bereithält, wovon ich zuvor keine Kenntnis hatte. Vor allem awk und sed in Kombination mit head, tail und der Bash-eigenen Substitutions-Methoden, also Zeichenersetzungs-Methoden, sind äußerst mächtig, sodass das Herausfiltern des Datums "[01/Feb/2024 " aus der ersten sowie letzten Zeile einer Apache-Access-Logdatei und das Umwandeln jener in "2024-02-01" quasi ein Kinderspiel ist. Man muss halt nur jeden einzelnen Schritt genau peu à peu angeben und am Schluss alles wieder passend zusammenführen. Das macht einfach nur einen riesen Spaß. Schön, dass ich das alles nun nicht mehr mit meinem Hirn machen muss, sondern der Blechtrottel diese Arbeit für mich in einer rasenden Geschwindigkeit übernimmt, was uns sogleich zum nächsten Grund führt.

3. Weil mir, wie einleitend bereits geschrieben, diese periodisch wiederkehrenden, repetitiven Arbeitsabläufe ebenfalls zu viel Konzentration von mir abverlangten und somit nur noch nervig waren. Und 4. Weil am Dienstag, dem 12. Dezember 2023, im KUK Linz neben dem sich in der Vorderkammer in linken Auge befindlichen Silikonöl, was dort absolut nichts zu suchen hat, nun zusätzlich eine Gefäßneubildung an und in der Hornhaut (Neovaskularisation) diagnostiziert wurde. Am Dienstag, dem 20. Februar 2024, findet daher eine OP unter Vollnarkose am linken Auge (Kauterisierung der oberflächlichen Hornhaut-Gefäße, Ligatur der endothelialen Hornhaut-Gefäße und Entfernung der Silikonölblase aus der Vorderkammer) statt. Und ich habe absolut keine Ahnung, ob das überhaupt etwas nutzt, zumal ich seit Mitte November 2022 nahezu täglich mehrstündige Schmerzen am linken Auge habe, noch was mit dem linken Auge danach passieren wird. Im schlimmsten Fall muss es komplett entfernt werden. Das rechte Auge macht hingegen keine Probleme, wurde allerdings bereits im Dezember 1987 derart ruiniert, sodass ich dort nie etwas sehen konnte.

Kommen wir nun aber wieder zurück zur letzten, also der 20. Arbeitssitzung an diesem Bash-Script, in der ich lediglich nur noch vier kleine Checks bzgl. des Vorhandenseins der Kommandos grep, sed, tar und xz im Abschnitt p2 hinzufügte und ein paar Tippfehler in den Kommentaren der ersten drei Abschnitte (P0 bis P2) korrigierte – für die restlichen Abschnitte blieb leider keine Zeit mehr. Heute um 01:20 Uhr war ich damit fertig gewesen, sodass das Bash-Script final nun 89,6 KB schwer war und satte 1668 Zeilen aufwies. Von 01:22 bis 01:28 Uhr bereitete ich jenes Bash--Script für die Veröffentlichung vor, da hier einige Variablen im Abschnitt p1 aus Sicherheitsgründen noch dringend entfernt bzw. abgeändert werden mussten. Zudem fehlt in dieser Version – wie bereits geschrieben – auch die Auflistung der Arbeiten an diesem Bash-Script, weshalb es um 23 Zeilen kürzer ist. Und Unmittelbar vor dem Upload um exakt 01:30 Uhr fügte ich in beiden Versionen nach dem "fi"-Befehl in der allerletzten Zeile noch einen Zeilenumbruch hinzu, sodass es sich in der letzten Zeile um eine komplett leere Zeile handelt, was in der Linux-Welt üblich ist. Das war nun also erledigt

Mila's Rattenschwanz:

Worum ich mich bis zu jenem Zeitpunkt allerdings noch überhaupt nicht gekümmert gehabt hatte, da ich keine Zeit hierfür gehabt hatte, waren sämtliche Arbeiten an Daniel Mayr.at, wie z.B. das Erstellen dieser internen News hier. Diese ging dann um 01:46 Uhr nebst Anreißertext online, wobei ich dessen Uhrzeit-Angabe auf 01:30 Uhr beließ, handelt es sich hierbei ja um den Zeitpunkt der Veröffentlichung des Bash-Scripts "mil.sh". Um 02:00 Uhr ging dann mal die erste Version der Downloads-Seite online, auf der nun der Abschnitt Bash-Scripts nebst einem Link zu jener sh-Datei ersichtlich war. Anschließend kümmerte ich mich dort um die Anmerkungs- und Hinweise-Texte, die sowohl auf Deutsch als auch auf Englisch vorhanden sind. Ja, die Kommentare und Terminal-Ausgaben jenes Bash-Scripts sind auf Deutsch verfasst, was allerdings keinen Einfluss auf die Funktionalität jenes Bash-Scripts hat. Es folgte dann noch das Aufsetzen des entsprechenden Logbuch-Eintrags sowie das Abändern des Anreißer-Abschnitts "Interne News" im linken Bereich auf der Home-Seite, da dies alles manuelle Prozesse sind. Nachdem ich damit um 03:50 Uhr vollständig fertig gewesen war, ging's mal ab ins Traumland.

Gleich am Folgetag, also am 2. Februar 2024, kopierte ich nach und nach, also mit kleinen Pausen dazwischen, die drei Abschnitte "Bash-Script-Metadaten", "Bash-Script-Übersicht (Abschnitte p0 bis pb)" und "Arbeiten an diesem Bash-Script" aus dem Bash-Script in diese interne News, legte die Formatierungen jener fest und lud jene dann um 03:55 Uhr hoch, damit das schon mal erledigt war. Fehlten jetzt nur noch die eigentlichen Texte, die ich am Donnerstag, dem 8. Februar 2024, von 03:00 bis 06:25 Uhr, am Freitag, dem 9. Februar 2024, von 05:25 bis 08:30 Uhr und am Samstag, dem 10. Februar 2024, von 06:05 bis 08:40 Uhr niederschrieb, korrekturlas und schlussendlich hochlud. Am Sonntag, dem 11. Februar 2024, von 07:30 bis 10:15 Uhr gab's nochmals eine Runde Korrekturlesen dieser internen News u.a. nebst kleiner Erweiterung der beiden Absätze betreffend dem Braille-Display, damit dieses Thema "Lesen" verständlicher und nachvollziehbarer rüber kommen kann. Puh, was für ein Rattenschwanz, zumal ich erst am Freitag, dem 9. Februar 2024, um 05:32 Uhr dem Sidebar-Block "Sehenswertes" einen Eintrag zu dieser internen News hier noch rasch hinzufügte, da ich zuvor darauf komplett vergessen gehabt hatte.

Und dies führt sogleich zu Grund #5, warum ich all dies gemacht habe: Ich hatte während alledem keine Zeit mir Gedanken an meine bevorstehende, vielschichtige, hochriskante, aber medizinisch notwendige Augen-OP zu machen. Somit bleibt mir zum Schluss nur noch euch viel Spaß und Freude mit Mila zu wünschen. Dieses Bash-Script läuft übrigens auch auf einem Raspberry Pi Zero W mit Raspberry Pi OS problemlos – wenn auch teils etwas gemächlicher als in der Linux Mint 21-VM auf meinem Stand-PC mit einem Intel Core i7 960.

Arbeiten an diesem Bash-Script:

1. 2023-09-02 08:16 - 2023-09-02 08:52
2. 2023-11-23 23:21 - 2023-11-24 01:51
3. 2023-12-01 04:01 - 2023-12-01 06:39
4. 2023-12-03 07:58 - 2023-12-03 11:50
5. 2024-01-01 03:39 - 2024-01-01 06:21
6. 2024-01-02 04:00 - 2024-01-02 07:44
7. 2024-01-03 06:35 - 2024-01-03 09:40
8. 2024-01-04 07:00 - 2024-01-04 10:12
9. 2024-01-05 08:00 - 2024-01-05 11:10
10. 2024-01-11 09:36 - 2024-01-11 12:49
    
    
11. 2024-01-15 13:58 - 2024-01-15 16:00
12. 2024-01-17 14:30 - 2024-01-17 18:25
13. 2024-01-18 17:55 - 2024-01-18 20:15
14. 2024-01-19 18:58 - 2024-01-19 21:30
15. 2024-01-20 19:25 - 2024-01-20 22:50
16. 2024-01-22 22:20 - 2024-01-23 01:20
17. 2024-01-23 20:10 - 2024-01-24 00:30
18. 2024-01-27 22:00 - 2024-01-28 01:55
19. 2024-01-29 21:45 - 2024-01-30 01:10
20. 2024-01-31 22:25 - 2024-02-01 01:20