Hier blogge ich regelmäßig über verschiedene IT-Themen, die mir bei meiner täglichen Arbeit begegnen und die mich beschäftigen. In der Regel werden Sie hier also Artikel zu C++ mit Qt, JavaScript, HTML und/oder CSS und ähnlichen Themen finden.
Ich freue mich dabei natürlich über Kommentare, Fragen und rege Beteiligung.
Daneben finden Sie hier Informationen zu meiner selbstständigen Arbeit in den Bereichen Softwareentwicklung und Netzwerkbetreuung.
Vielleicht kennst Du das Problem: Du hast unter Ubuntu oder Linux Mint ein einfaches Shell-Skript geschrieben, das nur das Verzeichnis wechseln soll. Doch beim Aufruf des Skripts merkst Du, dass das Verzeichnis in Deiner aktuellen Shell nicht gewechselt wird, obwohl der cd-Befehl im Skript steht.
In diesem Artikel erkläre ich Dir, warum das passiert und wie Du es richtig machst.
Wenn Du ein Shell-Skript normal ausführst, passiert das in einer Subshell. Das bedeutet, dass eine neue Shell-Instanz geöffnet wird, die das Skript abarbeitet. Sobald das Skript fertig ist, wird die Subshell geschlossen und Du landest wieder in Deiner ursprünglichen Shell – ohne dass Änderungen wie der Verzeichniswechsel übernommen werden.
Das ist der Grund, warum Dein cd-Befehl zwar innerhalb des Skripts funktioniert, aber nach dem Ende des Skripts Dein Verzeichnis unverändert bleibt.
Damit das Verzeichnis in Deiner aktuellen Shell geändert wird, musst Du das Skript im aktuellen Shell-Kontext ausführen. Dazu gibt es zwei einfache Möglichkeiten: den Befehl source oder den Punkt ..
Nehmen wir an, Du hast ein Skript namens wechselverzeichnis.sh, das so aussieht:
#!/bin/bash
cd /pfad/zu/deinem/verzeichnis
Anstatt es wie gewohnt so aufzurufen:
./wechselverzeichnis.shmusst Du es so aufrufen:
source wechselverzeichnis.shoder:
. wechselverzeichnis.shDurch den Aufruf mit source (oder dem Punkt .) wird das Skript nicht in einer Subshell ausgeführt, sondern direkt im Kontext Deiner aktuellen Shell. Alle Änderungen, die das Skript an der Umgebung vornimmt, wie z.B. der Verzeichniswechsel, gelten dann auch für Deine Shell-Sitzung.
Wenn Du das Skript weiter wie gewohnt ausführst, also mit ./wechselverzeichnis.sh, dann bleibt es dabei, dass es in einer Subshell läuft. Das kann für andere Arten von Skripten völlig ausreichend sein, aber für Dinge wie cd, die Änderungen an der aktuellen Umgebung vornehmen sollen, ist es nicht die richtige Methode.
Wenn Du ein Shell-Skript geschrieben hast, das in Deinem aktuellen Shell-Kontext Änderungen vornehmen soll, wie z.B. den Wechsel des Verzeichnisses mit cd, dann musst Du das Skript „sourcen“ – also mit source oder . aufrufen. Dadurch führst Du das Skript im gleichen Kontext aus, und die Änderungen gelten direkt für Deine aktuelle Shell-Sitzung.
Dein System wird langsamer, und Du hast bemerkt, dass der Arbeitsspeicher (RAM) oft ausgelastet ist? Dann könnte es Zeit sein, die Swap-Datei zu vergrößern! In diesem Artikel erkläre ich Dir Schritt für Schritt, wie Du Deine Swap-Datei anpassen kannst, um die Leistung Deines Linux-Systems zu optimieren.
Bevor wir loslegen, ein kurzer Überblick: Die Swap-Datei fungiert als eine Art Erweiterung des Arbeitsspeichers (RAM). Wenn Dein physischer RAM voll ist, speichert Linux weniger genutzte Daten auf der Festplatte, um den RAM für aktivere Prozesse freizuhalten. Dies verhindert, dass das System einfriert oder verlangsamt, wenn es zu wenig RAM gibt.
Obwohl die Nutzung der Swap-Datei das System verlangsamen kann, ist es immer noch besser, als wenn das System komplett überlastet wird. Falls Du speicherintensive Anwendungen wie Entwicklungsumgebungen, Videobearbeitung oder Virtualisierung nutzt, könnte es ratsam sein, die Größe der Swap-Datei anzupassen.
Zuerst müssen wir die aktuelle Swap-Datei deaktivieren, bevor wir sie vergrößern. Keine Sorge, Dein System wird weiterhin laufen, solange Du genügend freien RAM hast. Öffne ein Terminal und gib folgenden Befehl ein:
sudo swapoff /swapfileFalls Du möchtest, kannst Du die alte Swap-Datei löschen, um Platz zu schaffen. Nutze dafür folgenden Befehl:
sudo rm /swapfileJetzt erstellen wir eine neue Swap-Datei mit der gewünschten Größe. Nehmen wir an, Du möchtest eine 4 GB große Swap-Datei:
sudo fallocate -l 4G /swapfileFalls fallocate auf Deinem System nicht funktioniert, kannst Du auch diesen alternativen Befehl verwenden:
sudo dd if=/dev/zero of=/swapfile bs=1M count=4096Damit die Swap-Datei sicher ist, setzen wir die Berechtigungen:
sudo chmod 600 /swapfileNun formatieren wir die neue Swap-Datei, damit sie als Swap-Speicher verwendet werden kann:
sudo mkswap /swapfileJetzt aktivieren wir die neue Swap-Datei:
sudo swapon /swapfileMit folgendem Befehl kannst Du überprüfen, ob die Swap-Datei korrekt aktiviert wurde:
swapon --showDu solltest jetzt sehen, dass die neue Größe der Swap-Datei angezeigt wird.
Damit die neue Swap-Datei nach jedem Neustart automatisch aktiviert wird, müssen wir sie in der /etc/fstab-Datei eintragen. Öffne die Datei mit einem Texteditor:
sudo nano /etc/fstabFüge folgenden Eintrag hinzu, falls er nicht bereits vorhanden ist:
/swapfile none swap sw 0 0Speichere die Datei und schließe den Editor.
Für ein System mit 8 GB RAM gibt es einige Richtlinien:
Falls Dein System dennoch an die Grenzen stößt, kannst Du die Swap-Datei jederzeit vergrößern.
Mit diesen einfachen Schritten kannst Du die Swap-Datei Deines Linux-Systems anpassen und vergrößern. Eine gut konfigurierbare Swap-Datei kann Dir helfen, die Leistung zu verbessern und Dein System stabil zu halten, auch wenn Dein Arbeitsspeicher ausgelastet ist.
In der Welt der Datenbanken ist PostgreSQL für seine Zuverlässigkeit und Leistungsfähigkeit bekannt. Dennoch kann es vorkommen, dass Entwickler und Administratoren auf kryptische Fehlermeldungen stoßen, die nur begrenzt Aufschluss über die eigentliche Ursache eines Problems geben. In solchen Fällen ist es hilfreich, die Detailtiefe der Fehlermeldungen zu erhöhen. Hier kommen die Parameter log_error_verbosity und client_min_messages ins Spiel. In diesem Artikel erläutere ich, wie Du diese Parameter verwenden kannst, um umfassendere und hilfreichere Fehlermeldungen zu erhalten.
log_error_verbosityDer Parameter log_error_verbosity bestimmt, wie detailliert die Fehlerprotokolle von PostgreSQL sind. Es gibt drei mögliche Einstellungen:
log_error_verbosityUm die Detailtiefe der Fehlermeldungen zu erhöhen, kannst Du log_error_verbosity auf VERBOSE setzen. Dies kann entweder in der PostgreSQL-Konfigurationsdatei (postgresql.conf) oder direkt in einer SQL-Sitzung erfolgen.
postgresql.conf Dateipostgresql.conf Datei in einem Texteditor: sudo nano /etc/postgresql/<version>/main/postgresql.conflog_error_verbosity und setze ihn auf verbose: log_error_verbosity = verbose sudo systemctl restart postgresqlDu kannst die Einstellung auch vorübergehend in einer SQL-Sitzung ändern:
SET log_error_verbosity = 'verbose';client_min_messagesDer Parameter client_min_messages steuert, welche Meldungen an den Client gesendet werden. Die verfügbaren Stufen sind:
client_min_messagesUm sicherzustellen, dass alle relevanten Meldungen angezeigt werden, kannst Du client_min_messages auf die detaillierteste Stufe DEBUG5 setzen.
postgresql.conf Dateipostgresql.conf Datei in einem Texteditor: sudo nano /etc/postgresql/<version>/main/postgresql.confclient_min_messages und setze ihn auf debug5: client_min_messages = debug5 sudo systemctl restart postgresqlDu kannst die Einstellung auch vorübergehend in einer SQL-Sitzung ändern:
SET client_min_messages = debug5;Die Anpassung der Parameter log_error_verbosity und client_min_messages kann Dir helfen, detailliertere und nützlichere Fehlermeldungen in PostgreSQL zu erhalten. Dies erleichtert das Debuggen und die Fehlerbehebung erheblich. Denke daran, dass Änderungen an diesen Parametern die Menge der geloggten Informationen erheblich erhöhen können, was sich auf die Performance und die Größe der Logdateien auswirken kann. Verwende diese Einstellungen daher mit Bedacht und nur für die Zeit, die zur Problemlösung erforderlich ist.
SQL (Structured Query Language) ist eine mächtige Sprache für die Verwaltung und Manipulation von Datenbanken. Eine häufige Aufgabe bei der Arbeit mit Datenbanken ist das Verbinden von Tabellen, um umfassendere Datensätze zu erstellen. In SQL gibt es verschiedene Möglichkeiten, Tabellen zu verbinden, darunter INNER JOIN, LEFT JOIN, RIGHT JOIN und FULL JOIN. Ein spezieller Typ des Joins, der weniger bekannt, aber dennoch nützlich ist, ist der NATURAL JOIN.
Ein NATURAL JOIN ist eine Art von Join, der automatisch die Spalten mit denselben Namen in beiden Tabellen verknüpft. Das bedeutet, dass Sie die Spalten, die zum Verbinden der Tabellen verwendet werden, nicht explizit angeben müssen. Stattdessen übernimmt die Datenbank-Engine diese Aufgabe für Sie. Dies kann den Code kürzer und einfacher machen, insbesondere wenn viele Spalten übereinstimmen.
Die Syntax eines NATURAL JOIN ist einfach und übersichtlich. Hier ein Beispiel:
SELECT *
FROM table1
NATURAL JOIN table2;
In diesem Beispiel sucht die Datenbank-Engine automatisch nach Spalten in table1 und table2 mit denselben Namen und verknüpft diese.
NATURAL JOINs eignen sich am besten für Situationen, in denen Sie sicher sind, dass die Tabellen nur eine oder wenige Spalten mit denselben Namen haben und diese Spalten die einzigen sind, die verknüpft werden sollen. Wenn Sie jedoch komplexere Joins benötigen oder mehr Kontrolle über den Join-Prozess wünschen, sind explizite Joins wie INNER JOIN die bessere Wahl.
NATURAL JOINs sind ein nützliches Werkzeug in SQL, das den Join-Prozess vereinfachen kann, indem es automatisch Spalten mit denselben Namen verknüpft. Während sie in bestimmten Situationen sehr praktisch sein können, ist es wichtig, ihre Einschränkungen und potenziellen Fallstricke zu kennen. Verwenden Sie NATURAL JOINs mit Bedacht und stellen Sie sicher, dass sie für Ihre spezifischen Anwendungsfälle geeignet sind. Wie bei vielen Aspekten der Softwareentwicklung gibt es keine Einheitslösung, und die Wahl des richtigen Werkzeugs hängt von den spezifischen Anforderungen und Umständen Ihres Projekts ab.
In der C++ Programmierung ist es wichtig, Enum-Werte so zu definieren, dass sie über die Zeit stabile Integer-Werte behalten, besonders wenn sie in Datenbanken gespeichert werden.
Enums bieten eine bequeme Möglichkeit, benannte Konstanten zu definieren, aber ihre zugewiesenen Integer-Werte können sich ändern, wenn neue Werte hinzugefügt werden oder die Reihenfolge geändert wird. Dies kann zu Inkonsistenzen führen, wenn Enum-Werte in Datenbanken gespeichert und später interpretiert werden.
Angenommen, wir haben eine Klasse Event, die verschiedene Ereignistypen speichert:
enum class EventType {
UNKNOWN = 0,
STARTED = 1,
STOPPED = 2,
PAUSED = 3
};
class Event
{
public:
Event(EventType type = EventType::UNKNOWN)
: eventType(type)
{
// Weitere Initialisierungen können hier erfolgen
}
EventType getType() const {
return eventType;
}
void setType(EventType type) {
eventType = type;
}
int getTypeAsInt() const {
return static_cast<int>(eventType);
}
private:
EventType eventType;
};Um sicherzustellen, dass Enum-Werte über die Zeit stabil bleiben und in Datenbanken konsistent gespeichert werden können, ist es wichtig, ihnen explizite Integer-Werte zuzuweisen. Im obigen Beispiel wurden den Enum-Werten feste Integer-Werte zugewiesen (UNKNOWN = 0, STARTED = 1, usw.). Dies stellt sicher, dass sich die zugewiesenen Integer-Werte nicht ändern, wenn neue Enum-Werte hinzugefügt werden.
Die Stabilität von Enum-Werten in C++ ist entscheidend, insbesondere wenn sie persistent in Datenbanken gespeichert werden sollen. Durch das explizite Zuweisen von festen Integer-Werten zu Enum-Konstanten stellt man sicher, dass die Interpretation dieser Werte über die Zeit konsistent bleibt.
Wenn Sie Git zur Versionskontrolle verwenden und auf der Suche nach einem benutzerfreundlichen Diff- und Merge-Tool sind, ist Meld eine ausgezeichnete Wahl. In diesem Artikel erfahren Sie, wie Sie Meld installieren und nahtlos in Ihre Git-Workflows integrieren können.
Stellen Sie zunächst sicher, dass Sie Meld installiert haben. Sie können Meld von der offiziellen Website herunterladen und installieren: Meld.
Um Meld als Diff-Tool in Git zu konfigurieren, öffnen Sie eine Eingabeaufforderung (CMD, PowerShell, Terminal) und führen Sie die folgenden Befehle aus:
git config --global diff.tool meld
git config --global difftool.meld.path [Pfad-zu-Meld]Ersetzen Sie [Pfad-zu-Meld] durch den tatsächlichen Pfad zur Meld-Programmdatei. Beispielsweise könnte der Pfad unter Windows so aussehen:
git config --global difftool.meld.path "C:/Program Files (x86)/Meld/Meld.exe"Unter Linux oder macOS könnte es einfach meld sein, wenn Meld im Systempfad liegt:
git config --global difftool.meld.path meldUm Meld als Merge-Tool zu konfigurieren, führen Sie diese Befehle aus:
git config --global merge.tool meld
git config --global mergetool.meld.path [Pfad-zu-Meld]
git config --global mergetool.meld.trustExitCode trueAuch hier sollten Sie [Pfad-zu-Meld] durch den tatsächlichen Pfad zur Meld-Programmdatei ersetzen.
Um sicherzustellen, dass Git Sie nicht jedes Mal nach einer Bestätigung fragt, wenn Sie Meld verwenden, können Sie die folgenden Befehle ausführen:
git config --global difftool.prompt false
git config --global mergetool.prompt falseNachdem Sie die Konfiguration abgeschlossen haben, können Sie Meld sowohl für Diffs als auch für Merges verwenden.
Diff-Tool verwenden: Um Meld als Diff-Tool zu nutzen, verwenden Sie git difftool anstelle von git diff:
git difftool [commit1] [commit2] -- [dateiname]Wenn Sie beispielsweise die Änderungen des letzten Commits vergleichen möchten, führen Sie Folgendes aus:
git difftool HEAD~1 HEAD -- [dateiname]Merge-Tool verwenden: Bei Merge-Konflikten können Sie Meld verwenden, um diese zu lösen:
git mergetoolDurch die Integration von Meld in Ihre Git-Workflows profitieren Sie von einer benutzerfreundlichen und leistungsfähigen Umgebung zum Vergleichen und Zusammenführen von Dateien. Die oben beschriebenen Schritte sollten Ihnen helfen, Meld schnell und effektiv zu konfigurieren. Probieren Sie es aus und erleben Sie, wie Meld Ihre Arbeit mit Git noch produktiver macht.
Die in Qt eingebaute Methode zur Komprimierung von Datenströmen mit qCompress und qUncompress generiert leider keine standardkonformen Dateien, die mit externen Tools geöffnet werden können.
Ich habe daher ein kleines Tool geschrieben, das den Umgang mit diesen Dateien auf der Kommandozeile erleichtert. Die einzige Abhängigkeit besteht dabei zu Qt Core (Qt5Core.dll unter Windows). Der Quelltext steht unter GPL 3 zur freien Verfügung und kann hier runtergeladen werden:
Eine automatische, nächtliche Datensicherung für einen Ubuntu-Server ist schnell eingerichtet. Dabei werden die Daten lokal verschlüsselt und dann per SFTP verschlüsselt auf einen Strato HiDrive-Account übertragen. Dazu verwende ich das Linux-Tool Duplicity.
Zunächst richtet man ein kleines Shell-Skript ein und legt es im eigenen Home-Verzeichnis an. Mein Beispiel-Skript führt monatlich eine vollständige Datensicherung durch. Alle weiteren nächtlichen Sicherungen erfolgen dann inkrementell. Außerdem lasse ich durch Duplicity automatisch alle Sicherungen entfernen, die älter als 3 Monate sind. So muss ich mir keine Gedanken darüber machen, dass der Strato HiDrive-Speicher auf Dauer vollläuft.
#!/bin/bash export PASSPHRASE="MeineStrengGeheimePassphrase" export FTP_PASSWORD=<SFTP-Passwort von Strato> # monatliche Vollsicherung (1M) duplicity --full-if-older-than 1M /home/user sftp://share-xxxx@sftp.hidrive.strato.com/users/share-xxxx/Serversicherungen # Backups wegräumen, die älter als 3 Monate sind duplicity remove-older-than 3M --force sftp://share-xxxx@sftp.hidrive.strato.com/users/share-xxxx/Serversicherungen unset PASSPHRASE unset FTP_PASSWORD
Hier sind nur noch die markierten Stellen individuell anzupassen bzw. mit den Strato-Zugangsdaten zu füllen.
Beim ersten Aufruf muss man zunächst den SSH-Fingerabdruck des Strato-Server bestätigen. Dieser wird dabei in der .ssh/known_hosts abgelegt. Daher sollte man das Sicherungsskript einmal manuell durchlaufen lassen, bevor man die Datensicherung als Cronjob anlegt. Ist der SSH-Fingerabdruck hinterlegt, läuft das Sicherungsskript ohne weitere Nachfrage automatisch durch.
Dieses Sicherungsskript kann man nun z.B. über einen Cronjob jede Nacht um 23:00 Uhr aufrufen. Um einen solchen Cronjob anzulegen, wechselt man mit crontab -e in den Cronjob-Editor und legt folgende neue Zeile an:
0 23 * * * /home/user/backup.sh >> /home/user/logs/backup.log 2> /home/user/logs/backup.error.log
Dabei ist darauf zu achten, dass das logs-Verzeichnis bereits angelegt und schreibbar ist, da die Datensicherung sonst fehlschlägt.
Für die Wiederherstellung der so gesicherten Daten habe ich ein kleines Restore-Skript zusammengestellt, das ich im Notfall nur noch schnell anpassen muss, ohne erst zu recherchieren, wie genau eine Datenwiederherstellung mit Duplicity funktioniert.
export PASSPHRASE="MeineStrengGeheimePassphrase" export FTP_PASSWORD=<SFTP-Passwort von Strato> duplicity restore sftp://share-xxxx@sftp.hidrive.strato.com/users/share-xxxx/Serversicherungen /home/user/backup unset PASSPHRASE unset FTP_PASSWORD
Die beiden Skriptdateien sollte man dann noch mit einem chmod 700 backup.sh bzw. chmod 700 restore.sh vor den neugierigen Blicken anderer User auf dem System schützen.
Aus einer SQLite-Tabelle soll mit einem einfachen SELECT-Query ein gewichtetes Zufallsergebnis, also eine zufällig ausgewählte Zeile selektiert werden. Die in der Tabelle vorhandenen Zeilen sollen aber nicht mit der gleichen Wahrscheinlichkeit auftreten, sondern nach einem zeilenspezifischen Integer-Wert gewichtet werden.
In der Tabelle Event liegen folgende Spalten vor:
id | bezeichnung | gewichtung
Eine Zeile mit gewichtung = 2 soll also doppelt so häufig selektiert werden wie eine Zeile mit gewichtung = 1.
Eine (pseudo-)zufällig ausgewählte, dabei aber nach gewichtung gewichtete Zeile erhält man nun, unter Zuhilfenahme der kumulierten Gewichtung, durch folgende Abfrage:
SELECT t.id, t.bezeichnung, t.gewichtung FROM Event t INNER JOIN ( SELECT t.id, SUM(tt.gewichtung) AS cum_weight FROM Event t INNER JOIN Event tt ON tt.id <= t.id GROUP BY t.id ) tc ON tc.id = t.id ,( SELECT ABS(RANDOM() % SUM(gewichtung)) AS rnd FROM Event) WHERE rnd >= (cum_weight - gewichtung) AND rnd < cum_weight ORDER BY t.id ASC;
In einer Qt/C++-Application habe ich zum Erstellen von Zufallszahlen die eingebaute qrand()-Methode verwendet. Dazu hatte ich einmal beim Programmstart den Seed über die qsrand()-Methode initialisiert:
QTime time = QTime::currentTime(); qsrand((uint)time.msec());
Nach kurzer Zeit ist mir aufgefallen, dass die so generierten Zufallszahlen nur scheinbar zufällig sind. Ein großes Problem war insbesondere, dass alle Zahlen, die in der gleichen Millisekunde generiert wurden, gleich waren. Das war in meiner Anwendung häufig der Fall, weil ich zum Teil in einer Schleife (nahezu) gleichzeitig sehr viele Zufallszahlen generieren musste.
Schließlich bin ich beim C++-Standardheader <random> gelandet, der eine ganze Reihe unterschiedlicher Zufallsgeneratoren zur Verfügung stellt. Unter anderem steht mit dem Generator random_device ein Non-deterministic true random number generator bereit, den ich in meiner Applikation wie folgt implementiert habe:
std::random_device generator; std::uniform_int_distribution<int> distribution(low, high); int result = distribution(generator); return result;
Ein schneller Test hat ergeben, dass die so generierten Zufallszahlen tatsächlich nicht nur bei jedem Programmstart unterschiedlich sind, sondern sich auch bei der Massengenerierung in einer Schleife immer unterscheiden.
Eine gute Quelle für die Möglichkeiten des <random>-Headers habe ich hier gefunden: