$ fondamentaux bash
Comprendre Bash
de zéro à ta stack
Un cours pratique orienté ton environnement réel : VPS Hostinger, Docker, Coolify, n8n, Supabase — et les agents LLM.
Bash est un interpréteur de commandes — un programme qui lit des instructions en texte et les exécute sur le système d'exploitation Linux. Quand tu ouvres un terminal et tu tapes quelque chose, c'est bash qui lit, comprend et exécute.
Le nom signifie Bourne Again SHell — une réécriture du shell original Unix des années 70. Il est présent sur absolument tous les serveurs Linux sans aucune installation requise. C'est pourquoi tous les guides, scripts d'installation, Docker, Coolify, et les agents LLM s'appuient dessus.
Analogie simple : Bash est au serveur Linux ce que le terminal Windows est à Windows — mais beaucoup plus puissant, universel, et scriptable.
Sur ton PC portable sous macOS ou Linux, c'est bash (ou zsh, son cousin direct) que tu utilises dans le terminal. Sur ton VPS Hostinger, c'est bash que tu pilotes via SSH. Même commandes, même logique, partout.
Voici comment bash s'insère concrètement dans ton environnement MultiBrasServices :
Toi (SSH) ──→ Bash (shell) ──→ Linux kernel
↑ tu tapes ici ↑ traduit ↑ exécute vraiment
Bash ──→ Docker ──→ Coolify / n8n / Supabase
commandes docker tes conteneurs tournent ici
Claude (LLM) ──→ bash_tool ──→ Bash ──→ Linux
↑ outil connecté ↑ même shell, même puissance
Bash n'est pas "à côté" de Docker ou Coolify — il est en dessous. Quand Coolify installe un service, il exécute des commandes bash. Quand un agent LLM agit sur une machine, il passe par bash. La boîte noire devient transparente dès que tu comprends le shell.
Clé de compréhension : Quand Claude utilise bash_tool dans cette conversation, il fait exactement ce que tu ferais en tapant dans ton terminal SSH. Même niveau d'accès, même commandes.
Avant de taper quoi que ce soit, il faut savoir lire ce qu'on voit dans un terminal. Chaque partie a un sens précis.
Le prompt — ce qui s'affiche avant ta commande
ulrich@vps:~$ ma-commande
# ↑↑↑↑↑↑ ↑ ↑↑↑ ↑ ↑ ↑
# user @ host : ~ $
# ulrich → l'utilisateur connecté
# @vps → le nom de la machine (ton VPS Hostinger)
# :~ → le dossier courant (~ = ton home /home/ulrich)
# $ → tu es un utilisateur normal (# = tu es root/admin)
# Exemples de prompts selon où tu es :
ulrich@vps:~$ ← dans /home/ulrich
ulrich@vps:/opt/coolify$ ← dans /opt/coolify
root@vps:/# ← connecté en root, à la racine du système
La structure d'une commande
$ docker logs -f --tail 100 n8n
# ↑ ↑ ↑ ↑ ↑
# commande sous- option option longue argument
# cmd courte avec valeur (nom du conteneur)
# Options courtes : -f -r -la -n 50
# Options longues : --follow --recursive --tail=100
# On peut souvent combiner : -la = -l + -a
# Exemples réels :
$ ls -la /opt/coolify ← commande + options + argument
$ tail -f -n 50 app.log ← 2 options + argument
$ docker ps ← commande + sous-commande, pas d'argument
Les chemins : absolu vs relatif
# Chemin ABSOLU — commence toujours par /
# Même résultat peu importe où tu es
$ cd /opt/coolify ← va dans /opt/coolify depuis n'importe où
$ cat /home/ulrich/.env
# Chemin RELATIF — part de là où tu es actuellement
ulrich@vps:/opt$ cd coolify ← = cd /opt/coolify
ulrich@vps:/opt$ cd ../home ← remonte d'un niveau, va dans home
ulrich@vps:/opt$ ./script.sh ← exécute script.sh dans le dossier courant
Les caractères spéciaux
| Caractère | Signification |
|---|
| ~ | Ton dossier home (/home/ulrich). cd ~ te ramène toujours chez toi. |
| . | Le dossier courant. ./script.sh = exécute dans le dossier où tu es. |
| .. | Le dossier parent. cd .. remonte d'un niveau. |
| * | Wildcard — correspond à n'importe quoi. *.log = tous les fichiers .log. |
| $ | Préfixe d'une variable. $NOM = valeur de la variable NOM. |
| # | Commentaire dans un script. Tout ce qui suit est ignoré par bash. |
| / | Séparateur de chemin ET racine du système (/ seul = la racine absolue). |
| - | Préfixe d'une option courte (-f), ou chemin spécial : cd - retourne au dossier précédent. |
Le code de retour — bash sait si ça a marché
# Après chaque commande, bash stocke un code dans $?
# 0 = succès | tout autre nombre = erreur
$ docker ps
CONTAINER ID IMAGE ...
$ echo $?
0 ← succès
$ cat fichier-inexistant.txt
cat: fichier-inexistant.txt: No such file or directory
$ echo $?
1 ← erreur
# C'est pour ça que && fonctionne :
apt update && apt upgrade ← upgrade seulement si update renvoie 0
À retenir : Le prompt te dit qui tu es, où tu es et avec quels droits. Avant de taper une commande destructive, lis ton prompt — deux secondes qui évitent de supprimer le mauvais dossier.
Les commandes de base pour te déplacer et manipuler des fichiers. À maîtriser absolument — tu les utiliseras tous les jours sur ton VPS.
| Commande | Description |
|---|
| pwd | Affiche le dossier où tu es (Print Working Directory) |
| ls | Liste le contenu du dossier courant |
| ls -la | Liste détaillée avec fichiers cachés, tailles, droits |
| cd /chemin | Va dans un dossier (chemin absolu) |
| cd .. | Remonte d'un niveau |
| cd ~ | Va dans ton dossier personnel (home) |
| mkdir mon-dossier | Crée un dossier |
| mkdir -p a/b/c | Crée plusieurs niveaux de dossiers d'un coup |
| cp fichier copie | Copie un fichier |
| cp -r dossier/ dest/ | Copie un dossier entier (récursif) |
| mv ancien nouveau | Renomme ou déplace un fichier/dossier |
| touch fichier.txt | Crée un fichier vide |
# Où suis-je ?
ulrich@vps:~$ pwd
/home/ulrich
# Lister les dossiers Coolify
ulrich@vps:~$ ls -la /opt/coolify
drwxr-xr-x coolify/
drwxr-xr-x n8n/
-rw-r--r-- docker-compose.yml
# Créer la structure d'un projet
ulrich@vps:~$ mkdir -p projets/zoomali/backup
ulrich@vps:~$ cd projets/zoomali && touch .env
Indispensable pour inspecter des logs, des configs, des fichiers .env sur ton VPS sans ouvrir un éditeur graphique.
| Commande | Description |
|---|
| cat fichier | Affiche le contenu entier d'un fichier |
| less fichier | Lecture paginée (q pour quitter, / pour chercher) |
| head -n 20 fichier | Affiche les 20 premières lignes |
| tail -n 50 fichier | Affiche les 50 dernières lignes |
| tail -f fichier | Suit le fichier en temps réel — parfait pour les logs live |
| grep "mot" fichier | Cherche "mot" dans un fichier |
| grep -r "mot" dossier/ | Cherche récursivement dans tous les fichiers |
| find / -name "*.env" | Trouve tous les fichiers .env sur le système |
# Voir les logs de n8n en direct (Ctrl+C pour arrêter)
ulrich@vps:~$ docker logs -f n8n
[2026-05-11] INFO Workflow executed successfully
[2026-05-11] INFO Webhook received...
# Chercher une erreur dans les logs Coolify
ulrich@vps:~$ grep -r "ERROR" /var/log/coolify/
app.log: ERROR Connection refused on port 5432
# Inspecter un .env sans éditeur
ulrich@vps:~$ cat /opt/n8n/.env
N8N_PORT=5678
DB_TYPE=postgresdb
Astuce VPS : tail -f est ta meilleure arme pour déboguer. Lance-le sur les logs d'un service pendant que tu testes — les erreurs apparaissent en direct.
Comprendre ce qui tourne sur ta machine. Crucial quand un port est occupé, qu'un service ne répond plus, ou que la RAM est pleine.
| Commande | Description |
|---|
| ps aux | Liste tous les processus en cours |
| top | Vue temps réel CPU/RAM (q pour quitter) |
| htop | Version améliorée de top (à installer via apt) |
| kill PID | Arrête un processus par son numéro |
| kill -9 PID | Force l'arrêt immédiat (ne peut pas être ignoré) |
| lsof -i :8080 | Quel processus utilise le port 8080 ? |
| systemctl status nginx | État d'un service système |
| docker ps | Conteneurs Docker actifs |
| docker ps -a | Tous les conteneurs (même arrêtés) |
| df -h | Espace disque disponible |
| free -h | RAM utilisée / disponible |
bash — diagnostic port occupé
# Mon service ne démarre pas — port 3000 occupé ?
ulrich@vps:~$ lsof -i :3000
COMMAND PID USER FD TYPE NODE NAME
node 1423 ulrich 12u IPv4 TCP *:3000 (LISTEN)
# Je vois le PID 1423 — je vérifie ce que c'est
ulrich@vps:~$ ps aux | grep 1423
ulrich 1423 node /opt/old-app/server.js
# Vieux process oublié — je l'arrête proprement
ulrich@vps:~$ kill 1423
Sur Linux, chaque fichier a des droits de lecture (r), écriture (w) et exécution (x) pour son propriétaire, son groupe, et les autres. Beaucoup d'erreurs mystérieuses sur un VPS viennent de permissions incorrectes.
ulrich@vps:~$ ls -la
-rwxr-xr-- ulrich staff backup.sh
# ↑↑↑ propriétaire : peut lire, écrire, exécuter
# ↑↑↑ groupe : peut lire et exécuter
# ↑↑↑ autres : peuvent seulement lire
| Commande | Description |
|---|
| chmod +x script.sh | Rend un script exécutable |
| chmod 644 fichier | rw-r--r-- : lisible par tous, modifiable seulement par toi |
| chmod 600 .env | rw------- : uniquement toi (idéal pour les secrets) |
| chmod 755 dossier/ | rwxr-xr-x : standard pour les dossiers web |
| chown user:group fichier | Change le propriétaire d'un fichier |
| sudo commande | Exécute en tant que super-administrateur |
| whoami | Affiche l'utilisateur courant |
Bonne pratique : Tes fichiers .env contenant des clés API et mots de passe doivent toujours être en chmod 600. Jamais lisibles par d'autres utilisateurs sur le serveur.
Le vrai superpouvoir de bash : enchaîner des commandes. La sortie d'une commande devient l'entrée de la suivante. C'est ce qui permet d'écrire des one-liners très puissants.
| Symbole | Description |
|---|
| cmd1 | cmd2 | Pipe — envoie la sortie de cmd1 vers cmd2 |
| cmd > fichier | Redirige la sortie vers un fichier (écrase le contenu) |
| cmd >> fichier | Ajoute à la fin du fichier sans écraser |
| cmd 2> erreurs.log | Redirige uniquement les erreurs vers un fichier |
| cmd1 && cmd2 | Exécute cmd2 seulement si cmd1 réussit (code 0) |
| cmd1 || cmd2 | Exécute cmd2 seulement si cmd1 échoue |
# Compter les erreurs dans les logs Docker
ulrich@vps:~$ docker logs n8n | grep "error" | wc -l
7
# Archiver les logs du jour
ulrich@vps:~$ docker logs n8n >> /var/log/n8n-backup.log
# Mettre à jour ET redémarrer — seulement si la mise à jour réussit
ulrich@vps:~$ apt update && apt upgrade -y && systemctl restart nginx
# Filtrer les conteneurs actifs par nom
ulrich@vps:~$ docker ps | grep coolify
a3f1b coolify:latest Up 3 days 0.0.0.0:8000->8000/tcp coolify
Dès que tu répètes plus de 3 commandes, pense à un script. Un fichier .sh automatise des tâches récurrentes — backups, déploiements, maintenance du VPS.
# Assigner une variable (pas d'espaces autour du =)
ulrich@vps:~$ NOM="zoomali"
ulrich@vps:~$ echo "Projet : $NOM"
Projet : zoomali
# Variable calculée : résultat d'une commande
ulrich@vps:~$ DATE=$(date +%Y%m%d)
ulrich@vps:~$ echo $DATE
20260511
#!/bin/bash
# Script de backup automatique — MultiBrasServices
DB_NAME="zoomali_prod"
BACKUP_DIR="/opt/backups"
DATE=$(date +%Y%m%d_%H%M)
mkdir -p $BACKUP_DIR
pg_dump $DB_NAME > $BACKUP_DIR/backup_$DATE.sql
echo "✅ Backup terminé : backup_$DATE.sql"
bash — exécuter le script
# Rendre le script exécutable (une seule fois)
ulrich@vps:~$ chmod +x backup-supabase.sh
# Lancer
ulrich@vps:~$ ./backup-supabase.sh
✅ Backup terminé : backup_20260511_2130.sql
💀 Pas de corbeille. Pas d'annulation. Immédiat.
Sur Linux, rm supprime définitivement. Il n'y a aucune corbeille, aucun Ctrl+Z possible. La suppression est instantanée et irréversible — même en production sur un VPS avec des clients.
Les différentes formes de rm et leurs niveaux de risque :
rm — du moins au plus dangereux
# Supprime un fichier unique — relativement sûr si tu vises bien
ulrich@vps:~$ rm fichier.txt
# -r = récursif, supprime un dossier et TOUT son contenu
ulrich@vps:~$ rm -r mon-dossier/
# -f = force, passe outre les protections, aucune confirmation
ulrich@vps:~$ rm -rf mon-dossier/
⚠ DANGER ABSOLU — supprime le système entier en quelques secondes
ulrich@vps:~$ rm -rf / ← NE JAMAIS TAPER ÇA
# Détruit complètement le serveur. Irrécupérable.
⚠ Variante avec espace accidentel — aussi catastrophique
ulrich@vps:~$ rm -rf /opt /coolify ← espace = supprime /opt ENTIER d'abord
Le scénario classique de catastrophe — le wildcard :
# Objectif : supprimer les fichiers .log dans /opt/logs
# Problème : tu t'es trompé de dossier courant
ulrich@vps:/opt/coolify$ rm -rf *.log
# Si aucun .log n'existe ici mais que le shell expand * différemment
# tu peux supprimer des fichiers non voulus
✅ La bonne méthode : vérifier avec ls AVANT de supprimer
ulrich@vps:~$ ls *.log ← je vois exactement ce qui sera supprimé
app.log debug.log access.log
ulrich@vps:~$ rm *.log ← maintenant je supprime en confiance
Les protections disponibles :
# -i = interactif, demande confirmation pour chaque fichier
ulrich@vps:~$ rm -i fichier.txt
rm: remove 'fichier.txt'? y
# Simuler sans supprimer — affiche la commande sans l'exécuter
ulrich@vps:~$ echo rm -rf /opt/vieux-projet/
rm -rf /opt/vieux-projet/ ← vérifie avant d'enlever le "echo"
# Alias de sécurité à ajouter dans ~/.bashrc
alias rm='rm -i' ← toujours demander confirmation
Règle d'or : Sur un VPS en production — avant tout rm -rf, fais d'abord un ls sur la cible pour voir exactement ce qui sera supprimé. Deux secondes qui peuvent sauver ton serveur et tes clients.
Ce ne sont pas des commandes à éviter — ce sont des commandes à comprendre avant d'utiliser.
🔥 dd — le "destroyer de données"
La commande dd copie des données brutes octet par octet. Utilisée pour flasher des disques, créer des images système. Une erreur dans if= (source) ou of= (destination) et tu écrases un disque entier silencieusement.
dd if=/dev/sda of=/dev/sdb ← écrase sdb avec sda. Irrécupérable.
# Toujours vérifier if= (source) et of= (destination) deux fois
⚡ chmod -R 777 — la fausse bonne idée
Quand un service refuse de lire un fichier, la tentation est d'ouvrir les droits à tout le monde avec 777. Sur un VPS, c'est ouvrir la porte : n'importe qui peut lire tes clés API, modifier tes configs, exécuter du code.
chmod -R 777 /var/www/ ← tout le monde peut tout lire ET modifier
chmod -R 755 /var/www/ ← ✅ lecture pour tous, écriture seulement toi
chmod 600 .env ← ✅ secrets : toi seulement
🧨 > fichier seul — le vidage silencieux
Le symbole > seul, sans commande devant, vide instantanément un fichier. Une faute de frappe peut détruire un fichier de config essentiel.
> /etc/nginx/nginx.conf ← vide la config nginx. Service cassé.
cp /etc/nginx/nginx.conf nginx.conf.bak ← ✅ toujours sauvegarder avant
📋 Coller une commande inconnue avec sudo
Ne jamais copier-coller une commande depuis internet sans la comprendre, surtout avec sudo. C'est le vecteur d'attaque numéro un sur les VPS. Si tu ne comprends pas une ligne, demande avant d'exécuter — à moi, ou sur un forum de confiance.
Les réflexes à acquérir pour travailler sereinement, même sous pression.
| Commande | Pourquoi c'est important |
|---|
| pwd | Toujours vérifier où tu es avant une suppression ou modification |
| ls | Vérifier ce qui existe avant d'utiliser rm ou > |
| cp fichier fichier.bak | Copier avant de modifier un fichier de config important |
| history | Voir les dernières commandes — utile pour retrouver ce qui a planté |
| man commande | Lire le manuel d'une commande avant de l'utiliser |
| commande --help | Aide rapide sur les options disponibles |
| which commande | Savoir où est installée une commande |
Alias de sécurité : Ajoute ces lignes dans ton ~/.bashrc sur le VPS et recharge avec source ~/.bashrc :
~/.bashrc — alias recommandés
# Sécurité — demande toujours confirmation
alias rm='rm -i'
alias cp='cp -i'
alias mv='mv -i'
# Raccourcis pratiques
alias ll='ls -la'
alias dps='docker ps'
alias dlogs='docker logs -f'
alias disk='df -h'
alias mem='free -h'
# Appliquer les changements
ulrich@vps:~$ source ~/.bashrc
La règle des 3 secondes : Avant toute commande destructive sur le VPS (rm, dd, >, chmod -R), prends 3 secondes pour relire ce que tu as tapé. La plupart des catastrophes sur serveur arrivent dans la précipitation ou le copier-coller rapide.