Der Weg zum Fullstackdeveloper

Erste Schritte zur lokalen Entwicklungsumgebung

🧱 Eine saubere Basis: Struktur, Bash und eigene Skripte

Beim Einrichten einer neuen Linux-Umgebung geht es nicht nur darum, Tools zu installieren, sondern vor allem darum, Ordnung und Wiederverwendbarkeit zu schaffen. Besonders dann, wenn ich ein Linuxsystem wieder neu aufsetzen möchte. Meine Motivation ist es, von einem Setup mit Windows 10 nahezu komplett auf Linux umzusteigen. Es kommt aber auch bald der Release Ubuntu 26.04 und dann werde ich auf das aktuellste Ubuntu wechseln. Dann habe ich ja noch meinen Laptop mit Win 11 in der WSL etwas besser funktioniert. Dann möchte ich auch mal Ferdora, CachyOS oder andere Distributionen testen. Dafür habe ich zwei Partitionen für zwei Distributionen parallel auf meinem Desktop-PC und eine Partition für meine Daten. Somit sind einige Skripte etwas angepasst oder obsolet. Deswegen verwalte ich meine Skripte in verschiedenen Branches.

Bevor ich Node, PHP oder Docker installiere, kümmere ich mich zuerst um drei Dinge:

  • eine klare Verzeichnisstruktur
  • meine Shell-Konfiguration (.bashrc)
  • und eigene Hilfsskripte

Diese bilden die Grundlage für alles Weitere.

📁 1. Struktur: Skripte versionieren statt verteilen

Ich verwalte meine Skripte nicht direkt im System, sondern in einem eigenen Git-Repository (hraesvelgr ist übrigens ein Drache aus dem Spiel Final Fantasy XIV):

~/hraesvelgr/        # Git-Repository
└── etc/             # alle eigenen Konfigurationen wie bspw.Apache2
└── scripts/         # alle eigenen Skripte

👉 Idee dahinter:

  • Skripte und Konfigurationen sind versioniert (Git)
  • ich kann sie auf andere Systeme übertragen
  • keine „verstreuten“ Dateien im System

🔗 Zugriff über ~/bin

Statt Skripte direkt aus dem Repository aufzurufen, verlinke ich sie:

ln -s ~/hraesvelgr/scripts/create_database.sh ~/bin/createDatabase

Damit kann ich sie überall nutzen:

createDatabase

⚙️ PATH erweitern

uDamit das funktioniert, wird ~/bin in den PATH aufgenommen:
export PATH="$HOME/bin:$PATH"

👉 Wichtig:

Ich verlinke keine Skripte direkt in der .bashrc, sondern halte die Kontrolle vollständig über das bin/-Verzeichnis.

🧠 2. Warum dieses Setup sinnvoll ist

Dieses Konzept hat mehrere Vorteile:

  • klare Trennung zwischen Code und System
  • einfache Migration auf neue Rechner
  • volle Kontrolle über verfügbare Commands
  • keine Seiteneffekte durch Shell-Konfiguration

⚙️ 3. .bashrc – minimal, aber gezielt

Die .bashrc sollte nicht überladen sein. Ich nutze sie nur für:

  • PATH-Erweiterungen
  • Tool-Initialisierung (z. B. Node)
  • Prompt-Anpassung

📦 Beispiel: Node über nvm

export NVM_DIR="$HOME/.nvm"if [ -s "$NVM_DIR/nvm.sh" ]; then
    . "$NVM_DIR/nvm.sh"
fiif [ -s "$NVM_DIR/bash_completion" ]; then
    . "$NVM_DIR/bash_completion"
fi

👉 Vorteil:

Node wird im Benutzerkontext installiert und benötigt kein sudo. Das ist tatsächlich gängige Praxis auf Linux und man bekommte eine Warnung, wenn man node als sudo ausführt. Auf Windows und Mac ist das nicht nötig.

🔌 Optional: externe Skripte laden

Beispiel:

[ -f "$HOME/hraesvelgr/scripts/wp-completion.bash" ] && source "$HOME/hraesvelgr/scripts/wp-completion.bash"

👉 Wichtig:

  • keine festen Pfade wie /home/user/...
  • immer $HOME verwenden

🎨 4. Ein sinnvoller Bash-Prompt

Ein guter Prompt zeigt direkt:

  • Benutzer & Host
  • aktuelles Verzeichnis
  • Git-Branch

Ich habe auch mal andere Varianten versucht mit nur dem aktuellen Verzeichnis oder komplett leeres Prompt, aber das fühlt sich ungewöhnlich an. Auf dem Server könnte ich nicht darauf verzichten, da muss ich sehen, welcher Nutzer ich gerade bin und wo ich bin. Ein Prompt ist übrigens:

root@servername:/etc/apache2/sites-available$

Git-Integration aktivieren

source /usr/lib/git-core/git-sh-prompt

Farbiger Prompt mit Branch

color_prompt=yesif [ "$color_prompt" = yes ]; then
    PS1='${debian_chroot:+($debian_chroot)}\
\[\033[01;32m\]\u@\h\[\033[00m\]:\
\[\033[01;34m\]\w\[\033[00m\]\
$(__git_ps1 " (%s)")\$ '
else
    PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w$(__git_ps1 " (%s)")\$ '
fi

⚠️ Typischer Fehler

Ein Problem, das häufig auftritt:

Der Prompt funktioniert nicht, obwohl er korrekt definiert ist.

Die Ursache ist meist:

PS1='...'

👉 wird weiter unten erneut gesetzt und überschreibt alles.

🔍 Debugging

grep -n PS1 ~/.bashrc

👉 Die letzte Zuweisung gewinnt immer.

Ich hatte nämlich etwas experimentiert und vergessen, dass ich weiter unten diese Variable überschrieben habe. Da war etwas Debugging nötig, um das zu entdecken. Ich habe da ein paar Echo-Befehle in den If-Block gesetzt, wunderte mich, dass die Bedingung in der Abfrage erfüllt war, aber am Ende das Ergebnis anders aussah. Letztendlich entdeckte ich, dass der Prompt einige Zeilen unter dem If-Block überschrieben wurde. Das passiert tatsächlich häufiger als man denkt, deswegen benutzt man bei modernen Programmiersprachen, dass man eine Variable nicht überschreiben kann, wenn man nicht explizit möchte, dass sie überschrieben wird. Das wäre bei JavaScript:

const BASE_PATH = "/home/user/bin"  // feste Grundlage
let currentBranch = "main"          // ändert sich je nach Kontext

oder

const MAX_RETRIES = 3        // feste Grenze
let attempt = 0              // zählt hoch

🛠️ 5. Eigene Helper-Skripte

Ein paar kleine Skripte sparen im Alltag enorm Zeit.

🔄 System aktualisieren

#!/bin/bash
sudo apt update && sudo apt upgrade -y

Damit könnte man sein System mit einem Kommando aktualisieren oder sogar einem Cron-Job zuweisen. Ich sehe aber gerne, welche Pakete ein Update erhalten. Deswegen teile ich das auf zwei Kommandos auf:

# update.sh
sudo apt update && apt list --upgradable
# upgrade.sh
sudo apt upgrade -y

Und sollte es keine Updates geben, spare ich mir upgrade.sh

🔁 Nur Upgrade

#!/bin/bash
sudo apt upgrade -y

💡 Beispiel: Boot-Manager nutzen

sudo efibootmgr -n 1 && sudo reboot

👉 Damit kann ich einmalig ein anderes Betriebssystem starten, ohne die Boot-Reihenfolge dauerhaft zu ändern.

Kurz zur Erklärung: eifbootmgr allein zeigt mir die Einträge der UEFI-Booteinträge, die Boot-Reihenfolge und welcher als Nächstes gestartet wird. Mit dem Tag und der Nummer -n 1 setze ich den nächsten Boot auf den Eintrag mit der Boot0001. Und das ist bei mir Windows. Ubuntu hat Ubuntu hat Boot0000. Den Bootxxx* kann man weglassen und die letzte Ziffer angeben

🔐 6. Dateirechte bewusst setzen

Skripte müssen ausführbar sein:

chmod u+x script.sh

Alternativ:

chmod 755 script.sh

👉 Empfehlung:

Statt pauschal Rechte zu setzen, ist es oft sinnvoll, gezielt nur das Execute-Bit (u+x) zu ergänzen.

🧠 Fazit

Eine saubere Entwicklungsumgebung beginnt nicht mit Frameworks, sondern mit Struktur:

  • Skripte gehören in ein Repository
  • ausführbare Befehle in ~/bin
  • .bashrc bleibt übersichtlich
  • der Prompt liefert relevante Informationen

Diese Basis sorgt dafür, dass sich das System leicht erweitern, debuggen und reproduzieren lässt.