From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from relay2.UU.NET ([137.39.1.7]) by hawkwind.utcs.toronto.edu with SMTP id <2628>; Wed, 24 Jun 1992 15:19:23 -0400
Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA07279; Wed, 24 Jun 92 15:19:17 -0400
Received: from srg.UUCP by uunet.uu.net with UUCP/RMAIL
	(queueing-rmail) id 151853.25523; Wed, 24 Jun 1992 15:18:53 EDT
Received: from ceres.srg.af.mil by srg.srg.af.mil
	id aa06331; Wed, 24 Jun 92 15:10:36 EDT
From:	culliton@srg.af.mil (Tom Culliton x2278)
X-Mailer: SCO System V Mail (version 3.2)
To:	rc@hawkwind.utcs.toronto.edu
Subject: Command execution
Date:	Wed, 24 Jun 1992 15:10:38 -0400
Message-Id: <9206241510.aa06947@ceres.srg.af.mil>

Heres a minor annoyance/inconsistency with Byron's rc that I noticed
way back when I first started using it but never bugged me until now.

Tom Duff[1] says that in executing commands rc first looks for a
function of the given name, then a builtin commands, then if the name
CONTAINS a '/' it is taken as a path to an executeable, otherwise it 
searchs for an executable of that name using the path.

This implies a couple of things which I believe are desirable.  First,
the function: "fn csh /bin/csh { echo 'You''ve got to be kidding!' }"
should be a legitimate and useful definition.  If you really want to
get to csh you can still say "builtin csh".  (Unless of course builtin
has been overloaded...)  Currently "/bin/csh" will not invoke the
function.

Second, the commands "./bin/thingee" and "bin/thingee" should be
treated consistently, and not behave differently, based on the path or
function definitions.  Currently if you remove "." from your path
"bin/thingee" will not be treated as a path name, and "bin/thingee"
will invoke a function but "./bin/thingee" will not.)

Unfortunately Byron[2] changed these rules somewhat, so that his rc
FIRST checks if the command STARTS with "/", "./", or "../" in which
case it is taken as a path to an executeable, before going on to check
functions, builtins and the path.  This means that the function
"/bin/csh" will never be seen and that "./bin/thingee" is quite
different from "bin/thingee".

"Fixing" this should be trivial, in the one case changing the order of
checks and in the other checking using strchr(cmdname, '/').  However I
assume Byron had a reason for this.  Any comments?

Tom

[1] "Rc - A Shell for Plan 9 and Unix Systems", page 6, section 17 
[2] "RC(1)" (Byron's man page), page 1, section "Commands"