Umbenennen mit dem Lieblingseditor

Dateien umbenennen ist oft mühsam.
Wenn man ein Extra-Werkzeug benutzt, muss man es erst lernen.
Das schreiben eines extra Skriptes kann aber oft zu aufwendig sein.
Es wäre doch schön, wenn man direkt im Lieblingseditor die Dateinamen verändern könnte.

Hier kommt die Werkzeugsammlung renameutils zum Einsatz.

Installation


Installiert wird das ganze aus den üblichen Paketmanagern, also z.B.

brew install renameutils # macOS / Linuxbrew
pacman-S renameutils # Arch based
sudo apt install renameutils # Debian based

Benutzung

Nun gibt es die Befehle: qmv und qcp, mit denen Dateien umbenannt, bzw. kopiert werden können.

Beispiel:

ls *.txt

Ausgabe:

Kopie von hallo.txt
Kopie von gutentag.txt
Kopie von abrechnung.txt

Nun verwenden wir unser neues Werkzeug:

qmv *.txt

Nun öffnet sich unser eingestellter Editor mit einer Dateiliste und wir können die Datei-Umbenennungen direkt im Editor vornehmen.

Fazit

Das Verwenden von Shell-Kommandos zum Umbennen ist oft schnell.
So geht das Umbenennen aller .txt Dateien in .md schnell von der Hand.

Für komplexe Fälle können wir qmv verwenden. Damit können wir unseren vertrauten Editor und alle darin vorhandenen Funktionen nutzen.
Insbesondere, wenn wir keine einfachen Regeln zum Umbenennen formulieren können, helfen uns die renameutils hier stark weiter.

So ist bei mir der Alias

alias ren=qmv --format=destination-only

fest in meine Werkzeugkiste eingezogen.

ip statt ifconfig unter macOS

Viele moderne Linux Distributionen bieten mit iproute2 eine einfache Möglichkeit Netzwerkkonfiguration durchzuführen.

So zeigt z.B.

ip a s

die IP Adresse der Netzwerkschnittstellen an.

MacOS bietet dieses Tool aber nicht an. Also müssen wir auf ifconfig ausweichen. Blöd, wenn wir zwischen den Systemen wechseln und immer umdenken müssen.

Installieren wir mit der Hilfe von Homebrew ein kleines Hilfsscript:

brew install iproute2mac

Nun können wir auch mit

ip a s

die konfiguierten Netzwerkgeräte anzeigen. Wunderbar!

yay mit archarm nutzen

Viele Entwickler schätzen es aktuelle Werkzeuge zu nutzen.
Ob Compiler, Editor oder Shell - neue Versionen haben neue Features, bereinigte Bugs und mehr.

Daher ist in den letzten Jahren die Linux Distribution "Arch" auch sehr beliebt geworden: Rolling Releases statt großer Versionssprünge erleichtern den Entwickleralltag.
Auch auf dem Raspberry Pi läuft diese Distribution.

Aus der Community getrieben Pakete können aus dem AUR mit einem beliebigen Tool installiert werden.
Derzeit verwende ich dafür gerne yay.

Um yay auf dem Raspberry Pi zu installieren, sind folgende Schritte notwendig:

# Notwendige Pakete installieren
sudo pacman -S git go make binutils gcc fakeroot

# yay via git clonen und installieren
git clone https://aur.archlinux.org/yay.git
cd yay
makepkg -si

Dann steht der Installation von Paketen aus dem AUR nichts mehr im Wege.

Simples deployment via git

Das Problem

Egal ob Homepage, Konfigurationsdateien oder Programmcode: Für praktisch alle Projekte verwendet man heute git.

Möchte man jedoch Versionen automatisch ausrollen (z.B. statische HTML Dateien einer Webseite), benötigt man einige Skripte oder einen Build-Dienst wie z.B. Gitlab-CI, Jenkins oder CircleCI.

Oftmals reicht es jedoch die Daten auf das Zielsystem zu kopieren. Aber auch das geht mit git:

Verteilen von Paketen

Ausgangssituation

Wie haben einen Server (für die Homepage), einen Laptop (für die Entwicklungsarbeit), sowie ein Git-Projekt (z.B. bei Github).
Auf Github befindet sich unser Projekt.
Auf Laptop wie auch auf dem Server haben wir uns mit git clone das Projekt eingerichtet.

Vorgehen

Das Projekt auf dem Server soll beim Empfangen neuer Dateien diese auch in das "Working Directory" schreiben. Dies aktivieren wir mit :

# auf Server, im Projektverzeichnis
git config receive.denyCurrentBranch updateInstead

Nun müssen wir unserem Projekt auf dem Laptop das neue Ziel beibringen:

# auf Laptop, im Projektverzeichnis
git remote add deploy benutzer@servername:/pfad/zu/projektordner/auf/server
# jetzt noch sagen: schiebe den lokalen branch _master_ auf den server (nur 1 mal notwendig)
git push --set-upstream deploy master

Unsere Änderungen können wir weiterhin zu Github schieben:

git push origin

Aber nun auch neu: Auf dem Server direkt ausrollen:

git push deploy

Es ist sogar möglich mittels push-url mehrere Ziele auf einmal zu definieren.

Fazit

Natürlich ersetzt unser kleiner Workflow keinen Build-Server oder ausgetüftelte Deployment Prozesse. Aber für Kleinst-Projekte kann das vorgehen mit updateInstead sehr praktisch sein.

Aber Achtung: Verwenden wir diese Möglichkeit um Webseiten zu versionieren: Nicht vergessen, den .git Ordner nicht auszuliefern.

Geräte unter eigenem Namen: udev rules

Das Problem

Unter Linux wird jedem verbundenen Gerät ein Pfad zugeordnet.
So erscheint z.B. ein verbundener Esp8266 Microcontroller als (serielle) Schnittstelle /dev/ttyUSB0.
Sind noch mehr Geräte verbunden, so erscheinen diese als /dev/ttyUSB1, /dev/ttyUSB2 usw.

Welches Gerät ist aber nun welche Schnittstelle? Und sind diese nach dem Reboot noch gleich?
Rules

Die Lösung: udev rules

Um dies sicher zu stellen erstellt man eine Regel mit udev:

Zunächst identifizieren wir, welches Gerät wir haben wollen. Als Beispiel nutzen wir hier einen Microcontroller, der unter /dev/ttyUSB0 eingehängt ist.

udevadm info --name=/dev/ttyUSB0 --attribute-walk

Aus der Ausgabe von udevadm suchen wir uns einige Werte heraus: Die von ATTRS{idVendor}, ATTRS{idProduct} und ATTRS{serial}.
Dies sollte zum eindeutigen Identifizieren des Gerätes ausreichen.

Nun legen wir uns eine Regel-Datei an:

Eine neu erstellte /etc/udev/rules.d/20-mydevice.rules füllen wir nun mit den gesammelten Informationen. Natürlich müssen hier echte Werte eingesetzt werden:

SUBSYSTEM=="tty", ATTRS{idVendor}=="1234", ATTRS{idProduct}=="abcd", ATTRS{serial}=="01010101010101010101010101010", SYMLINK+="ttyUSB_mydevice"

Nun noch die neuen Regeln anlegen:

sudo udevadm trigger

und den udev Dienst neu starten:

sudo systemctl restart udev

Nun sollte unsere Regel angewendet werden und ein neuer Eintrag /dev/ttyUSB_mydevice angelegt sein. Dieser ist ein Link auf das "echte" Gerät. Somit können wir uns immer auf den selbstgewählten Namen verlassen - auch wenn sich der automatisch Vergebene Name nach einem Neustart ändern kann.

Dateien finden mit fd

Das Tool find ist ein praktisches Programm und Dateien und Ordner zu finden.
Find kann aber auch komplexere Aktionen wie z.B. mehrere Dateien konvertieren. Leider ist es jedoch nicht allzu einsteigerfreundlich.

Hier kommt fd ins Spiel:

Das Open-Source Programm erledigt nahezu alle Aufgaben von find, ist aber einfacher zu bedienen.

LPs

Beispiel1

Finde alle Dateien mit der Zeichenfolge schuh im Namen:

find:

find . -iname '*schuh*'

fd:

fd schuh

Beispiel 2

Finde alle .jpg Dateien:

find:

find . -iname '*.jpg'

fd:

fd -e jpg

Beispiel 3

Finde alle .png Dateien und konvertiere diese in .jpg Dateien:

find:

find ./ -name '*.png' -exec bash -c 'convert $0 ${0/png/jpg}' {} \;
# Konvertiert eine nach der anderen Datei

fd:

fd -e png -x convert {} {.}.jpg
# Konvertiert parallel mehrere Dateien auf einmal

Fazit:

Wer find in- und auswendig beherrscht hat keinen Zwang zu wechseln. Der bequeme Syntax von fd macht das Leben jedoch leichter. Die Möglichkeit parallel mehrere Dateien zu verarbeiten ist ungemein praktisch. Daher ist fd für jeden Kommandozeilen-Fan absolut empfehlenswert.

Docker services via docker-compose und systemd template

Docker ist das derzeit omnipresente Werkzeug um Dienste in Containern auszuführen.

Wie kann man jedoch einen logischen Verbund an Diensten mit dem System zusammen starten?

Container

Mit der Hilfe von Docker können Anforderungen eines Dienstes (z.B. Gitlab) an die Distribution innerhalb eines Containers befriedigt werden. Das ausführende System aussenherum bleibt davon unberührt und kann auch eine inkompatible Distribution sein.

In der Praxis werden jedoch oft mehrere Dienste in einem Verbund benötigt. Diese können mit dem Tool docker-compose beschrieben und gestartet werden.

Will man nun Dienste via docker-compose mit dem System zusammen starten, bietet sich folgende Vorgehensweise an:

Als erstes definieren wir ein Dienst-Template in einer neuen Datei /etc/systemd/system/dc@.service

[Unit]
Description=%i service with docker compose
Requires=docker.service
After=docker.service

[Service]
Restart=always
TimeoutStartSec=1200

WorkingDirectory=/opt/dockerfiles/%i

# Remove old containers, images and volumes and update it
ExecStartPre=/usr/local/bin/docker-compose down -v
ExecStartPre=/usr/local/bin/docker-compose rm -fv
ExecStartPre=/usr/local/bin/docker-compose pull

# Compose up
ExecStart=/usr/local/bin/docker-compose up

# Compose down, remove containers and volumes
ExecStop=/usr/local/bin/docker-compose down -v

[Install]
WantedBy=multi-user.target
ExecStartPre=/usr/local/bin/docker-compose pull

# Compose up
ExecStart=/usr/local/bin/docker-compose up

# Compose down, remove containers and volumes
ExecStop=/usr/local/bin/docker-compose down -v

[Install]
WantedBy=multi-user.target

Wir gehen dabei davon aus, dass alle docker-compose Konfigurationsdateien in /opt/dockerfile/DIENSTNAME liegen und sich docker-compose im Verzeichnis /usr/local/bin liegt.

Nun legen wir unsere docker-compose.yml Datei z.B. in /opt/dockerfile/gitlab/docker-compose.yml ab.

Nun weisen wir systemd an, das Template zu instanziieren:

sudo systemctl enable dc@gitlab

Ab sofort ist der Dienst vorhanden und kann auch direkt gestartet werden:

sudo systemctl start dc@gitlab

Beim starten des Dienstes wird auch das Image aktualisiert - ist dies nicht gewünscht, muss lediglich die entsprechende Zeile im Template entfernt werden.

Viel Spaß!

Python auf dem ESP8266

Der ESP8266 ist ein kleiner Mikrocontroller, den es für kleines Geld in verschiedenen Ausführungen und von verschiedensten Herstellern gibt.
Das kleine 32-Bit Board besticht neben einfacher Zugänglichkeit, niedrigem Preis und einem on-board WLAN Modul.

Für viele Zwecke lohnt sich ein Blick auf Micropython als Alternative zu "klassischer" Arduino C++ Entwicklung für das kleine Wunderwerk.

ESP8266 Microcontroller

Diese auf Python 3 basierende, spezialisierte Version von Python bringt vieles mit, was man sich auf einer Entwicklungsplattform wünscht: