Être prévenu quand une longue commande se termine dans le terminal

Arrêtez de surveiller une compilation de quarante minutes. Une ligne après n'importe quelle commande envoie le résultat sur votre téléphone, même si vous êtes parti.

Mis à jour

Table des matières

Vous lancez un entraînement, une suite de tests complète, un docker build ou un agent de code sur une tâche longue. Il vous reste deux mauvaises options : rester devant une barre de progression, ou partir et revenir vingt minutes plus tard pour découvrir que ça a échoué au bout de quatre-vingt-dix secondes.

Il existe une troisième option, et elle tient sur une ligne.

La ligne

Créez un canal dans Echobell, copiez son URL de webhook et ajoutez ceci après ce que vous lancez :

pnpm build; curl -sS -X POST https://hook.echobell.one/t/VOTRE_TOKEN \
  -H 'content-type: application/json' \
  -d '{"title":"build terminé","body":"echobell-web"}'

Notez le ; et non &&. Avec &&, la notification ne part que si la commande réussit, ce qui est exactement l'inverse : l'échec est le cas dont vous voulez le plus être averti.

Envoyez aussi le code de sortie

Une notification qui dit « terminé » ne raconte que la moitié de l'histoire. Capturez le statut :

pnpm build; s=$?; curl -sS -X POST https://hook.echobell.one/t/VOTRE_TOKEN \
  -H 'content-type: application/json' \
  -d "{\"title\":\"build $([ $s -eq 0 ] && echo ok || echo ÉCHEC)\",\"status\":\"$s\"}"

s=$? doit venir immédiatement après la commande : tout ce qui s'intercale, y compris le test [ lui-même, écrase $?.

Faites-en une fonction shell

Retaper ça à chaque fois annule l'intérêt. Mettez ceci dans ~/.zshrc ou ~/.bashrc :

notify() {
  "$@"
  local status=$?
  curl -sS -X POST "$ECHOBELL_HOOK" \
    -H 'content-type: application/json' \
    -d "{\"command\":\"$*\",\"status\":\"$status\",\"host\":\"$(hostname -s)\"}" \
    >/dev/null
  return $status
}

Définissez ECHOBELL_HOOK dans le profil de votre shell — ou mieux, gardez-le hors de votre dépôt de dotfiles et exportez-le depuis un fichier non versionné. Ensuite :

notify pnpm test
notify cargo build --release
notify python train.py

Le return $status final compte : il garde notify transparent, si bien que notify make && ./deploy.sh se comporte toujours comme prévu.

Avec ce payload, les modèles du canal peuvent être :

Titre

{{command}} · {{status}}

Corps

sur {{host}}

Ne me sonnez qu'en cas d'échec

La plupart des exécutions réussissent et vous n'avez pas besoin de le savoir. Deux canaux règlent ça proprement : un normal pour tout, et un en mode appel avec une condition :

status != "0"

Pointez notify vers le second canal pour ce qui vous ferait sortir du lit, et les exécutions réussies restent silencieuses.

Survivre à un portable fermé et à une session SSH coupée

Si la commande tourne en SSH, fermer le portable tue le shell et la notification ne part jamais. Deux solutions :

tmux — lancez la commande dans une session et détachez-vous :

tmux new -d -s build 'notify pnpm build'

nohup — pour un cas isolé :

nohup bash -c 'notify pnpm build' >/dev/null 2>&1 &

Dans les deux cas le processus survit à votre connexion, et la notification arrive que vous soyez encore attaché ou non.

Agents de code IA

Le même schéma couvre un agent en ligne de commande occupé par une tâche longue :

notify codex exec "refactorise le module de paiement et lance les tests"

Pour les agents qui s'arrêtent en cours de route en attendant un humain — une approbation, une demande de permission — une notification de fin est le mauvais outil, puisque l'exécution n'est pas terminée. Ce cas demande le hook ou le callback de l'agent lui-même, et il mérite un appel plutôt qu'une notification. Transformer les approbations d'agent en appels téléphoniques traite ce sujet, y compris le hook Notification de Claude Code et son matcher agent_needs_input.

Utilisez les deux : le hook pour « je suis bloqué », la fonction shell pour « j'ai fini ».

Ce qu'il ne faut pas mettre dans la notification

Pas la sortie de la commande. Il est tentant de glisser les dernières lignes d'un build en échec dans le corps. Résistez : les logs de build contiennent des jetons, des chaînes de connexion et des données clients plus souvent qu'on ne le croit, et un corps de notification finit sur un écran verrouillé. Envoyez le code de sortie et allez voir le terminal.

Pas l'URL du canal dans un dépôt de dotfiles public. Quiconque a l'URL peut poster dans votre canal. Gardez-la dans un fichier non versionné et activez POST uniquement pour qu'un aperçu de lien égaré ne la déclenche pas.

Questions fréquentes

Pourquoi ne pas utiliser terminal-notifier ou notify-send ?

Ils affichent une notification sur la machine qui exécute la commande. C'est utile quand vous êtes assis devant. Tout l'intérêt de ce montage, c'est le cas contraire : une machine distante, un portable fermé, une autre pièce.

Est-ce que ça marche sous Windows ?

Le schéma oui, la syntaxe diffère. En PowerShell, l'équivalent est Invoke-RestMethod -Method Post -Uri $env:ECHOBELL_HOOK -ContentType application/json -Body $json, avec $LASTEXITCODE à la place de $?.

Puis-je recevoir la notification sur ma montre ?

Oui. Les abonnements sont livrés sur une Apple Watch appairée, qui est franchement le bon format pour « le build est fini ».

Et si la commande dure 12 heures ?

Rien n'expire dans ce montage : le curl s'exécute quand la commande retourne. Lancez-la sous tmux pour qu'une coupure n'emporte pas le processus.

Mes collègues peuvent-ils recevoir les mêmes notifications ?

Oui. Partagez le canal et chaque abonné choisit son type de notification. Pratique sur une machine d'entraînement partagée où plusieurs personnes veulent savoir que le GPU est de nouveau libre.

Conclusion

Une fonction shell, un canal, et une condition si vous ne voulez que les échecs. Deux minutes de mise en place, et vous récupérez les vingt passées à regarder des barres de progression.

Téléchargez Echobell pour iPhone ou obtenez-le sur Google Play, puis essayez sur quelque chose d'assez long pour que vous partiez.


Contenu lié