From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from oldp.astro.wisc.edu ([128.104.39.15]) by hawkwind.utcs.toronto.edu with SMTP id <2223>; Tue, 18 May 1993 13:01:19 -0400
Received: by oldp.astro.wisc.edu (5.65/DEC-Ultrix/4.3)
	id AA22461; Tue, 18 May 1993 12:01:05 -0500
Message-Id: <9305181701.AA22461@oldp.astro.wisc.edu>
To:	rc@hawkwind.utcs.toronto.edu
Subject: A delicious thought
Date:	Tue, 18 May 1993 13:01:04 -0400
From:	Alan Watson <alan@oldp.astro.wisc.edu>
X-Mts: smtp

rc keeps everything in the environment (other than its flags and at
least until noexport arrives), so there is almost no need for any
built-in commands whatsoever: simply, exec a command which performs the
`built-in' and then have that command exec another rc, e.g.:

	; fn cd { exec not-built-in-cd $* }
	; cat `{ whatis not-built-in-cd }
	#! /bin/sh
	cd ${1+$"$@"}
	exec rc
	;

Flags like `-x' don't get carried over, but otherwise this seems like a
complete functional replacement of cd (and, likewise, limit, wait, and
umask).  Of course, if you really wanted to do this, you'd probably code
up the not-built-ins in C.

All of this is somewhat academic, but if someone DID want to add a new
built-in (or, rather, something which had to function in the same
process as rc), this would be an obvious solution.  To me, this is a
strong argument in favour of placing the flags in the environment (or,
at least, what they can be read into the environment) and against
noexport (or, at least, against a no export which cannot be easily and
temporarily over-ridden).

Once again, rc's clean design and the original philosophy of putting
everything into the environment seems to be paying off dividends.

Alan.

P.S. A free email message to the first person to publicly claim that
they really do want to exec twice just to change directory (limit is a
more obvious candidate to go to a not-built-in implementation --
wouldn't you like to get one more piece of #ifdef-ed code out of the
source?).