Questo post può essere d'aiuto. La raccomandazione è:
- in background il processo (con Ctrl-Z, quindi bg )
- corri disown -h% [jobid] (probabilmente un bash-ism, quindi dovrai tradurre per tcsh)
La cattiva notizia , ovviamente, è che il bg dovrebbe essere fatto nella stessa shell in cui è in esecuzione il processo ... ma ... potrebbe già essere in background.
La brutta notizia è che potrebbe essere necessario eseguire la chiamata di rifiuto nella stessa shell. In tal caso, sì, sei fregato. Ma non sono sicuro, forse root può disconnetterlo forzatamente.
Hmm. Possibili buone notizie - tcsh fa automaticamente il rifiuto :
Se tcsh esce in modo anomalo, rinnega automaticamente i lavori in esecuzione in background quando esce.
Quindi, se il tuo processo a lungo termine è già in background, uccidere il suo genitore tcsh dovrebbe consentirgli di continuare. Il processo è ora disconnesso dal terminale di partenza. (In caso contrario, vedere "cattive notizie" sopra.)
Sfortunatamente, non è uno schermo, quindi non c'è una vera riconnessione. Puoi falsificarlo con gdb forse (di nuovo, dal primo link):
[...] con alcuni hack sporchi, non è impossibile riaprire un processo 'stdout / stderr / stdin.
Quindi è ancora possibile creare una finestra vuota (ad esempio che esegue la sospensione).
E poi usa gdb per esempio per collegarti al processo, esegui qualche chiamata close (0)
call close (1)
call close (2)
call open ("/ dev / pts / xx", ...)
call dup (0)
call dup (0)
scollegare
L'output del processo verrebbe visualizzato sullo schermo. Non sarebbe collegato a quel terminale dello schermo, quindi per esempio [sic] ucciderebbe il comando "sleep", non il processo, ma potrebbe essere sufficiente per l'OP.
Mi chiedo se non ci dovrebbero essere anche "call dup (1)" e "call dup (2)" in quel processo ...