Skip to content
shellmap

fg — Bring a background or stopped job to the foreground across all 5 shells

Equivalents in every shell

Bashunix
fg %1
Zshunix
fg %1
Fishunix
fg 1

fish takes a bare integer ID — no leading `%`.

PowerShellwindows
Receive-Job -Wait -Id 1

PowerShell jobs are never "in the foreground" — they always run in subprocesses. `Receive-Job -Wait` blocks the current shell until the job finishes and streams its output, which is the closest equivalent. `Wait-Job <id>` blocks without streaming.

cmd.exewindows
start /wait command

cmd.exe has no Unix-style fg. `start /wait` blocks the current shell until the launched process exits, which approximates foregrounding *new* commands. You cannot bring an already-running background process back into the parent cmd window.

Worked examples

Foreground the most recent job

Bash
fg
Fish
fg

Foreground a specific job by ID

Bash
fg %2
Fish
fg 2

Wait for a PowerShell job to finish and stream its output

PowerShell
Receive-Job -Wait -Id 1

Gotchas

  • Only one job can be in the foreground at a time. `fg %2` replaces the current foreground job — and your shell does not read keystrokes while a fg job is attached.
  • fish job IDs are recycled. If you `fg 1` after job 1 already exited, fish errors with "no such job".
  • PowerShell `Receive-Job -Wait` returns the job’s output but does NOT pipe your keystrokes to its stdin — there is no real foregrounding, only blocking-collect.
  • Job tables are per-shell-process: a job started in one terminal cannot be `fg`’d from a different terminal even if you `screen`/`tmux` reattach to the same session.

WSL & PowerShell Core notes

pwshpwsh has no foreground/background job model — jobs always run in subprocesses. `Receive-Job -Wait -Id N` blocks the current shell and streams the job's stdout (the closest analogue to `fg`) but does NOT forward your keystrokes to the job's stdin, so it is strictly "block until done + collect output", not true interactive foregrounding. On Linux/macOS pwsh hosts, drop to bash via `bash -c '<long-task>'` (with no `&`) when you need real fg/bg semantics.
WSLWSL bash `fg` works identically to native Linux — but the job table is per-bash-process and does NOT migrate across `screen` or `tmux` sessions, so jobs started inside a screen session can only be `fg`'d from within that same session, even if you reattach to it from a different Windows Terminal tab. Job IDs are also per-bash-process, so `fg %1` from a fresh bash login (e.g. a new tab) cannot reach a job started in an earlier session.

Common tasks using fg

Related commands