This is not the same as a few of the other posted items dealing with sub-process pids (that I saw anyway).
If zot contains:
echo "main mypid: $$ - lastpid: $!"
(
echo "block mypid: $$ - lastpid: $! - ppid: $PPID"
ps -ef > xxx
sleep 5
echo "block mypid: $$ - lastpid: $! - ppid: $PPID"
) &
echo "main mypid: $$ - lastpid: $! - ppid: $PPID"
sleep 6
Then: ksh zot (under Solaris and MKS) results in:
main mypid: 7318 - lastpid:
block mypid: 7318 - lastpid: - ppid: 607
main mypid: 7318 - lastpid: 7320 - ppid: 607
block mypid: 7318 - lastpid: - ppid: 607
It surprises me that in the forked child process, that $$ still returns the pid of the main process. i.e. both show $$ as 7318 - I would have expected the child to have $$ be $7320. (You can ignore the ppid - I was looking at related notions.)
If you do: "grep 7320 xxx" you get:
root 7320 7318 0 13:59:45 pts/9 0:00 ksh zot
root 7321 7320 1 13:59:45 pts/9 0:00 ps -ef
which clearly shows the child process and if you were to "kill -9" that pid before the 5 seconds runs out, you would not get the second block line.
My intention was for the child process to record its own pid rather than the parent doing it on its behalf. I realise that the parent can use $! but why can the child not use $$ for its own PID? By the way, if you extract the block of code and put it in a separate file and call it, then you get the expected results.
Thank you in advance for any insights.
Michel
ksh compiles the code and then executes it. The $$ is gone long before the fork occurs. So replace the ( stuff ) notation with
ksh -c "stuff"
Not a great solution, but it works.
Then how would the following ever work:
xxx=$(date)
( sleep 5
xxx=$(date)
echo $xxx
) &
echo $xxx
if $xxx were coerced when the (...)& is being scanned, then the two echo statements would always show the same time but they don't (you can try it). Are you suggesting that $$ is coerced by different rules than $xxx?
Yes. Special parameters and named parameters are different. I would post some sample code to prove this, but you you beat me to it. 
Thanks for the insights.
I do find the behaviour borderline nuts presuming different rules for coercing variables.
An arguably valid definition I can think of as an alternate is that "$$" is by definition the initial shell's PID as opposed to the current process's PID, independent of sub-shells much like PPID is the parent of the initial shell regardless of being in a sub-shell or not. This is consistent with a few ksh man pages I dug up though not obvious.
It also seems to be consistent with a few experiments I tried with "eval" with a composite string that results in "$$" which would preclude the initial parsing of the (....)& from coercing a manifest $$ and that also produced the same result.
That ksh treats a subshell differently from a forked instance of ksh is consistent with other aspects of behaviour (e.g. variables need not be exported to be seen by a sub-shell) but it sure messes up the notion of using inline code vs external scripts in any consistent manner.
I will derive an alternative strategy (messing with ps -ef is not an option because my code needs to run under Solaris and Windows/MKS wherein ps differs due to the information about process parameters maintained by Windows).
Thanks again.
Michel
A better way to think about it is that "subshell" is not guaranteed to be a new process. Look carefully at the definition of ( ) and you find "separate environment" rather than "new process". As long as no side effects propogate into the parent environment, it could be done without a fork and forking is expensive. So this leaves the door open for faster implementations. Also Dave Korn wanted ksh to be universal and some OS's do not allow fork(). (They may have a spawn() which is like a fork()/exec() combo or something like that.)
Anyway, I thought of a way to do it...I think. Background the subshell. Have the parent obtain $! and send it into the subshell via a named pipe. Then the parent waits for the subshell to exit. 
if the subshell that is spawned is sent to the background process group,
there are subtle points to be noted:::
if the subshell is interactive one and if it has to be switched to foreground process group and that must be explicitly done by the parent and it cannot do that by itself; only thing that could be done by the child itself is being stopped by generating SIGTTIN/SIGTTOU
if the subshell is non-interactive, care must be taken that the subshell should not support any of the job control activities.