Rc does not update $pid when it forks, only when it is initalized. Consider ; @{echo $pid} 296 ; echo `{echo $pid} 296 ; echo $pid 296 If this is not a bug, then it is certianlly a poor feature. [but, then again sh is guilty of the same.]
Easily fixed, I think; apply the following patch to wait.c. Corrections by those more widely read in rc internals than me gladly welcome. - cks *** /tmp/,RCSt1a17852 Wed Jun 3 19:48:00 1992 --- wait.c Wed Jun 3 19:46:06 1992 *************** *** 44,49 **** --- 44,50 ---- /* NOTREACHED */ case 0: forked = TRUE; + varassign("pid", word(nprint("%d", getpid()), NULL), FALSE); SIGCHK; return 0; default:
I don't think echo `{ echo $pid } should be different from echo $pid because I don't really want know that backquote substitution requieres a fork(2). Of course, shell functions and explicit subshell commands "@{ .. }" should. Malte.
Malte (9206041005.AA01785@dahlie.techfak.uni-bielefeld.de> writes
>I don't think echo `{ echo $pid } should be different from echo $pid because
>I don't really want know that backquote substitution requieres a fork(2).
>Of course, shell functions and explicit subshell commands "@{ .. }" should.
$Pid should always mean the _current_ pid (as per the td's paper and
rc's man page), whatever the implementation demands that that me. If
this is not the case, then a script like
@{ kill -9 $pid }
will _not_ behave like a seperate shell, the whole idea behind @ ...
in the first place. This is bad.
As to the case of backquoting it seems to me a little less clear that
changing the pid is the right thing to do. But I still have several
reasons for wanting $pid to change. First inconsistency is not a nice
thing. Second, it eliminates the difference between the percieved [sic?]
behavior of
echo `{exit} (1)
which does _not_ kill the shell and
echo `{kill -9 $pid} (2)
which does. Such quirks are really not nice to have around: they cause
confusion and cause too much dependence on implementation. Consider an
implementation which did not fork (perhaps in the Plan 9 environment).
Perhaps $parent should be introduced, being the pid of the rc which is
forking off this, that and the other thing. But to be honest, I am not
yet clear how to resolve all the complecations of this.
> $Pid should always mean the _current_ pid (as per the td's paper and
> rc's man page)
as per what?
quoting from the v10 manual page:*
``$pid set during initialization to rc's process id.''
quoting from Tom Duff's UKUUG paper, section 26, paragraph 3:
``... $pid, initialized by rc to its process-id...''
in my opinion, rc's current implementation (which matches the above description)
is the more useful version. remember, folks, what the most common use of $pid is:
naming of temporary files to avoid collisions. now, if i want to keep referring
to /tmp/foo.$pid, i should be able to w/o doing
tmp=/tmp/foo.$pid
and being careful to watch for $pid changing.
two other reasons i can think of for keeping pid the same:
(1) the bourne shell did it this way and nobody complained
(2) the other interpretation can be acheived with a c program getppid:
#include <stdio.h>
extern int getppid(void);
int main(void) {
printf("%d\n", getppid());
}
but nobody's felt the need yet to do this.
----
* this is actually from a version of the v10 manual page that may have
preceded the printed manuals. i don't have that version handy.
what i forgot to say in my previous note is that the rc.1 that ships with Byron's rc should be updated to be more precise about what $pid means.
This is not a bug. Byron thought about this carefully. Do you really want whatis pid and whatis pid >file to give different pids? That would be one awful consequence of having $pid behave in the way some have been suggesting recently. Now I agree that this is confusing at first, and I will stand 100% behind any proposal to change rc.1 to explain this more fully. But please, _don't_ change the code. I append the mail Byron sent me when I asked him about this. OK, John. From: Byron Rakitzis <byron@archone.tamu.edu> Date: Thu, 23 Jan 1992 13:54:56 +1100 To: john@vetsci.su.oz.au Subject: Re: rc file descriptor bug Received: from archone.tamu.edu ([128.194.53.42]) by doolittle.vetsci.su.oz.au with SMTP id <49478>; Thu, 23 Jan 1992 14:28:45 +1100 Received: by archone.tamu.edu id <18895>; Wed, 22 Jan 1992 20:55:01 -0600 Message-Id: <92Jan22.205501cst.18895@archone.tamu.edu> $pid is not EXPORTED. Note that this is much different from saying that a subshell of rc has $pid wiped out of its hash table. $pid obeys the following property: ~ $pid `{echo $pid} is true. Do you think it should be otherwise? How about another variable, like $ifs. Do you think that ~ $ifs `{echo $ifs} should be different? (assuming for the moment that the ~ command I wrote is just a convenient way to test the two values) I guess the easiest way to think of this is to notice that $pid never makes its way into the envp argument of an execve. Other than that, it is kept around in rc's data structures.