In a bash script, `echo $$` inside a `( ... )` subshell prints the same number as `echo $$` outside it. Why doesn't `$$` change, and which variable reports the PID of the process actually running that code?

## The two variables - **`$$`** — the process ID of the shell that was invoked to run this script. POSIX requires it to stay constant for the life of that shell, and bash honours that by *not* refreshing it in forked children. - **`$BASHPID`** — a bash-specific variable, introduced in **bash 4.0**, that always expands to the PID of the bash process doing the expansion. In the top-level shell the two are equal; anywhere bash has forked, they differ. ```bash #!/usr/bin/env bash echo "main : $$ $BASHPID" # e.g. 4711 4711 ( echo "paren : $$ $BASHPID" ) # e.g. 4711 4712 ``` Because `$BASHPID` is bash 4.0+, it is unavailable on the bash 3.2 that ships as `/bin/bash` on macOS, and it does not exist in POSIX `sh`. ## Why bash was designed this way `$$` predates the idea of asking "which process am I?" — it exists so a script can identify *itself*, mostly for naming things and for signalling itself. A shell forks constantly and mostly invisibly: every pipeline stage, every command substitution, every background job, every `( ... )`. If `$$` tracked the current process, then a value captured early and used later would be unstable in a way scripts could not reason about, and it would break the POSIX contract. So bash froze `$$` at the invoking shell and, when the need for the true PID became clear, exposed it as a separate variable rather than changing the old one. Note what this means for children that are not bash: an external program's `getpid()` is of course its own PID; `$$` is a *shell expansion*, evaluated by bash before the program is launched, so `some-tool $$` passes the script's PID as an argument, not the tool's. ## Where it actually causes bugs ### PID-derived file names A long-standing habit is to build a scratch file name from the PID: ```bash tmp="/tmp/build.$$" ``` Inside a single script that is at least stable. But run several blocks in parallel subshells and every one of them computes the same `$$`, so they all write `/tmp/build.4711` — they clobber each other, and the failure is timing-dependent and rare enough to survive testing. Substituting `$BASHPID` makes the names distinct, but PIDs make poor unique identifiers in general: the kernel reuses them, a stale file from a previous run can collide with a recycled number, and inside a container the numbers restart from a small range. The robust answer is to let the system allocate the name — `mktemp` — instead of deriving it. ### Signalling the wrong process ```bash ( slow-thing || kill $$ ) # intends: give up on this block ``` Because `$$` is the script's PID, this kills the entire script — often the opposite of what the author wanted, and dramatic when a parent has a cleanup trap that then also runs. To end just the subshell, `exit` from it. To signal the current process explicitly, `kill "$BASHPID"`. ### Log lines that all look alike A script that fans work out into subshells and stamps each log line with `$$` produces output where every worker claims the same identity, which makes interleaved logs unreadable. `$BASHPID` distinguishes them. ## Related identity variables - **`$PPID`** — the PID of this shell's parent. Like `$$`, it is not refreshed in a subshell, so a subshell's `$PPID` is the *script's* parent, not the script itself. - **`$SHLVL`** — counts nested shell *invocations*, incremented when a new bash starts. A `( ... )` subshell is a fork of the running shell, not a new invocation, so it does not bump `SHLVL`; running `bash` explicitly does. ## The rule of thumb Ask what you want the number *for*. Identifying the script as a whole — a top-level lock, a message that says "run 4711 started" — is `$$`, and it is correct precisely because it is stable. Identifying the process executing right now — per-worker logging, signalling yourself — is `$BASHPID`. And generating something unique is neither: use a tool built for it.