From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from stolaf.edu ([130.71.128.8]) by hawkwind.utcs.toronto.edu with SMTP id <2706>; Thu, 4 Jun 1992 08:14:39 -0400
Received: from mari.acc.stolaf.edu by stolaf.edu (4.1/SMI-4.1)
	id AA04151; Thu, 4 Jun 92 07:14:19 CDT
Date:	Thu, 4 Jun 1992 08:14:19 -0400
From:	quanstro@stolaf.edu (Erik Quanstrom)
Message-Id: <9206041214.AA04151@stolaf.edu>
Received: by mari.acc.stolaf.edu (4.1/SMI-4.1)
	id AA03329; Thu, 4 Jun 92 07:14:18 CDT
To:	rc@hawkwind.utcs.toronto.edu
Subject: re: $pid

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.