Command execution

Command execution

[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"

Re: Command execution

[Chris Siebenmann]

 Duff's rc lets you define a function that looks like a full path, and
running the full path will run the function (ie, fn /bin/csh ...). I
don't think this is a good idea myself; the uses seem limited to trapping
standard programs when invoked by explicit paths, and I see more problems
as a result than solutions. Contrary to the documentation, Duff's rc
and Byron's behave the *same* for 'foo/bar', and at least Rob Pike a)
thinks this is a good thing and b) uses this feature.

	- cks

Re: Command execution

[Tom Culliton x2278]

cks> 						if you invoke the absolute
cks> path name, you *mean* the absolute path name.

I can still imagine ways that it might be useful, but no big deal.

cks>  'x/y' vs. './x/y' has been hashed out before in the mailing list;
cks> check the archives. I belive Pike just considered it the right
cks> approach. I use it for the same sort of things that David Moore does;
cks> to keep infrequently-used stuff off my path.

I probably missed it, having only been on the mailing list since early
December.  It could definitely be made clearer in the man page,
especially since it's rather different from most shells.

Re: Command execution

[Chris Siebenmann]

[trapping regular absolute program names with function names:]
| This was exactly what I wanted to do.  One of my friends likes to run a
| couple of obnoxious programs on my workstation when he drops by to
| visit and I'm not in the office.

 This sounds like a social problem, not a software problem; if it's
really that bad, patch your own version of rc a bit. I wouldn't want
to twist the main rc version to do this; if you invoke the absolute
path name, you *mean* the absolute path name.

 'x/y' vs. './x/y' has been hashed out before in the mailing list;
check the archives. I belive Pike just considered it the right
approach. I use it for the same sort of things that David Moore does;
to keep infrequently-used stuff off my path.

- cks

Re: Command execution

[David Moore]

Tom Culliton writes:
 
| >>				Contrary to the documentation, Duff's rc
| >> and Byron's behave the *same* for 'foo/bar', and at least Rob Pike a)
| >> thinks this is a good thing and b) uses this feature.
| 
| This iregularity troubles me more, but thats just because odd little
| gotchas set my teeth on edge, and in almost any other unix context
| "x/y" is identical to "./x/y".  Could you say more about why Pike
| thinks this is good and what you would use it for?

	I use this all of the time.  At first I found it strange that
'x/y' wasn't './x/y' but I quickly retrained.  Also, I don't have '.'
in my path so I'm well used to using './' in front of things as needed.

Now, the reason I use this.  I some subdirectories of binaries that I
use occasionally, but don't want to pay the performance hit of leaving them
in my path.  Also, I just don't want them in my path because of some name
conflicts with std programs.

Example: I do have '/usr/local/bin' in my path.  If I want to run the
file '/usr/local/bin/cap/atlook VA', as I do once or twice a week, I
just do 'cap/atlook VA' and it does it.  I find this very convenient
and I like it better than having a function named 'atlook' which
knew where to go.

I currently have a hosts directory of machines I log into also.  I've been
thinking of removing this from my path, and just using 'hosts/foo' to get
to them.

| Tom


David

--
David Moore <dmoore@ucsd.edu> - SysAdmin/Programmer
UCSD | Dept. of Anesthesiology | V-151 | La Jolla, CA 92093-9151
Work Phone: (619) 552-8585 x7042
"God does not play dice." - A. Einstein		"Yes, I do." - D. Moore

Re: Command execution

[Tom Culliton x2278]

>>  Duff's rc lets you define a function that looks like a full path, and
>> running the full path will run the function (ie, fn /bin/csh ...). I
>> don't think this is a good idea myself; the uses seem limited to trapping
>> standard programs when invoked by explicit paths, and I see more problems
>> as a result than solutions.

This was exactly what I wanted to do.  One of my friends likes to run a
couple of obnoxious programs on my workstation when he drops by to
visit and I'm not in the office.  Since they're coming from the file
server's shared bin directory a function seemed like a good way to
interdict them.  I can also see other uses to transparently stick a
front end on something, say to translate command line options from one
form to another.  In any case, it was a fairly minor quibble.

>>				Contrary to the documentation, Duff's rc
>> and Byron's behave the *same* for 'foo/bar', and at least Rob Pike a)
>> thinks this is a good thing and b) uses this feature.

This iregularity troubles me more, but thats just because odd little
gotchas set my teeth on edge, and in almost any other unix context
"x/y" is identical to "./x/y".  Could you say more about why Pike
thinks this is good and what you would use it for?

Tom