Glow Markdown in der Shell rendern

Markdown ist eine leicht verständliche Auszeichnungssprache für Texte. Einige von Euch kennen jene aus Readme-Dateien aus Git Repositories, Dokumentationen und von statischen Bloggeneratoren wie Hugo, oder Jekyll. Markdown bietet für mich entscheidende Vorteile.

Ein in Markdown formatierter und strukturierten Text ist für immer in der gewünschten Formatierung betrachtbar. Er ist nicht an ein bestimmtes Programm und seiner Syntax gebunden. Im Gegensatz dazu öffnen sich alte Dateien aus Officeanwendungen aus Redmond der 90er Jahre nur mit Verlusten in neueren Programmen, wobei bereits viel der Formatierung und dessen Struktur verloren geht. Besonders problematisch wird es, wenn Programme nicht mehr auf neuen Systemen laufen, oder wenn sie für eine Installation nicht mehr verfügbar sind. Hier drohen uns in Zukunft digitale Verluste.

Markdown überzeugt durch seine gute Lesbarkeit ohne Rendering, sowie durch die einfache Syntax bei der Erstellung von Texten, Tabellen und Listen. Markdown erlaubt es, Text mit einfachen Symbolen zu formatieren. So rahmen zwei ** einen fetten Text ein, während ein * kursiven Text markiert und eine H1-Überschrift ihre Formatierung durch eine Raute mit Leerzeichen vor dem Text erhält. Für Überschriften in unteren Ebenen verwendet man entsprechend zwei, drei oder vier Rauten. Weitere Informationen finden sich in dem Artikel auf Wikipedia. Ich selbst nutze für die einfach und schnelle Auszeichnung Typora unter Linux und macOS. Ich gebe auch zu, damit meine README.md gerne in Git zu gestalten. Typora erstellt mir auf Knopfdruck ein Inhaltsverzeichnis aus den Überschriften inklusive Anker 😉

Während Markdown-Dateien in dafür bestimmten Texteditoren, wie z.b. dem oben genannte Typora, gut formatiert lesbar sind, benötigen Markdown-Dateien zum Rendern in der Shell eine spezielle Software, um eine perfekte Darstellung zu bekommen. Hier kommt Glow ins Spiel.

Was ist Glow?

Kurz und knapp: Glow ist ein auf ein der Programmiersprache Go basierendes Shellprogramm, welches Markdown-Dateien direkt in der Shell rendert. Es stellt die Inhalte übersichtlich formatiert, inklusive Links, und farbig dar.

Je nach System wird Glow über die Paketmanager der Linuxdistribution installiert. Glow lässt unter Debian, macOS ( via brew), FreeBSD, Fedora und sogar Android installieren. Natürlich besteht auch die Möglichkeit, glow über die Sprache go selbst zu installieren.

Nutzung

Glow kann mit einer lokalen Markdown-Datei aufgerufen werden:

glow README.md

Auch eine Vorschau von Markdown-Dokumenten aus dem Internet wäre möglich:

glow https://raw.githubusercontent.com/charmbracelet/glow/refs/heads/master/README.md

Des Weiteren bietet glow noch einen Pager und die Möglichkeit eigene Styles zu definieren und herunterzuladen.

Glow ist Teil des Charmprojektes welches eine Sammlung von Open-Source-Tools/-Bibliotheken für die Entwicklung von terminalbasierten Anwendungen ist. Das Charmprojekt ist die Glamourecke der modernen und benutzerfreundliche CLI-Programme 😉

Readeck eine Read it later Alternative

Ich habe im Jahr 2013 das erste Mal Wallabag geschrieben, zu diesem Zeitpunkt hieß es noch Poche. Für mich der Beginn einer sehr langen, bis heute noch andauernden, Freundschaft mit der Software. Es ist aber wichtig auch immer wieder einmal über den Zaun zu schauen, falls ich mit einer Software in Zukunft nicht mehr zufrieden sein könnte. Zu groß wird der Stress und die Enttäuschung, wenn ich den jahrelangen Workflow so schnell wie möglich ändern muss. Beziehungsweise einen Stichtag habe, an dem ich die Änderung herbeizuführen habe.

Ich habe mir als Player neben Wallabag einmal Readeck angeschaut und hier meine Wallabaglesezeichen importiert. Ich habe den Ablauf ohne Hindernisse ausgeführt, aber er hinterließ einige Leichen. Einige der mit Wallabag konservierten Webseiten sind nicht mehr Online, oder konnten nicht richtig von Readeck abgeholt werden. Ich bin zwar auf ein Script gestoßen, welches leider aber dann alle fehlerhaften Einträge löscht, wobei manche nur einmal angestoßen werden müssten.

Readeck unterscheidet sich nicht wirklich groß von Wallabag. Auch hier gibt es eine gute Browserintegration und die Oberfläche ist mehr als ein Quentchen besser als jene von Wallabag. Hierzu sei aber gesagt, dass Wallabag in sehr reger Entwicklung ist und mit dem nächsten Majorupdate, 3.0/4.0, auch hier nachzieht. Ich hatte hierzu mal eine Aussage im Fediverse gelesen, aber bedauerlicherweise findet sich in den alten News kein Hinweis. Readeck ist aber in der Tat momentan etwas „polierter“ und Anwenderfreundlicher. Im Gegensatz zu Wallabag bietet es ab Werk kein RSS-Feed an, dieser kann aber mit dem Projekt readeck-rss nachgerüstet werden. Ich selbst brauche diese Funktion aber nicht.

Ich selbst habe Readeck als Container bei mir installiert und den dort schon laufenden Apache als Proxy genutzt.

Apache Prox-Teil:

    RequestHeader set X-Forwarded-Proto https

    ProxyRequests off
    ProxyPass / http://127.0.0.1:8000/
    ProxyPassReverse / http://127.0.0.1:8000/
    ProxyPreserveHost On

docker-compose.yml:

services:
  readeck:
    container_name: Readeck
    image: codeberg.org/readeck/readeck:latest
    mem_limit: 8g
    cpu_shares: 1024
    security_opt:
      - no-new-privileges:true
    restart: unless-stopped
    ports:
      - 8000:8000
    volumes:
      - /volume1/docker/readeck/data:/readeck:rw
    environment:
     READECK_USE_X_FORWARDED: true
     READECK_DATABASE_SOURCE: postgres://readeck:readeckpass@readeck-db:5432/readeck

  readeck-db:
    image: postgres:16
    container_name: Readeck-DB
    hostname: readeck-db
    mem_limit: 1g
    cpu_shares: 768
    security_opt:
      - no-new-privileges:true
    healthcheck:
      test: ["CMD", "pg_isready", "-q", "-d", "readeck", "-U", "readeck"]
      timeout: 45s
      interval: 10s
      retries: 10
    volumes:
      - /volume1/docker/readeck/db:/var/lib/postgresql/data:rw
    environment:
      POSTGRES_DB: readeck
      POSTGRES_USER: readeck
      POSTGRES_PASSWORD: readeckpass
    restart: on-failure:5

Backup:

Das Backup landet dann inklusive des Datums in dem Volume von readeck ( /volume1/docker/readeck/data).

 docker exec Readeck readeck export -config /readeck/config.toml /readeck/export_$(date +"%Y_%m_%d").zip

iOS/ipadOS

Für das Share-Menü gibt es einen Shortcut“/Kurzbefehl unter send-page-to-readeck. Hier muss im Kurzbefehl, dann die Domain, sowie einen APi-Token, welcher unter Einstellungen > API-Token erstellt wird, eingegeben werden.
Damit der Befehl im Teilenmenü erscheint:

  • Langer Klick auf den Kurzbefehl bis zu dem Öffnen des Menüs
  • Details auswählen
  • Im Share-Sheet anzeigen aktivieren

Android

Für Android gibt es eine Readeck App, welche unter F-Droid zu finden ist. Ich selbst habe sie noch nicht installiert, da mein daily driver ein iPhone 16 Pro ist.

Fazit

Readeck hat mich mit seiner sehr eleganten Benutzeroberfläche und vor allem der unkomplizierten Installation überzeugt. Es fällt mir jedoch schwer, Wallabag nach über einem Jahrzehnt treuer Dienste den Rücken zu kehren. Da spielt sicherlich auch eine nicht kleine Portion Nostalgie mit 😉
Momentan teste ich beide Lösungen im Parallelbetrieb und werde in den nächsten Wochen entscheiden, welches Projekt das richtige für mich ist. Mir wäre es auf jeden Fall wichtig, auch wenn den Weg zu Wallabag zurückzugehen. Bis jetzt gestaltet dies sich wohl sehr schwierig. Seiten der Wallabag 2.x Dokumentation ist hier über den Import nichts zu finden. Hier bleibt wohl nur dann einer der Wege den Export von Readeck in das JSON-Format von Wallabag zu konvertieren, Datenbanklevel-Migration vorzunehmen, oder noch schlimmer, Zeit mit einer manuelle Rearchivierung zu verbrennen. Dies ist für mich ein großer Negativpunkt bezüglich Readeck. Keine Sackgassen.

Invidious: The media could not be loaded format not supported

Invidious ist eineSoftware, die es ermöglicht, Videos von YouTube anzusehen, ohne direkt die offizielle YouTube-Website, oder App zu verwenden. Die selbstgehostete Software ermöglicht eine werbefreie Nutzung von Youtube und schützt die Privatsphäre der Nutzer, indem es Tracking durch Google verhindert. Invidious bietet die weiteren Funktionen wie das Herunterladen von Videos, das Ansehen ohne Anmeldung und die Möglichkeit, nur den Audiostream abzuspielen.

Ich hatte nun etwas länger meine private Instanz auf dem Homeserver genutzt und stieß auf den Fehler
„The media could not be loaded, either because the server or network failed or because the format is not supported“.

Damit die Software wieder produktiv arbeitet, muss hier ein weiterer Container erstellt und die Datei docker-compose.yml für Euren Stack umgeschrieben werden.

Als Erstes wird ein einzelner Container via

 docker run quay.io/invidious/youtube-trusted-session-generator

gestartet und nach einem Start die Ausgabewerte des Containers für visitor_data und po_token kopiert.
Dieser Container beendet sich nach der Ausgabe von selbst und sollte nicht detached gestartet werden.

docker run quay.io/invidious/youtube-trusted-session-generator
[INFO] internally launching GUI (X11 environment)
[INFO] starting Xvfb
[INFO] launching chromium instance
[INFO] launching browser.
[INFO] waiting 10 seconds for the page to fully load.
visitor_data: TOLLERHASHWERT1
po_token: TOLLERHASHWERT2
successfully removed temp profile /tmp/uc_3aimnef0

Jene Werte habe ich, inklusive des neuen Containers, in die Datei docker-compose.yml eingepflegt.

version: "3"
services:
  invidious:
    image: quay.io/invidious/invidious:latest
    container_name: invidious
    restart: unless-stopped
    ports:
      - "4000:3000"
    environment:
      INVIDIOUS_CONFIG: |
        db:
          dbname: invidious
          user: kemal
          password: kemal
          host: invidious-db
          port: 5432
        check_tables: true
        signature_server: inv_sig_helper:12999
        visitor_data: TOLLERHASHWERT1
        po_token: TOLLERHASHWERT2
        quality: dash

        registration_enabled: false
        top_enabled: false
        related_videos: false
        comments: ["",""]
        login_enabled: false
        domain: TOLLERFQDN
        hmac_key: "BLABLABLABLABLA"

    depends_on:
      - invidious-db
    logging:
      options:
        max-size: "1G"
        max-file: "4"

  inv_sig_helper:
    image: quay.io/invidious/inv-sig-helper:latest
    init: true
    command: ["--tcp", "0.0.0.0:12999"]
    environment:
      - RUST_LOG=info
    restart: unless-stopped
    cap_drop:
      - ALL
    read_only: true
    security_opt:
      - no-new-privileges:true
  invidious-db:
    image: docker.io/library/postgres:14
    restart: unless-stopped
    container_name: invidious-db
    volumes:
      - ./postgresdata:/var/lib/postgresql/data
      - ./config/sql:/config/sql
      - ./docker/init-invidious-db.sh:/docker-entrypoint-initdb.d/init-invidious-db.sh
    environment:
      POSTGRES_DB: invidious
      POSTGRES_USER: kemal
      POSTGRES_PASSWORD: kemal
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U $$POSTGRES_USER -d $$POSTGRES_DB"]
    networks:
      - default

Weiterführende Informationen bezüglich einem Fehler mit sigv_helper und kontobasierter Authentifizierung finden sich in der Issue 4947 auf Github

Viel Spaß mit Invidious.

macOS: LibreOffice nicht aus Apples App Store installieren

Einmal wollte ich faul sein und gleichzeitig einem FOSS-Projekt etwas Gutes tun. Anstelle mich immer selbst um ein Update von LibreOffice zu kümmern, wollte ich es aus dem Apple App Store installieren, via selbigen an das Projekt spenden und die Downloadzahlen im Store um eine Wertigkeit erhöhen. Automatische Updates im Hintergrund sollten hier die Wahl sein. Als gewissenhafter Verbraucher beobachte ich, die von mir installieren Pakete und deren Projekte auf Neuigkeiten und vor allem auf Sicherheitsmeldungen. Im Falle von LibreOffice gab es hier ein Sicherheitsproblem in der Version 7.6.6, welche mit der Version 7.6.7 relativ zügig behoben wurde.
Das Sicherheitsrelease ist bis heute nicht in Apples App Store angekommen.

Weiterlesen

Neues Theme in WordPress neue Darkmode CSS

Im Frontend ändert sich mein Blog nur noch marginal. Jedoch musste ich mich aufgrund von Änderungen im Sourcecode von WordPress für ein anderes Theme entscheiden. Zuvor hatte ich ein Theme von einem deutschen bekannten Entwicklerpaar gekauft, aber leider endet hier der Support doch recht schnell. Auch Bugfixes, welche ich einmal auf Github eingereicht hatte, wurden erst nach zwei Jahren (🦉really?!?!) eingepflegt. Es ist eher ein „Aus den Augen, aus dem Sinn“-Coding und ich würde hier kein Geld mehr investieren.

Weiterlesen

Entfernen des gist-Plugins und YouTube aus WordPress

Ich habe nun das nächste Plugin aus WordPress entfernt. Auch habe ich mir nochmals Gedanken über dieses Plugin gemacht und es ist definitiv nicht Datenschutz konform, wenn ich Daten aus Github nachgeladen habe. Ich hatte zwar somit immer die neueste Version des Codes eingebunden, aber es war eigentlich eine Faulheit auf Kosten der Lesenden.

Im Moment suche nun Shortcodes mit der Bezeichnung gist id=“ und kopiere den Inhalt dieser Gists in den Fließtext. Die richtige Aufgabe während meiner Krankmeldung. Falls ich mich mit etwas anderem als im Bett liegen und Hörbuch hören befassen möchte. Für das Teilen von Code habe ich mir noch keine Gedanken gemacht, aber es wird definitiv selbst gehostet und sollte keinen großen Pflegebedarf haben. Bis jetzt habe ich hier leider noch nichts gefunden. Gitlab und ähnliche Projekte wären mit Kanonen auf Spatzen geschossen. Gitweb wäre ein Lösung, habe ich noch nicht im shared Hosting noch nicht getestet.

Vor sehr langer Zeit war es einmal in der Blogosphäre gang und gebe die Videos der Plattform YouTube einzubinden. Damit ich hier nicht mit den Daten der Lesenden hausieren gehe, hatte ich das Plugin „Lazy Load for Videos“ installiert. Diese direkten Links wurden nun gegen normale ausgetauscht

Ich konnte mir viel Handarbeit wieder zwei Plugins deaktivieren und entfernen.
Mittlerweile sind nun 9 Plugins deaktiviert bzw entfernt worden.

Plugin WP-Appbox für WordPress deaktiviert

WP-Appbox ist ein wunderbares Plugin, welches vielfältige Darstellungsmöglichkeiten für die Verlinkung verschiedener Apps bietet. Das Plugin war bei mir seit 2013 in Benutzung. Ich habe es erstmals bei dem Blogbeitrag Ownstagram ein eigenes Instagram verwendet. Das Plugin bindet verschiedene Stores anhand eines Shortcodes ein und zieht sich hier die gewünschten Daten aus dem Shop. Ein verlässliches Plugin, welches ich immer empfehlen würde. Aber ich habe es nicht wirklich gebraucht.

Da ich WordPress gerade auf ein exportierbares Minimum migriere, war es für mich klar, dass auch dieses Plugin aus meiner Installation verschwindet. Leichter gesagt als getan. Der Shortcode der App beinhaltet appbox und dieser befindet sich in 32 Blogeinträgen und dort als mehrmaliger Eintrag.

Beispielcode von WP-Appbox. Einträge 1,2 verweisen auf Apples Store , Einträge 3 und 4 auf den Google Playstore
[appbox appstore id654810212]
[appbox appstore id1062526415]
[appbox googleplay com.freeletics.lite]
[appbox googleplay com.freeletics.android.running]

Hier habe ich nun jeweils den Code gelöscht, die echten URLs herausgesucht und in den Text eingepflegt. Dabei ist mir aufgefallen, dass das Plugin auf viele Leichen verwiesen hatte. Diese gebrochenen Links sind auch dem WordPress-Plugin Link Checker nicht aufgefallen und gemeldet worden. Von diesem nutze ich noch die alte lokale funktionale Version. Auch dieses Plugin drückt es langsam in die Cloud und falls eine lokale Verifizierung der Links nicht mehr möglich ist, muss ich mich um eine Alternative kümmern.

Es ist ein wenig Arbeit, um einfach nur aus der Insellösung zu kommen. Bei den Galerien hatte ich aufgepasst, hier wurde FooGallery bei mir installiert. Auch diese besitzt Shortcodes, baut aber auf der Mediengalerie von WordPress auf. Wie bei anderen Plugins erfolgt hier kein Aufbau einer eigenen Mediengalerie wie bei anderen Plugins. Die Galerien müsste ich händisch nachbauen.

Cookieless WordPress seit heute

Ich habe nun meine Bannermeldung nach dem Telekommunikation-Telemedien-Datenschutz-Gesetz (TTDSG) abgeschaltet.
Siehe hierzu auch das Urteil des Bundesgerichtshofs vom 28. Mai 2020, Aktenzeichen I ZR 7/16.
Ich betrieb meine Installation von Matomo schon so, dass seitens Matomo keine Cookies gesetzt wurden. Durch das Abschalten der Kommentarefunktion in WordPress konnten auch hier auf Cookies verzichtet werden.

Weiterlesen

Auf ein Minimum in WordPress

Nach über 14 Jahren Gebrauch ist WordPress eine Art von Hassliebe. Es ist nicht so, dass ich nicht andere Plattform für das Schreiben im Netz ausprobiert hatte. Ich startete mit WordPress, besuchte Drupal,Octopress und Serendpity, um am Ende doch wieder bei WordPress zu landen.

Somit sitze ich im Moment vor meinem, doch in die Jahre gekommen Blog, und beginne aufzuräumen. Ausgeschaltet habe ich die Kommentarfunktion und konnte hierdurch nun zwei Plugins schon abschalten. Des Weiteren löse ich ein Plugin aus, welches mit Shortcodes eine eine bessere Verlinkung in verschiedene Appstore ermöglichte. Anhand der ID in Shops ließen sich hier automatisch QR-Codes und Screenshots in den Beitrag einbinden. Es dreht sich hier nicht Affiliate-Links. Etwas Arbeit, aber ich brauche es wirklich nicht mehr.

Nach einigen Hin und Her war ich kurz davor eine Migration in Jekyll für das Blog vorzunehmen. Ein statisches Blog hat Vorteile, wie auch Nachteile. Ich hätte serverseitig ein gutes Gefühl, aber betreffend der Arbeit an einem Blog bin ich mir nicht sicher, ob ich dies alles so möchte. Ich bin diesen Weg schon einmal gegangen. Wobei mein Ablauf für ein statisches Blog prädestiniert wäre.

Mein jetziger Ablauf für einen Artikel sieht so aus, dass ich unter Linux, oder macOS, mit Typora meine Posts in Markdown verfasse und dann in WordPress nochmals neu formatiere. Mit Jekyll würde ich hier mir mehr als einen Weg sparen. Aber ich müsste hier zum Beispiel auf zwei bei gute Plugins verzichten müssen, sowie auf den Import der alten Kommentare. Einmal schnell im Web weiterzuarbeiten ist hier keine Option, obwohl diese bei mir nie eigentlich eine Rolle spielt.

Vorerst also bei WordPress auf das nötige Beschränken an Plugins beschränken und dann sehe ich einmal weiter. Es besteht ja die Möglichkeit auch einmal zweigleisig zu fahren und bei Bedarf umzuschalten. In WordPress gibt es die Möglichkeit, Dateien im Format Markdown in WordPress zu importieren. Ich muss auf jeden Fall raus aus den Insellösungen der Shortcodes durch Plugins. Dann wäre das Migrieren und vielleicht auch der Rückweg eine Sache von Minuten. Der Import in Jekyll lokal hat mir hier ein kleines Grauen offenbart.

Fork: Grafischer Git-Client für macOS

Ich habe mich nach einer kleinen Testphase gegen GitKraken und für Fork als grafischen Client für Git unter macOS entschieden.
Gitkraken mag ein hervorragendes Werkzeug sein, aber das Abomodell hat mich abgeschreckt. Ich möchte noch erwähnen, dass GitKraken ein Studenten- und Universitätspaket anbietet. Ich werde vielleicht GitKraken Kollegen:innen an meinem Arbeitsplatz für einen Test vorschlagen. Dann können wir einmal nochmal einen direkten Vergleich vornehmen.

Für mich kam dieses Paket nicht infrage, da ich aus meinem Arbeitsplatz nicht einen Vorteil ziehen will. Die Lizenz möchte ich auch Privat nutzen und meine Frau würde sich auch über einen besseren Client freuen. Fork bietet mit hier die Möglichkeiten für 3 Installationen auf verschiedenen Systemen. Hiermit kann meine Frau unter Windows Fork nutzen. Leider bietet Ihr Arbeitgeber nur dieses Betriebssystem und keine Alternativen.

Natürlich könnten viele Aufgaben direkt in der Entwicklungsumgebung, oder via Shell gelöst werden. Ich will auch die Möglichkeiten einer besseren Visualisierung benutzen können. Diese sind dort nicht immer gegeben, beziehungsweise haben nicht dieses Aussehen wie in Fork. Neben den typischen Aufgaben eines Clients für git, bietet Fork noch Unterstützung für zum Beispiel git-flow und git LFS.

Als Haken könnte ich den Preis von 55,34 € für eine Lizenz erwähnen. Diese Lizenz beinhaltet drei gleichzeitige Installation für eine:n Entwickler:in. Ein Blick in die rege Entwicklung von Fork durch die Entwickler Tanya und Dan Pristupova, lässt mich positiv in Zukunft schauen. Hier möchte ich auch nochmals auf das Blog der Entwickler hinweisen.

Eine Sache ist mir noch sehr wichtig. Die Wahl wäre eher auf GitKraken gefallen, wenn ich für meine Arbeit und Privat nicht macOS nutzen würde. GitKraken unterstützt Linux deb,tar.gz,rpm und Snap. Sowie auch Mac mit Apple Silicon/Intel und Windows.
Aber hier bleibt der für mich der noch etwas freche, und mehr als bittere, Beigeschmack der Anzahl der Verbindungen zu einer Instanz für 4 € monatlich. Sie beträgt 1 Verbindung, siehe Screenshot. Das bedeutet, ich muss das Paket für 12 € monatlich abonnieren, um meinen Bedarf abzudecken.