> ## Documentation Index
> Fetch the complete documentation index at: https://docs.syntblaze.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Bash Background Command
In Bash, executing a command in the background allows the shell to run a process asynchronously. By appending the control operator `&` to a command, the shell forks a child process to execute the command. Instead of blocking synchronously on `waitpid()`, the parent shell immediately continues its own execution. The shell still eventually executes `waitpid()` (typically via a `SIGCHLD` signal handler or before issuing the next prompt) to reap the terminated child process and prevent it from becoming a zombie process.
```bash theme={"dark"}
command [arguments] &
```
## Technical Mechanics
**Process Identification**
The behavior of background process identification depends on the shell's execution mode:
* **Interactive Shells:** Bash assigns the background process a session-specific Job ID and an OS-level Process ID (PID). It immediately prints these values to standard error before returning the prompt.
```bash theme={"dark"}
$ sleep 60 &
[1] 45892
```
* **Non-Interactive Scripts:** Backgrounding a task with `&` is completely silent and produces no terminal output. The PID of the most recently executed background command is stored in the `$!` special parameter.
**Standard I/O Handling**
Background processes inherit standard output (stdout) and standard error (stderr) from the parent shell unless explicitly redirected. If not redirected, the background process will print directly to the terminal, potentially interleaving with the parent shell's output.
Handling of standard input (stdin) differs based on the environment:
* **Interactive Shells:** If a background process attempts to read from stdin, the terminal driver sends it a `SIGTTIN` signal, which immediately suspends (stops) the process until it is brought to the foreground.
* **Non-Interactive Scripts:** Job control is disabled by default. The `stdin` of asynchronous commands is automatically redirected from `/dev/null`. If the background process attempts to read from stdin, it receives an immediate End-Of-File (EOF) rather than being suspended.
## Job Control Builtins
Bash provides builtin commands to manage the state of background processes within the current session's job table. The `fg` and `bg` commands rely on monitor mode (`set -m`). Because monitor mode is disabled by default in non-interactive scripts, `fg` and `bg` will fail with a "no job control" error if a developer attempts to use them in a standard script without explicitly enabling monitor mode. The `jobs` command, however, successfully tracks and lists asynchronous background processes regardless of monitor mode.
* **`jobs`**: Queries the shell's job table and outputs the status of all active, stopped, or recently terminated background jobs.
```bash theme={"dark"}
jobs [-lnprs] [jobspec ...]
```
* **`fg`**: Transfers a background job to the foreground. It assigns the terminal's foreground process group to the job and sends a `SIGCONT` signal if the process was suspended.
```bash theme={"dark"}
fg [jobspec]
```
* **`bg`**: Resumes a suspended job, keeping it in the background. It sends a `SIGCONT` signal to the stopped process without transferring terminal control.
```bash theme={"dark"}
bg [jobspec ...]
```
* **`wait`**: Blocks the parent shell's execution until the specified background child process (or all child processes, if no PID/Job ID is provided) terminates. It then returns the exit status of the awaited process. Unlike `fg` and `bg`, `wait` functions fully in non-interactive scripts without monitor mode, accepting both OS-level PIDs and shell Job IDs (e.g., `wait %1`).
```bash theme={"dark"}
wait [-n] [id ...]
```
## Process Detachment and Termination
In *interactive* shells, if the shell receives a `SIGHUP` (hangup) signal (such as when the terminal emulator window is closed), it resends the `SIGHUP` to all jobs in its internal job table. Additionally, if the `huponexit` shell option is explicitly enabled via `shopt -s huponexit`, an *interactive login* shell will send a `SIGHUP` to all jobs upon a normal exit. Non-interactive scripts do not exhibit either of these behaviors and do not propagate `SIGHUP` to background jobs.
Two primary mechanisms prevent background processes from terminating when a hangup signal is dispatched:
**`disown`**
A shell builtin that, by default, removes a specified job from the shell's internal job table. Because the shell no longer tracks the process, it will not send a `SIGHUP` to that process when the shell terminates or receives a hangup signal. If the `-h` flag is provided, the job is *not* removed from the job table; instead, it is marked in the shell's internal table so that the shell itself will not send it a `SIGHUP`. This does not modify the process's actual signal mask, meaning the process will still terminate if it receives a `SIGHUP` directly from the OS or another process.
```bash theme={"dark"}
disown [-ar] [-h] [jobspec ...]
```
**`nohup`**
An external command wrapper (not a shell builtin) that executes a command while modifying its signal mask to ignore `SIGHUP` signals. If standard output is attached to a terminal, `nohup` redirects it to a file named `nohup.out`. Furthermore, `nohup` only redirects standard error to standard output if standard error is currently attached to a terminal. If standard error is explicitly redirected elsewhere by the user (e.g., `nohup cmd > custom.log 2> error.log &`), `nohup` respects the existing redirection and leaves it alone.
```bash theme={"dark"}
nohup command [arguments] &
```
Tired of Poor Bash Skills? Fix That With Deep Grasping!
Learn More
