Date: Wed, 18 Dec 2024 13:56:48 -0800
From: Kaz Kylheku <k...@kylheku.com>
Message-ID: <c65ef8f1bf8bed7807f2110a9e916...@kylheku.com>
| The $$ parameter is expanded to a decimal numeric word
| *before* the while command is executed,
No it isn't.
| so the background process is referencing the correct PID of the parent.
But that is correct. $$ isn't the current pid, it is the pid of the
shell which is running everything (creating subshells does not change $$).
| There is no need to smuggle the PID through a variable.
| $$ in the while command will not refer to the child process'
Also both correct.
| That would be an issue if we had used eval:
| eval 'command ... $$ ...' &
But that's wrong, it would make no difference at all. Just try it:
jacaranda$ echo $$
15965
jacaranda$ eval 'echo $$'
15965
jacaranda$ echo $$ &
[1] 19884
jacaranda$ 15965
jacaranda$ eval 'echo $$' &
[1] 15869
jacaranda$ 15965
The [1] lines give the pids of the subshells created to run the commands.
Those differ. Yet the result of 'echo $$' does not. [Note in this
e-mail, I deleted the "Done" (jobs style) lines the shell outputs when
the background processes complete. They're not relevant to the issue.]
| now we backgrounded the eval, which then in the background
| process parses the shell syntax and does all the expanding.
Yes.
| Now $$ is the PID of the background process, not that of
| the shell which launched it.
No.
The only way to alter $$ is to start a whole new shell.
bash -c 'command ... $$ ...'
(run in background or foreground) will use a different value for $$
(that for the new bash process). Of course, if the command were
bash -c "command ... $$ ... "
then the $$ would be expanded before the new bash started, and so it
would refer to the invoking shell.
[As an aside, this is all true of all Bourne compatible shells, and
is specified to work like this by POSIX ... because that is how all
shells work, not because anyone necessarily thinks it is a great design.]
kre
