RCRC

RCRC

[Alan Watson]

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?

Re: RCRC

[Chris Siebenmann]

 My .rcrc produces output; sourcing it on rsh will thus produce
errors from things like rdist and rcp. Rsh is different from
a login; treating them the same is a mistake.

	- cks

Re: RCRC

[John Mackin]

I am afraid I think Alan's idea is terrible.  You said it yourself, Alan:
`[W]e have all worked out our own favorite work-arounds for the rsh problem.'

The problems with this idea are several-fold.  Firstly, and least seriously:
you're adding overhead on every rc startup in order to see whether something
needs to be done that will only happen a tiny minority of times.  Yes, the
added overhead is small.  It's still there.

Secondly, I add my voice to Chris's objection: rsh is different from a
login.  The _correct_ solution to this problem is simple: a wrapper
around rsh.

Thirdly, and more seriously, the proposal involves changing rc's code,
and the semantics of its startup.  This is bad.  We should need a
_tremendously_ good reason to make any such changes to rc at this
late stage: its semantics should be viewed as set in stone, or as
close to it as makes no difference.  I hardly think any imagined
payoff here can be worth the price.

Fourthly, lastly and the final nail in the idea's coffin: it's not
portable and cannot be made portable.  [I'm surprised, Alan, that
someone with your extensive knowledge of UNIX history could make this
mistake.]  On _real_ (say, Seventh Edition) UNIX systems, attempts to
open the null string for read _succeed_, and open the current directory
(always assuming, of course, that the current directory's mode allows
it to be opened for read).  This is actually a logical necessity: the
degenerate non-rooted pathname must refer to the current directory.
Indeed, it even says it does in Thompson & Ritchie.  `Modern' UNIX
systems that call opening '' for read an error are broken.  Even if you
don't accept that, the fact that some systems _will_ open '' for read
means that there is NO pathname that you can use that you can guarantee
will not be able to be opened for read, if you want the code to be
portable.  (Please don't suggest opening it for write.  Yes, I know
that would `work,' if you call that working.)

Sorry, Alan, I can't go for this one.

OK,
John.

Re: RCRC

[Alan Watson]

I don't propose to treat them the same within .rcrc.  The rc that I
eventually exec from rsh sources my .rcrc at the moment, so I have the
following in my .rcrc:

   [set path, define fns, etc.]
   if ( test -t 0 ) {
      [set tty, check mail, etc.]
   }

There are many variations on this.  Yes, you will have to rewrite your
.rcrc, but I was assuming that most people were already using wrappers
around rsh or rc to source .rcrc.  Perhaps I was wrong.