Finding where an executable was run from -- a proposal.

[William Sommerfeld]

In article <9987 at tekecs.TEK.COM> andrew at frip.gwd.tek.com (Andrew Klossner) writes:
>[]
>
>	"This would make lots of application programs easier to
>	install; you just copy it into somewhere on your PATH and it
>	will run."
>
>If an application uses this scheme to find its associated files, some
>useful Unix idioms cease to work.  For example, say that "rn" lives in
>/usr/news, but I don't want /usr/news in my PATH (too many nasty
>commands are also there).  At present I can put a link to /usr/news/rn
>in a directory that is in my path (e.g., my local bin).  With the
>proposed scheme, that would cause rn to look in my_local_bin/lib/* for
>its data files instead of in /usr/news/lib/*.

I remarked (in private mail) to John Gilmore that what he described
was very similar to the Multics referencing_dir mechanism. If it's
done right, the application gets passed its _real_ absolute pathname,
after all the symlinks have been chased.

While I'm here, I might as well lobby for support for a library
function/system call which canonicalizes a pathname, chasing all the
links and turning it into an absolute pathname.  abs_path(".", buf) should
be equivalent to getwd(buf).  It was useful on Multics.  It would be
very useful in some cases on UNIX.

While normally I am opposed to creating new system calls, a reasonable
implementation of abs_path in user code (assuming it didn't "cheat"
and use chdir()) would most likely be O(n**2) in terms of directory
lookups, whereas a version inside the kernel would be O(n).  (Of
course, you could always do what was done in both Amber and AEGIS:
move namei() or its equivalent out of the kernel and into a shared
library..)

				Bill Sommerfeld
				wesommer at athena.mit.edu