Qualche tempo fa ho scritto una sceneggiatura per aspettare la fine di un altro processo. NOISE_CMD
potrebbe essere qualcosa del genere notify-send ...
, dato che DISPLAY
è impostato correttamente.
#!/bin/bash
NOISE_CMD="/usr/bin/mplayer -really-quiet $HOME/sfx/alarm-clock.mp3"
function usage() {
echo "Usage: $(basename "$0") [ PROCESS_NAME [ PGREP_ARGS... ] ]"
echo "Helpful arguments to pgrep are: -f -n -o -x"
}
if [ "$#" -gt 0 ] ; then
PATTERN="$1"
shift
PIDS="$(pgrep "$PATTERN" "$@")"
if [ -z "$PIDS" ] ; then
echo "No process matching pattern \"$PATTERN\" found."
exit
fi
echo "Waiting for:"
pgrep -l "$PATTERN" "$@"
for PID in $PIDS ; do
while [ -d "/proc/$PID" ] ; do
sleep 1
done
done
fi
exec $NOISE_CMD
Senza alcun dubbio, fai subito un po 'di rumore. Questo comportamento consente qualcosa di simile per comodità (supponiamo che tu chiami lo script di seguito alarm.sh
):
apt-get upgrade ; ~/bin/alarm.sh
Ovviamente puoi fare molte cose divertenti con un tale script, come lasciare un'istanza di alarm.sh
attesa per un'istanza di alarm.sh
, che è in attesa di qualche altro comando. O eseguendo un comando subito dopo che alcune attività di un altro utente connesso hanno terminato ...>: D
Una versione precedente dello script sopra potrebbe essere interessante, se si desidera evitare una dipendenza pgrep
e accettare personalmente gli ID del processo di ricerca:
#!/bin/bash
if [ "$#" -lt 2 -o ! -d "/proc/$1" ] ; then
echo "Usage: $(basename "$0") PID COMMAND [ ARGUMENTS... ]"
exit
fi
while [ -d "/proc/$1" ] ; do
sleep 1
done
shift
exec "$@"
Leggermente fuori tema, ma utile in situazioni simili: uno potrebbe essere interessato a reptyr
, uno strumento che "ruba" un processo da una shell (padre) e lo esegue dalla shell corrente. Ho provato implementazioni simili ed reptyr
è la più bella e affidabile per i miei scopi.