Indice
- La riga
- Manda anche il codice di uscita
- Trasformalo in una funzione di shell
- Squilla solo se fallisce
- Sopravvivere a un portatile chiuso e a una sessione SSH caduta
- Agenti di codice IA
- Cosa non mettere nella notifica
- Domande frequenti
- Perché non usare terminal-notifier o notify-send?
- Funziona su Windows?
- Posso riceverla sull'orologio?
- E se il comando dura 12 ore?
- I colleghi possono ricevere le stesse notifiche?
- In chiusura
- Contenuti correlati
Lanci un addestramento, una suite di test completa, un docker build o un agente di codice su un compito lungo. Poi ti restano due brutte opzioni: startene lì a guardare una barra di avanzamento, oppure andartene e tornare venti minuti dopo per scoprire che è fallito dopo novanta secondi.
C'è una terza opzione e sta in una riga.
La riga
Crea un canale in Echobell, copia il suo URL webhook e aggiungi questo dopo quello che stai lanciando:
pnpm build; curl -sS -X POST https://hook.echobell.one/t/IL_TUO_TOKEN \
-H 'content-type: application/json' \
-d '{"title":"build finita","body":"echobell-web"}'
Nota il ; e non &&. Con && la notifica parte solo se il comando riesce, che è esattamente il contrario: il fallimento è il caso di cui vuoi sapere di più.
Manda anche il codice di uscita
Una notifica che dice "finito" racconta metà della storia. Cattura lo stato:
pnpm build; s=$?; curl -sS -X POST https://hook.echobell.one/t/IL_TUO_TOKEN \
-H 'content-type: application/json' \
-d "{\"title\":\"build $([ $s -eq 0 ] && echo ok || echo FALLITA)\",\"status\":\"$s\"}"
s=$? deve venire immediatamente dopo il comando: qualunque cosa in mezzo, compreso il test [ stesso, sovrascrive $?.
Trasformalo in una funzione di shell
Riscrivere quella roba ogni volta annulla il vantaggio. Metti questo in ~/.zshrc o ~/.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
}
Imposta ECHOBELL_HOOK nel profilo della shell — o meglio, tienilo fuori dal repository dei dotfile ed esportalo da un file che non versioni. Poi:
notify pnpm test
notify cargo build --release
notify python train.py
Il return $status finale conta: mantiene notify trasparente, così notify make && ./deploy.sh continua a comportarsi come ti aspetti.
Con quel payload, i template del canale possono essere:
Titolo
{{command}} · {{status}}
Corpo
su {{host}}
Squilla solo se fallisce
La maggior parte delle esecuzioni va a buon fine e non hai bisogno di saperlo. Due canali risolvono la cosa in modo pulito: uno normale per tutto e uno in modalità chiamata con una condizione:
status != "0"
Punta notify sul secondo canale per tutto ciò per cui ti alzeresti dal letto, e le esecuzioni riuscite restano silenziose.
Sopravvivere a un portatile chiuso e a una sessione SSH caduta
Se il comando gira via SSH, chiudere il portatile uccide la shell e la notifica non parte mai. Due rimedi:
tmux — avvia il comando dentro una sessione e stacca:
tmux new -d -s build 'notify pnpm build'
nohup — per una volta sola:
nohup bash -c 'notify pnpm build' >/dev/null 2>&1 &
In entrambi i casi il processo sopravvive alla tua connessione, e la notifica arriva che tu sia ancora collegato o no.
Agenti di codice IA
Lo stesso schema copre un agente da riga di comando impegnato in un compito lungo:
notify codex exec "rifattorizza il modulo pagamenti e lancia i test"
Per gli agenti che si fermano a metà aspettando una persona — un'approvazione, una richiesta di permesso — una notifica di completamento è lo strumento sbagliato, perché l'esecuzione non è completata. Quel caso richiede l'hook o la callback dell'agente stesso, e merita una telefonata più che una notifica. Trasformare le approvazioni degli agenti in telefonate tratta proprio questo, incluso l'hook Notification di Claude Code e il suo matcher agent_needs_input.
Usali entrambi: l'hook per "sono bloccato", la funzione di shell per "ho finito".
Cosa non mettere nella notifica
Non l'output del comando. Viene voglia di infilare le ultime righe di una build fallita nel corpo. Resisti: i log di build contengono token, stringhe di connessione e dati dei clienti più spesso di quanto si pensi, e il corpo di una notifica finisce su uno schermo bloccato. Manda il codice di uscita e vai a guardare il terminale.
Non l'URL del canale, dentro un repository di dotfile pubblico. Chiunque abbia l'URL può pubblicare sul tuo canale. Tienilo in un file non versionato e attiva Solo POST, così un'anteprima di link vagante non può farlo scattare.
Domande frequenti
Perché non usare terminal-notifier o notify-send?
Quelli mostrano una notifica sulla macchina che esegue il comando. Funzionano finché ci sei seduto davanti. Il senso di questa configurazione è proprio il caso in cui non ci sei: una macchina remota, un portatile chiuso, un'altra stanza.
Funziona su Windows?
Lo schema sì, la sintassi cambia. In PowerShell l'equivalente è Invoke-RestMethod -Method Post -Uri $env:ECHOBELL_HOOK -ContentType application/json -Body $json, con $LASTEXITCODE al posto di $?.
Posso riceverla sull'orologio?
Sì. Le iscrizioni vengono consegnate a un Apple Watch abbinato, che onestamente è il formato giusto per "la build è finita".
E se il comando dura 12 ore?
Niente in questa configurazione va in timeout: il curl parte quando il comando ritorna. Eseguilo sotto tmux così una caduta di connessione non si porta via il processo.
I colleghi possono ricevere le stesse notifiche?
Sì. Condividi il canale e ogni iscritto sceglie il proprio tipo di notifica. Comodo su una macchina di addestramento condivisa dove più di una persona vuole sapere che la GPU è di nuovo libera.
In chiusura
Una funzione di shell, un canale e una condizione se vuoi solo i fallimenti. Ci vogliono due minuti e ti restituisce i venti che passi a guardare barre di avanzamento.
Scarica Echobell per iPhone o prendilo su Google Play, poi provalo su qualcosa che duri abbastanza da farti andare via.