Fryboyter

Inhalt am Ende des Front-Matter-Bereichs einfügen

Wenn ich einen Artikel für fryboyter.de schreibe, erstelle ich hierfür eine Markdown-Datei, an deren Beginn ein Front-Matter-Bereich vorhanden ist. Dieser sieht beispielsweise wie folgt aus.

---
title: Inhalt am Ende des Front-Matter-Bereichs einfügen
date: 2022-11-02T20:21:11+0100
categories:
- OSBN
tags:
- Front Matter
- Markdown
- Sed
slug: inhalt-am-ende-des-front-matter-bereichs-einfuegen
---

In manchen Fällen will man diesen Bereich nachträglich erweitern. Zum Beispiel mit nositemap: true damit der Artikel nicht in der Sitemap der Internetseite erscheint. Bei einem einzelnen Artikel ist das schnell erledigt, indem man die Datei manuell ändert. Was, aber wenn es nicht einen, sondern mehrere Dateien betrifft? Dann wäre es besser, wenn man die Änderungen automatisieren würde. Allerdings besteht der besagte Bereich nicht immer aus der gleichen Anzahl von Zeilen. Zum Beispiel, weil ich mal mehr, mal weniger Tags verwende. Schlussendlich bin ich zu folgendem Ergebnis gekommen.

for file in $(find . -type f -name "*.md");
do
lines=$( sed -n '/^---$/=' $file | sed -n 2p )
sed -i -e "$lines i nositemap: true" $file
done

Die erste Zeile sucht im aktuellen Verzeichnis und allen darin vorhandenen Unterverzeichnissen nach Dateien mit der Endung .md. Die dritte Zeile prüft aus wie vielen Zeilen der jeweilige Front-Matter-Bereich besteht. Die vierte Zeile erweitert den Bereich am Ende abschließend um nositemap: true, sodass dieser wie folgt aussieht.

---
title: Inhalt am Ende des Front-Matter-Bereichs einfügen
date: 2022-11-02T20:21:11+0100
categories:
- OSBN
tags:
- Front Matter
- Markdown
- Sed
slug: inhalt-am-ende-des-front-matter-bereichs-einfuegen
nositemap: true
---

Wer das Script erst einmal testen will, ohne dass die Dateien gleich direkt geändert wird, sollte in Zeile 4 den Paramter -i entfernen. Dann werden die geänderten Dateien nur angezeigt ohne, dass sie tatsächlich geändert werden.

Dank Musk ist mir wieder aufgefallen, dass ich Mastodon nutze

Kürzlich hat Elon Musk, nach einigem hin und her, Twitter endgültig gekauft. Kurz darauf wurden diverse Artikel veröffentlicht, welche Alternativen es gibt. Warum nicht schon vorher? Egal.

Aufgrund der Übernahme von Twitter habe ich mir überlegt, ob ich schon so etwas wie Twitter für fryboyter.de genutzt habe. Spontan lautet die Antwort nein, da ich mit den sogenannten “sozialen Medien” nichts anfangen kann. Daher habe ich beispielsweise kein Konto bei Twitter oder bei Facebook. Aber irgendwie war da mal was.

Nachdem ich etwas überlegt habe, ist mir eingefallen, dass ich irgendwann einmal mit IFTTT experimentiert habe um damit die auf fryboyter.de veröffentlichten Artikel auch auf anderen Plattformen zu veröffentlichen. Das ist aber schon lange her.

Wie ich eben festgestellt habe, gibt es das Konto bei IFTTT noch. Und das Applet ist zum einen noch aktiv und zum anderen veröffentlicht es die Artikel von fryboyter.de auf einem, meinen, Mastodon-Konto. Und noch überraschender, es gibt Leute die meine Veröffentlichungen dort lesen.

Vorerst werde ich das Applet / Konto aktiv lassen. Wer also will, kann sich über https://social.tchncs.de/@fryboyter über meine Veröffentlichungen informieren.

Aktiven Fork bei Github finden

Ab und an nutze ich sshfs ganz gerne um ein Verzeichnis über SSH lokal zu mounten. Die Entwicklung des Projekts wurde allerdings vor ein paar Monaten eingestellt. Heute wollte ich nachschauen, ob es einen aktiv weiterentwickelten Fork von sshfs gibt.

Was leider, zumindest direkt über github.com, nicht so einfach ist. Über https://github.com/libfuse/sshfs/network/members kann man sich zwar die Forks ansehen aber diese sind alphabetisch sortiert. Da es von sshfs derzeit 403 Forks bei Github gibt, könnte es etwas dauern bis man den aktuellsten Fork findet. Oder man nutzt https://techgaun.github.io/active-forks/index.html. Dort braucht man nur die Adresse des Projekts eingeben (z. B. https://github.com/libfuse/sshfs) und erhält eine Liste der Forks, die nach der Aktivität sortiert ist. Über die Schaltfläche “Add Condition” kann man die Suchabfrage noch nach seinen Wünschen anpassen.

Besser wäre es natürlich, wenn man die Liste direkt bei Github sortieren könnte. Allerdings ist in der Hinsicht Codeberg.org, was auf Gitea basiert, auch nicht besser und bietet ebenfalls nur die alphabetisch sortiere Liste an.

Artikel gemeinsam aktualisieren

Bei Arch Linux ist Python 3 schon lange der Standard. Allerdings haben diverse Pakete in den offiziellen Paketquellen immer noch Python 2 verwendet. Kürzlich haben die Entwickler von Arch Linux nun Python 2 endgültig beerdigt. Dies habe ich zum Anlass genommen die bisher von mir veröffentlichten Artikel anzusehen.

Gefunden habe ich einen Artikel für ein Script von 2016. Den Artikel konnte ich dank des Tools 2to3 sehr leicht auf Python 3 aktualisieren.

Ich gehe allerdings davon aus, dass auch noch andere von meiner Artikel, die ich seit 2009 veröffentlicht habe, nicht mehr korrekt sind, da sich zwischenzeitlich einiges geändert hat. Selbst wenn ich nun alle Artikel selbst überprüfe, wäre ich mir nicht sicher, ob ich über jede nötige Änderung Bescheid wüsste.

Nun ist es so, dass es mich selbst nervt, wenn ich über die von mir bevorzugte Suchmaschine Artikel zur Lösung eines Problems finde, die veraltet sind. Was leider oft der Fall ist.

Daher habe ich mir überlegt, ob wir Betreiber diverse Blogs uns nicht gegenseitig unterstützen könnten, indem wir beispielsweise ab und zu eine “Bug Squashing Week” ins Leben rufen während dieser wir vorhandene Artikel anderer Blogs prüfen und bei Bedarf dem Betreiber entsprechend informieren oder, sofern möglich, Pull Requests erstellen.

Was ich damit erhoffe, zu erreichen ist, dass die Suchergebnisse bei den diversen Suchmaschinen möglichst aktuell sind. Denn leider ist es so, dass einmal veröffentlichte Artikel oft nie mehr aktualisiert werden. Wie man bei den genannten Artikel von 2016 sieht, bin ich leider keine Ausnahme.

PKGBUILD-Datei bequem herunterladen um damit ein Paket zu erstellen

Ab und zu benötige ich eine PKGBUILD-Datei, um damit ein Paket für Arch Linux zu erstellen, um dieses beispielsweise auf mehreren Computern im LAN zu installieren.

Nehmen wir https://aur.archlinux.org/packages/ttf-iosevka-term als beliebiges Beispiel. Man kann beispielsweise unter genannten Link auf “View PKGBUILD” klicken und dann den angezeigten Inhalt in einer PKGBUILD-Datei lokal speichern. Alternativ kann man auch git clone –depth 1 https://aur.archlinux.org/ttf-iosevka-term.git ausführen. Dieser speichert die gewünschte Datei automatisch aber man muss den genauen Link kennen. Ich finde beide Lösungen nicht besonders gut.

Heute bin ich auf das Tool pbget gestoßen. Mit diesem muss man nur den Namen des zu erstellenden Pakets kennen. Somit reicht der Befehl pbget –aur ttf-iosevka-term aus um die gewünschte PKGBUILD-Datei herunterzuladen. Die Angabe von –aur ist in dem Fall nötig, da ttf-iosevka-term nur im AUR vorhanden ist und pbget von Haus aus nur die offiziellen Paketquellen durchsucht.

Der Befehl sollte das Verzeichnis ttf-iosevka-term anlegen und in diesem die PKBUILD-Datei speichern. Wechselt man in dieses Verzeichnis und führt makepkg -crs PKGBUILD –noconfirm aus wird das Paket erzeugt. Oder man führt makepkg -cirs PKGBUILD –noconfirm aus, um das Paket auch gleich zu installieren.

Pbget findet man übrigens im AUR.