Digamos que você não possua GNU screen
e tmux
(e X11 e consoles virtuais), mas queira alternar entre um shell de login e outro shell interativo.
Você primeiro faria login no console e, em seguida, iniciaria um novo shell, bloqueando temporariamente o shell de login. Para obter o shell de login de volta para fazer algum trabalho lá, você faria suspend
. Em seguida, você solicitaria fg
que o shell interativo voltasse para continuar com o que você fez lá.
Na verdade, com controle de trabalho, o shell de login poderia gerar uma série de conchas interativos como trabalhos de fundo que você poderia mudar para com fg %1
, fg %2
etc., mas para voltar para o shell de login, você precisaria usar suspend
a menos que você queria manualmente kill -s STOP $$
.
Observe também que Ctrl+ Zno prompt de um shell interativo não o suspenderá.
EDIT: Inicialmente, eu tinha uma longa seção hipotética sobre o uso de suspend
em um script, mas como o comando requer controle de tarefas e como shells não interativos geralmente não têm controle de tarefas, excluí essa seção.
Seção excluída com suspend
substituída por kill -s STOP $$
(isso realmente não pertence mais à resposta, mas pode ser interessante para outras pessoas):
Digamos que você tenha um processo em segundo plano (um script) em um script e que em algum momento esse processo em segundo plano precise parar e aguardar o processo pai dizer para continuar. Pode ser que o pai tenha tempo para extrair e mover arquivos para o local ou algo assim.
O script filho suspenderia ( kill -s STOP $$
) e o script pai enviaria um CONT
sinal para ele quando estivesse tudo bem em continuar.
Ele oferece a oportunidade de implementar uma espécie de sincronização entre um processo pai e um processo filho (embora muito básico, pois o processo do shell pai precisa mais ou menos adivinhar que o processo filho está suspenso, embora isso possa ser corrigido com o filho. interceptar CONT
e não suspender se esse sinal for recebido muito cedo).
fork/exec
chamada de sistema