Linux / Comando bg: retomar um trabalho parado no Bash

bg retoma em segundo plano um trabalho parado que o Bash atual acompanha. Depois de suspender um comando em primeiro plano com Ctrl+Z, use bg para continuar sua execução e liberar o terminal para outros comandos.

A retomada envia o sinal de continuação, SIGCONT, mas não entrega ao trabalho o primeiro plano do terminal. Confira o número com jobs no Bash atual e use uma referência como %1. Um programa que precisa ler do terminal pode parar novamente ao continuar em segundo plano.

Sintaxe e preparação

bg [%número_do_trabalho]

Esta é uma descrição da sintaxe: os colchetes indicam um argumento opcional e não devem ser digitados. No Bash, bg é um comando interno; confira type bg e help bg na sessão usada. Outros shells podem ter diferenças.

Para a prática, abra um terminal com Bash interativo e controle de trabalhos ativo. Consulte set -o e procure monitor on. Se aparecer no job control, não prossiga com a sequência como se o terminal tivesse controle de trabalhos; confira o shell e o contexto da sessão. Um Bash não interativo geralmente começa com esse recurso desligado.

Parar uma espera e retomá-la no mesmo terminal

1. Na sessão de teste, execute sleep 60 sem &. O terminal aguarda o comando terminar.
2. Antes de a espera acabar, pressione as teclas Ctrl+Z. Não digite esse texto como comando. Em um terminal com a configuração habitual, o trabalho para, aparece uma indicação Stopped e o prompt retorna. Isso suspende o trabalho; não o encerra.
3. No mesmo Bash, liste os trabalhos parados:

jobs -s

Identifique a linha do sleep que você acabou de iniciar e leia o número entre colchetes. Se a lista estiver vazia, a espera pode já ter terminado ou você pode estar em outro shell. Repita a prática e confira o novo número; não aplique bg a um trabalho desconhecido.

4. Retome o trabalho que acabou de conferir. O exemplo usa %1; troque-o pelo número real, como %2 se a linha começar com [2]:

bg %1

5. Confira a tabela e os identificadores de processo, os PIDs:

jobs -l

Enquanto a espera ainda existir, ela deve aparecer como Running, em vez de Stopped, e o prompt deve continuar disponível. Running distingue execução de suspensão; não significa uso contínuo de CPU. Se o comando já terminou, a entrada pode aparecer como Done e depois ser retirada da tabela.

Conferir a mudança de estado

Depois de executar sleep 60 em primeiro plano e pressionar Ctrl+Z, a consulta e a retomada também podem ser organizadas assim. Execute as linhas no mesmo Bash e substitua %1 pelo trabalho conferido na primeira consulta:

jobs
bg %1
jobs

As duas linhas abaixo ilustram as consultas antes e depois da retomada. O número, o espaçamento e o idioma do estado variam conforme a sessão; são um exemplo de apresentação, não a saída literal do teste com sleep 30 descrito a seguir.

[1]+  Stopped  sleep 60
[1]+  Running  sleep 60 &

%1 é o número do trabalho nesse Bash, não um PID. O sinal + identifica o trabalho considerado atual pelo shell. Em um pipeline, um trabalho pode reunir vários processos; bg atua sobre o trabalho acompanhado pelo shell, não serve para anexar um processo arbitrário de outro terminal.

Em uma verificação com Bash 5.3.9 do Git para Windows, um shell não interativo separado ativou set -m, criou seu próprio sleep 30 e conferiu o PID guardado em $! contra jobs -p %1. Somente esse filho recebeu STOP. jobs -s mostrou Stopped; bg %1 retornou 0, jobs -l mostrou Running e a nova consulta jobs -s ficou vazia. Ao final, o envio de TERM ao próprio filho retornou 0 e wait retornou 143.

Essa verificação usou sinais enviados ao filho controlado e não reproduziu o teclado Ctrl+Z, fg ou o acesso ao terminal de uma sessão Linux nativa. A sequência interativa acima depende do terminal e do controle de trabalhos disponíveis nesse ambiente.

Escolher o trabalho a retomar

Confira a tabela antes de usar uma referência. Atual e anterior são escolhas do mecanismo de controle de trabalhos; não indicam prioridade de CPU. O manual de conceitos básicos de controle de trabalhos do Bash explica essas referências e a relação com o terminal.

Falhas e programas que param novamente

bg retorna um estado diferente de zero se o controle de trabalhos não estiver ativo. Com o recurso ativo, também falha quando a referência não existe ou aponta para um trabalho iniciado sem controle de trabalhos. No teste disponível, bg sem esse recurso retornou 1 com no job control; com set -m e uma tabela vazia, retornou 1 com current: no such job.

A ausência de trabalhos parados não implica, sozinha, que bg sempre falhará. Na mesma verificação, chamar bg %1 outra vez sobre o sleep já em segundo plano produziu job 1 already in background, mas retornou 0. Confira o estado com jobs em vez de interpretar somente uma mensagem. As condições do comando estão no manual dos comandos internos de controle de trabalhos do Bash.

Um programa em segundo plano que tenta ler do terminal controlador normalmente recebe SIGTTIN e para novamente, salvo tratamento do sinal e condições específicas do processo. Editores e programas interativos, portanto, podem precisar do primeiro plano. Depois de confirmar o número, fg %1 traz aquele trabalho ao primeiro plano; substitua %1 pelo trabalho correto. Sua saída também pode se misturar ao prompt enquanto ele está em segundo plano.

A espera de teste termina naturalmente; deixe-a concluir e confira jobs novamente. Se precisar encerrá-la antes, identifique somente o próprio processo de teste e siga o procedimento de envio de SIGTERM e verificação com kill. Não copie um PID de exemplo nem encerre um trabalho apenas porque recebeu o número 1.

Pergunta frequente

Usar & no final de um comando é igual a usar bg?

& inicia um comando em segundo plano desde o começo. bg permite retomar em segundo plano um trabalho que já está parado na tabela do shell. Nenhuma dessas formas, por si só, transforma o programa em serviço ou garante que continue após fechar o terminal; o guia de nohup explica uma parte desse problema e seus limites.