$BASHPID And $$ differ in some cases

Question

I'm reading "BASH pocket guide of Oreilly". It said:

The process ID of the current Bash process. In some cases, this can differ from $$.

Above explanation , explained $BASHPID variable.

Question: which cases?

Solution 1

An example is provided in the BASHPID description of the bash manpage:

   BASHPID
          Expands to the process id of the  current  bash  process.   This
          differs  from  $$ under certain circumstances, such as subshells
          that do not require bash to be re-initialized.

Here is an example of a subshell outputting the contents of the variable, along with $$ and the contents of BASHPID outside of the subshell.

$ echo $(echo $BASHPID $$)      $$       $BASHPID
              25680    16920    16920    16920
#             |        |        |        |
#             |        |        |        -- $BASHPID outside of the subshell
#             |        |        -- $$ outside of the subshell
#             |        -- $$ inside of the subshell
#             -- $BASHPID inside of the subshell

Solution 2

Subshells. $$ is specified by POSIX and always remains the value of the original shell process. $BASHPID is a Bash-specific variable, and is always the value of the process from which the variable is dereferenced, counting subshells.

 $ f() { printf '%s: %d, %d\n' "$1" $$ $BASHPID; };
 $ ${BASH_VERSION+shopt -s lastpipe}; set +m;
 $ f 1 >&2 | f 2
2: 31490, 31490
1: 31490, 32545

I did manage to convince the mksh maintainer to add BASHPID to the most recent version, so it is somewhat portable. It is also possible to implement BASHPID in ksh93 yourself on many platforms.

Comments

[mbaljeetsingh]

It should be noted that $BASHPID is new to BASH 4. If you are using BASH 3.x, you have to use $$

[The Quark]

Why using ${BASH_VERSION+shopt -s lastpipe} and not more simply shopt -s lastpipe?

[ormaaj]

@TheQuark Only bash has shopt, and only bash (and ksh93v-) have configurable "lastpipe" behavior, though their defaults are backwards. ${var+} isn't a particularly good mechanism either because it's being field split. It works alright for string literals with a known IFS when used at the top of scripts that aren't being sourced by other scripts.