Difference Between Bash Pid and $$

Difference between bash pid and $$

Looking at documentation on this, it looks like:

1. $$ means the process ID that the script file is running under. For any given script, when it is run, it will have only one "main" process ID. Regardless of how many subshells you invoke, $$ will always return the first process ID associated with the script. BASHPID will show you the process ID of the current instance of bash, so in a subshell it will be different than the "top level" bash which may have invoked it.
2. BASH_SUBSHELL indicates the "subshell level" you're in. If you're not in any subshell level, your level is zero. If you start a subshell within your main program, that subshell level is 1. If you start a subshell within that subshell, the level would be 2, and so on.
3. BASH_SUBSHELL is a variable.
4. Maybe BASHPID isn't supported by the version of bash you have? I doubt it's a "Mac" problem.

Why is $$ returning the same id as the parent process?

$$ is defined to return the process ID of the parent in a subshell; from the man page under "Special Parameters":

$ Expands to the process ID of the shell. In a () subshell, it expands to the process ID of the current shell, not the subshell.

In bash 4, you can get the process ID of the child with BASHPID.

~ $ echo $$
17601
~ $ ( echo $$; echo $BASHPID )
17601
17634

Comparing PID's in bash

A single equals sign is used to compare strings (if [ $pid = $tmp ]).

How can a Linux/Unix Bash script get its own PID?

The variable $$ contains the PID.

What is the difference between a Process' pid, ppid, uid, euid, gid and egid?

In order:

• pid: The is the process ID (PID) of the process you call the Process.pid method in.
• ppid: The PID of the parent process (the process that spawned the current one). For example, if you run ruby test.rb in a bash shell, PPID in that process would be the PID of Bash.
• uid: The UNIX ID of the user the process is running under.
• euid: The effective user ID that the process is running under. The EUID determines what a program is allowed to do, based on what the user with this UID is allowed to do. Typically the same as uid, but can be different with commands like sudo.
• gid: The UNIX group ID the program is running under.
• egid: Like euid, but for groups.

what's the difference between /proc/self and /proc/$$?

$$ is a special bash variable that gets expanded to the pid of the shell.

/proc/self is a real symbolic link to the /proc/ subdirectory of the process that is making the call.

When you do ls /proc/$$ the shell expands it to ls /proc/pid-of-bash and that is what you see, the contents of the shell process.

But when you do ls /proc/self you see the contents of the short lived ls process.

The $$ is not limited to this usage, you can write echo $$ to see the bash pid; you can use it to kill yourself, etc.

$$ in a script vs $$ in a subshell

I tried and escaping (to pass the $$ to the subshell) does not work as the subshell inherits the $$ value from the parent bash. The solution to this is to use $BASHPID.

(echo $$; echo $BASHPID)

prints the PID from the parent shell and from the subshell.

What does $$ mean in the shell?

In Bash $$ is the process ID, as noted in the comments it is not safe to use as a temp filename for a variety of reasons.

For temporary file names, use the mktemp command.

PID consistency between c++ and $! variable in bash

After

bash $1 &

$! is the pid of the bash child process. Presumably, $1 (something.run) is a script which ends up running the C++ program as a child, but that child process will be yet another pid.

You might be able to modify your .run file to exec the C++ program instead of spawning a child, but that will only work if you don't need to do anything in the .run file afterwards.

Another relatively simple solution is to generate a subprocess count in your driver loop, and pass it through the .run file to the C++ program, which can then use it as a tag in log messages. That has the advantage of allowing the log messages to come from various different programs, if that is useful.

Yet another simple solution is to output all logging information from your C++ program to stderr. Then the .run script which actually calls the program can redirect stderr to a log file created using $$ -- the pid of the .run script -- which will be the same as $! in the driver.

---

Related Topics