Job Control: bg, fg, jobs

Run a thing without blocking the prompt

Append & to put a command in the background of your shell. The prompt returns immediately; the job keeps running. jobs lists what your shell knows about; fg brings one back to the foreground; bg resumes a stopped job in the background.

The flow

./long-build.sh &        # start in background
jobs                          # list with [N] tags
fg %1                         # bring job 1 to foreground
Ctrl+Z                        # suspend it
bg %1                         # resume in background
fg %1                         # back to foreground
kill %1                       # end it

Job IDs vs PIDs

%1 = job 1 of this shell. kill %1 kills it. jobs -l shows the underlying PIDs if you want to use them with ps or kill from another shell.

Disowning and hangup handling

What happens when a terminal closes depends on the shell, its job table, the terminal, and the program. disown removes or marks a job in the current shell; nohup starts a command with SIGHUP ignored and may redirect terminal-bound output. Neither gives the process durable logs, restart policy, or health reporting.

When to reach for tmux instead

For long-running things you might want to come back to tomorrow, use a tmux session (next-but-one lesson). Job control is for the now-and-here; tmux is for multi-session persistence.

Persistence needs an owner

Use job control for work tied to this shell, tmux for an interactive session you will reattach to, and a service manager for unattended work that needs restart policy, logs, and observable state.

Job numbers belong to one shell

%1 means job 1 only inside the shell that created that job table. Another shell must use a verified PID or, preferably, the service owner. A background job is still attached to shell and terminal contracts; it is not unattended operation.