Xref: utzoo comp.unix.wizards:8437 comp.sources.d:2099
Path: utzoo!attcan!uunet!husc6!bloom-beacon!athena.mit.edu!wesommer
From: wesommer@athena.mit.edu (William Sommerfeld)
Newsgroups: comp.unix.wizards,comp.sources.d
Subject: Re: Finding where an executable was run from -- a proposal.
Message-ID: <5307@bloom-beacon.MIT.EDU>
Date: 12 May 88 23:33:05 GMT
References: <67@uvaarpa.virginia.edu> <6800012@cpe> <4527@hoptoad.uucp> <9987@tekecs.TEK.COM>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: wesommer@athena.mit.edu (William Sommerfeld)
Organization: Massachusetts Institute of Technology
Lines: 36

In article <9987@tekecs.TEK.COM> andrew@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@athena.mit.edu