exec'ing with relative pathname

exec'ing with relative pathname

[Robert Earl]

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

Re: exec'ing with relative pathname

[Chris Siebenmann]

 This behavior matches the Plan 9 rc, and at least Rob Pike considered
it the right thing to do (when overheard at Usenix). It can be debated,
but given that Plan 9 rc does it that way I think we should as well.
It does have a certain charm and occasional elegance. For example,
we have a /local/bin/urep directory for UREP commands, but I don't
have it on my path; this way I can type 'urep/cmd' and it'll wind up
executing the right thing.

	- cks

Re: exec'ing with relative pathname

[Donn Cave]

The Bourne shell behavior seems simpler to explain and, nine times out
of ten, more useful.  Maybe someone who's more familiar with Plan 9
could provide some insight into this odd design choice?

	Donn Cave, University Computing Services, University of Washington
	donn@cac.washington.edu