Vielen Dank an Claudia für die Idee zu diesem Artikel.
Wenn ihr mit dem Titel dieses Beitrags nicht viel anfangen könnt, seid ihr hier genau richtig. Viele unserer Leser:innen sind Linux-Nerds und haben mit den Begriffen Linter und Shell-Skript keine Probleme. Doch es gibt auch Einsteiger, Umsteigerinnen und Neue, denen diese Begriffe nichts sagen. Deshalb erfolgt zunächst eine kurze Erklärung.
Alle haben schon einmal von der berüchtigten Kommandozeile (Terminal, Shell) in Linux gehört und sich davor gefürchtet. Seit Jahren wird der Mythos verbreitet, dass man Linux nicht ohne die Kommandozeile bedienen kann. Das stimmt seit vielen Jahren nicht mehr. Wer eine GNU/Linux-Distribution verwenden möchte, kommt mit der Kommandozeile nie in Berührung. Das ist schade, weil das Terminal kein Muss, sondern ein Darf ist. Wer sich einmal darauf eingelassen hat, wird eine Produktivitätssteigerung über die Zeit bemerken. Das Terminal ist ein Geschenk, das entdeckt werden möchte.
In einem Terminal kann man nicht nur Befehle eingeben, die über grafische Anwendungen viel komplizierter sind und länger dauern, man kann im Terminal auch programmieren, um Arbeitsabläufe zu automatisieren. Diese kleinen Helfer-Programme heissen Shell-Skripte. Man schreibt sie in eine Textdatei, z. B. mache_die_und_das.sh. Diese Datei kann man im Terminal, als Autostart-Datei oder aus der grafischen Benutzeroberfläche ausführen.
Ein Linter ist ein Programm, mit dem man statischen Code auf Syntaxfehler, stilistische Schwächen und die Missachtung von Programmierstandards überprüfen kann. Beim normalen Programmierzyklus ist der Einsatz eines Linters ein üblicher Schritt in der Werkzeugkette. Häufig verwendete Linter bei der Python-Programmierung sind Pylint, Flake8, oder Ruff. Ich verwende gerne Ruff, weil dieser Linter sehr schnell und genau ist.
Doch wie sieht es mit der Überprüfung von Shell-Skripten aus? Da solche gerne von Einsteigern geschrieben, aus dem Internet heruntergeladen, oder von KIs generiert werden, empfiehlt sich die Überprüfung durch einen Linter ganz besonders. Für Shell-Skripte bietet sich der Linter ShellCheck an. Diesen gibt es als native Anwendung oder als Service im Internet. Für Gelegenheitsnutzer genügt die Online-Variante. Wer des Öfteren Shell-Skripte auf Korrektheit überprüfen möchte, ist mit der nativen Anwendung besser bedient. Bei der nativen Installation ist zu beachten, dass der ganze Haskell-Rattenschwanz mitinstalliert wird. Daher rate ich zum Ausprobieren zur Online-Variante. Die Bedienung ist einfach: Ihr kopiert euer Skript und fügt es hier ein. Die Code-Analyse erfolgt ohne weiteres Zutun.
Hier ist ein Beispiel aus meinem Shell-Skript-Bestand. Selbst in sehr einfachen Skripten finden sich Fehler:
Im oberen Teil seht ihr ein triviales Skript, welches in ein Verzeichnis wechselt und dort ein Python-Skript startet.
Hier ist ein weiteres Beispiel:
Hierbei handelt es sich um ein Skript, mit dem man anzeigen kann, in welchem Paketformat ein Programm installiert wurde. Dazu gibt es einen Artikel bei uns.
Als letztes Beispiel dient ein Code, den ich letzte Woche mit einer KI generiert habe. Auch dazu gibt es einen Artikel, den Claudia kommentiert hat und der diesen Beitrag ausgelöst hat:
Hier wird eine Warnung ausgegeben. Die Variable OLLAMA_PID wird initialisiert, aber im Skript nicht verwendet. ShellCheck gibt den Tipp, diese Variable zu exportieren, damit man diese ausserhalb des Skripts verwenden kann.
Fällt euch etwas auf? Mein Code enthält mehr Fehler als der KI-generierte. Das soll keine Aufforderung sein, die Code-Erzeugung an die KI abzugeben. Im Gegenteil: Wer Code schreiben möchte, sei es Shell-Skripte, Python oder etwas anderes, soll es lernen, verstehen und pflegen können. Dabei kann KI als Hilfsmittel dienen, darf aber nie der unreflektierte Urheber sein. Linter sind tolle Werkzeuge, um euren eigenen Code, oder fremden Code zumindest syntaktisch zu überprüfen.
Titelbild: https://pixabay.com/illustrations/hook-check-mark-yes-consent-done-881440/
Quellen:
Python-Linter Ruff: https://docs.astral.sh/ruff/linter/
ShellCheck: https://www.shellcheck.net/




Obacht, wer jetzt meint, bei unbekannten, heruntergeladenen Skripten einfach ShellCheck laufen zu lassen und den Ausgaben zu vertrauen, der irrt. Warnung oder Fehler lassen sich mit solchen Kommentarzeilen vor der jeweiligen Stelle unterdrücken:
Beispiel: # shellcheck disable=SC1091 unterdrückt die Fehlermeldung/Warnung "Can't follow non-constant source. Use a directive to specify location"
Wenn das möglich ist, dann einfach sämtliche Kommentare vorher entfernen und dann shellcheck laufen lassen. Somit hat man deine Bedenken aus den Weg geräumt. Ganz einfach mit
cat ZuPrüfendesSkript.sh | sed -e 's/^#[^!].*//g' | shellcheck, falls es lokal installiert ist, anosnten auch ganz coolcat ZuPrüfendesSkript.sh | sed -e 's/^#[^!].*//g' | xsel --input --clipboardsomit hat man es im zwischen Speicher (Clipboard) und kann es auf der Internetseite überprüfen lassen.Jetzt noch die Erklärung für den sed - command:
Und kombiniert lautet dann der Sachverhalt: Starte mit einem Tag, aber darauf soll kein Ausrufezeichen folgen
Hinweis: Das Tool xsel muss vorher installiert werden, weil es ist bei den meisten Distro's nicht vorinstalliert.
Ja, ist ein wirklich cooles Tool und Projekt!
Habe ich selbst auch vor rund zwei Wochen kennengelernt, als ich ein Plugin für VSCodium gesucht habe, welches bei Bash-Skripten unterstützt.
Dazu dann hier direkt die Empfehlung für "Bash IDE" von Mads Hartmann. Das Plugin bindet unter anderem shellcheck ein und macht Probleme direkt im Editor und in der separaten "Problems" View sichtbar - und bringt Skript-Funktionen und Variablen anklickbar in die "Outline"-View.