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 <2749>; Sat, 4 Sep 1993 18:10:53 -0400
Received: by oldp.astro.wisc.edu (5.65/DEC-Ultrix/4.3)
	id AA13356; Sat, 4 Sep 1993 17:10:50 -0500
Message-Id: <9309042210.AA13356@oldp.astro.wisc.edu>
To:	rc@hawkwind.utcs.toronto.edu
Subject: RCRC
Date:	Sat, 4 Sep 1993 18:10:49 -0400
From:	Alan Watson <alan@oldp.astro.wisc.edu>
X-Mts: smtp

Although we have all worked out our own favorite work-arounds for the
rsh problem, I think I've come up with an rc specific solution which is
quite elegant:

	During start-up, rc examines the environment variable RCRC.  If
	the variable is set, rc attempts to source the file to which it
	refers; otherwise it sources .rcrc.  Before sourcing the file,
	rc sets RCRC to be the null string.  If the attempt to source
	the file fails, rc does not report an error.

So what happens in some common situations?

	login: RCRC is unset, so rc sets it to "" and sources .rcrc.

	rsh: ditto.

	exec of rc from beneath a login/rsh shell: RCRC is set to "",
	so the open() fails and nothing gets sourced.

All this seems to cost us in performance terms is a getenv() and open()
after each exec, and I very much doubt anyone will notice that.  We
gain a useful improvement in rc's interaction with the rest of UNIX,
and open up an interesting means to customize environments (by setting
RCRC in .rcrc).

Some things will break (like running rc in a clean environment from
env), but I can't think of anything too important.  

If you don't like the silence on error, then have rc set RCRC to
/dev/null before sourcing the file it points to.

Any comments?