Command substitution. Spawned process name is identical to the parent one

Question

This script

$ cat csub.sh 
#!/bin/bash

while true;
do 
  sleep 5
  AVAR=$(date; sleep 2)
done 

when started, makes a process appear in the ps output:

ps -eLf|egrep '[c]sub.sh|PID'
UID        PID  PPID   LWP  C NLWP STIME TTY          TIME CMD
jimmy    31364 23445 31364  0    1 00:33 pts/7    00:00:00 /bin/bash ./csub.sh

which is quite predictable as well as the fact that $(date; sleep 2) spawns another process

Surprising is that the spawned process has identical CMD displayed

UID        PID  PPID   LWP  C NLWP STIME TTY          TIME CMD
jimmy    31364 23445 31364  0    1 00:33 pts/7    00:00:00 /bin/bash ./csub.sh
jimmy    31433 31364 31433  0    1 00:33 pts/7    00:00:00 /bin/bash ./csub.sh

I added sleep to be able to catch the process into the ps output, otherwise one have much less chances to, because it's too short. As you see the spawned process 31433 has 31364 as its parent. I would expect the spawned process has some different CMD mentioning what it deals with, e.g date or sleep command. For cases when there are multiple command substitutions, how could I distinguish them when I see a spawned process appeared?

Answer 1

From the manual page, section 2 for fork():

fork() creates a new process by duplicating the calling process. The new process, referred to as the child, is an exact duplicate of the calling process, referred to as the parent, except for the following points:

• The child has its own unique process ID, and this PID does not match the ID of any existing process group (setpgid(2)).
• The child's parent process ID is the same as the parent's process ID.
• The child does not inherit its parent's memory locks (mlock(2), mlockall(2)).
• Process resource utilizations (getrusage(2)) and CPU time counters (times(2)) are reset to zero in the child.
• The child's set of pending signals is initially empty (sigpending(2)).
• The child does not inherit semaphore adjustments from its parent (semop(2)).
• The child does not inherit record locks from its parent (fcntl(2)).
• The child does not inherit timers from its parent (setitimer(2), alarm(2), timer_create(2)).
• The child does not inherit outstanding asynchronous I/O operations from its parent (aio_read(3), aio_write(3)), nor does it inherit any asynchronous I/O contexts from its parent (see io_setup(2)).

Not on this list is the invocation command line of the process, so that will be identical to its parent. You can tell children apart from their parents because the child's PPID (Parent PID) will be the originating process's PID.