slacky.eu

Ciao,
purtroppo la mia conoscenza del bash è soltanto superficiale e stavo cercando di scrivere uno script che faccia le seguenti operazioni
Quindi comando1 deve andare in background (è un comando che non termina mai - in sostanza apre una connessione), comando2 fa quello che deve fare e quando ha finito il comando1 deve essere ucciso.

Una soluzione potrebbe essere quella di prendere il PID del comando1 e poi dare il kill. Ma qualunque altra soluzione andrebbe benissimo. Qualcuno mi può dare una mano?

Se hai più processi in bg, allora puoi lavorare con il comando 'jobs', controllando il numero del processo che vuoi portare in fg e poi terminandolo con crtl-c.

Emanuele

Ciao spina,
grazie, ma quello che mi serve è fare le operazioni all'interno di uno script bash.

Allora:dal man di bash:

$! Expands to the process ID of the most recently executed background (asynchronous) command.

Quindi nota che si espande al PID dell'ultimo comando mandato in bg.

Emanuele

Grazie spina,
funziona benissimo. Cosa sarebbe il forum senza di te!

un'altra soluzione similissima è che è necessaria se tra comando1 e kill ci sono altri processi in background.
poi evito il kill -9 finchè non mi è necessario.

Sono d'accordo con te 01, ho usato il SIGKILL perchè facendo una prova senza ho notato qualcosa di strano:Non me lo so spiegare, quindi ho optato per il SIGKILL. Comunque può darsi che sia nano ha gestire il segnale SIGTERM (quello di default).

Emanuele

mi sembra piuttosto normale che ti va in stopped, e non per il kill.
riprova: Quando un programma che sta in background si aspetta un input da tastiera (e nano è un editor), questo va in stopped perchè chiaramente in background non può arrivargli nessun output sensato.
Il fatto che te lo mostra dopo il kill è un puro caso, o meglio, un processo che butti in background ti da messaggi di interrupt&co solamente quando premi invio nella shell.


Il SIGTERM è un modo soft di chiudere un programma.. gli dice 'effettua la chiusura' (come se premi con la X su una finestra) e il programma decide di chiudersi (può cachare l'interrupt e fare le sue operazioni di chiusura o non chiudersi affatto). Sta di fatto che un processo STOPPED non può fare operazioni, quindi lì rimane.
Il SIGKILL non dice 'chiuditi' al programma, ma dice al kernel 'chiudilo'; non importa cosa stia facendo o non stia facendo il programma; il kernel libera memoria e risorse e lo toglie brutalmente dalla tabella dello scheduler (a meno che non riesce a liberare le risorse di I/O perchè queste non rispondono alla chiusura; in tal caso uccidi il processo solamente con un reboot.... se ti basta; io ho avuto difficoltà a fare il reboot con un hardware che non rispondeva).

Ciao
01

Quello che volevo sottolineare non era lo 'stopped', ma il fatto che non viene eliminato dalla tabella dei processi, vedi il comando 'ps'. In pratica succede che il processo non termina. Come dici te: "quindi lì rimane."

Per il resto sono d'accordo con te,
Emanuele