Command execution

[culliton@srg.af.mil (Tom Culliton x2278)]

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"