jobsList the shell's background and stopped jobs
jobs lists the commands your current shell has running in the background or stopped with Ctrl-Z, each with a job number like %1. Those job numbers are what fg, bg, kill and wait use, and they only exist inside the shell that started them.
jobs [-l | -p] [-r | -s] [%JOB...]You kick off a database export and a compression in the background and want to keep an eye on both.
jobsA bash builtin: it reads the shell's own job table. There is no /usr/bin/jobs to call from other programs.
Job control is a feature of an interactive shell plus the terminal driver. When you run a pipeline, bash puts all its processes in a new process group (setpgid). For a foreground job it hands the terminal to that group with tcsetpgrp, so keyboard signals (Ctrl-C sends SIGINT, Ctrl-Z sends SIGTSTP) go to that group, not to the shell. A command ending in & stays in its own group in the background while bash keeps the terminal. bash records every group in its job table with a number, the command text and a state, and updates the state when waitpid tells it a child stopped, continued or exited. jobs just prints that table. + marks the current job (the default for fg and bg) and - the previous one. Another terminal, a cron job or a script without set -m has no job table to show.
The terminal driver signals only the foreground process group; bash moves jobs between foreground, background and stopped.
bash puts the new process in its own process group and hands the terminal to that group with tcsetpgrp. The TTY now delivers keyboard signals to it.
-lInclude the PID of each job-pPrint only the PIDs (handy for kill $(jobs -p))-rOnly running jobs-sOnly stopped jobs%NJob number N%+ / %%The current job (marked +)%-The previous job (marked -)%string / %?stringThe job whose command starts with / contains stringRunning jobs in a new terminal to find a job you started elsewhereThe job table belongs to the shell that started the job. Other shells can't see or use its %N numbers.
pgrep -af NAME, then manage it by PIDUsing kill %1 inside a cron scriptNon-interactive shells don't enable job control by default, so job specs and fg/bg don't behave as in a terminal.
Save $! after starting the process: cmd & pid=$!; kill $pidLeaving Ctrl-Z'd jobs behind and forgetting themStopped processes hold memory, file handles, locks and listening ports; a stopped vim keeps its .swp file and a stopped server still owns its port.
jobs -s before logging out; fg and quit them properlyTry these on a Linux machine of your own. Each task has a hint and a solution.
Start `sleep 300 &` and `sleep 400 &`, then list your jobs with their PIDs.
Run `sleep 500` in the foreground, stop it with Ctrl-Z, and list only stopped jobs.
Kill all your background jobs in one command using their PIDs.
jobsList the shell's background and stopped jobs
jobs lists the commands your current shell has running in the background or stopped with Ctrl-Z, each with a job number like %1. Those job numbers are what fg, bg, kill and wait use, and they only exist inside the shell that started them.
jobs [-l | -p] [-r | -s] [%JOB...]You kick off a database export and a compression in the background and want to keep an eye on both.
jobsA bash builtin: it reads the shell's own job table. There is no /usr/bin/jobs to call from other programs.
Job control is a feature of an interactive shell plus the terminal driver. When you run a pipeline, bash puts all its processes in a new process group (setpgid). For a foreground job it hands the terminal to that group with tcsetpgrp, so keyboard signals (Ctrl-C sends SIGINT, Ctrl-Z sends SIGTSTP) go to that group, not to the shell. A command ending in & stays in its own group in the background while bash keeps the terminal. bash records every group in its job table with a number, the command text and a state, and updates the state when waitpid tells it a child stopped, continued or exited. jobs just prints that table. + marks the current job (the default for fg and bg) and - the previous one. Another terminal, a cron job or a script without set -m has no job table to show.
The terminal driver signals only the foreground process group; bash moves jobs between foreground, background and stopped.
bash puts the new process in its own process group and hands the terminal to that group with tcsetpgrp. The TTY now delivers keyboard signals to it.
-lInclude the PID of each job-pPrint only the PIDs (handy for kill $(jobs -p))-rOnly running jobs-sOnly stopped jobs%NJob number N%+ / %%The current job (marked +)%-The previous job (marked -)%string / %?stringThe job whose command starts with / contains stringRunning jobs in a new terminal to find a job you started elsewhereThe job table belongs to the shell that started the job. Other shells can't see or use its %N numbers.
pgrep -af NAME, then manage it by PIDUsing kill %1 inside a cron scriptNon-interactive shells don't enable job control by default, so job specs and fg/bg don't behave as in a terminal.
Save $! after starting the process: cmd & pid=$!; kill $pidLeaving Ctrl-Z'd jobs behind and forgetting themStopped processes hold memory, file handles, locks and listening ports; a stopped vim keeps its .swp file and a stopped server still owns its port.
jobs -s before logging out; fg and quit them properlyTry these on a Linux machine of your own. Each task has a hint and a solution.
Start `sleep 300 &` and `sleep 400 &`, then list your jobs with their PIDs.
Run `sleep 500` in the foreground, stop it with Ctrl-Z, and list only stopped jobs.
Kill all your background jobs in one command using their PIDs.