exec'ing with relative pathname

[Robert Earl <chupchup@piggy.ucsb.edu>]

I reported this problem to Byron earlier, and since then I've realized
why he got different results than I did...

The rc manpage says this:

                                       The first word of  a  com-
     mand  is  the name of that command.  If the name begins with
     /, ./, or ../, then the name is used  as  an  absolute  path
     name  referring  to an executable file.  Otherwise, the name
     of the command is looked up in a table of  shell  functions,
     builtin  commands,  or as a file in the directories named by
     $path.

Now, say I have a binary in a temporary directory under the current
one, and I want to run it, I type in a command like

; tmp/foo

rc reports "tmp/foo not found" (for me)

According to the manpage, this isn't an absolute pathname and the
search in functions, builtins, and $path is done.  All other shells
seem to treat this just like

$ ./tmp/foo

which seems correct to me, mostly because the UNIX (and others :)
idiom `open("tmp/foo", ..)' wants to open a file relative to the
current directory.

Byron tested this out and told me it worked "right" for him (it found
./tmp/foo); but it occurred to me that maybe "." was in his path (it's
not in mine), which means yes, eventually the $path search matched
"./tmp/foo" and it found the command.  For me, it never even tried
"./tmp/foo"; it did try $home/bin/sun4/tmp/foo, $home/bin/tmp/foo,
/usr/local/bin/tmp/foo, ad nauseum.

sh's rule is worlds simpler than rc's, and I don't see any reason not
to make rc do the same:

                                   If the command name contains a
     / the search path is not used.  Otherwise, each directory in
     the  path  is  searched for an executable file.

What does everyone else think?



robert earl		rearl@piggy.ucsb.edu
ella megalast burls forever