On Thu, 6 Apr 2006, Mike Hearn wrote:> > IMO the program must be aware of the get-my-exedir feature, just configuring> > --prefix=/proc/... is aiming for your feet.> > I disagree, though /proc/self/exedir may not be the right answer. The > problem with the original proposal is there's no concept of a group > leader to which files are resolved relative to so there is this problem > with child processes.The problem ist the word 'the'. If parent and child are using 'the foo',they will clash.> I sent a mail outlining a scheme that used file descriptor passing to > achieve the same effect but with the needed "inheritance" of the path, > but, vger seems to have munched it! At least I don't see it on the gmane > archives. But the scheme is simple enough:> > * get_prefix() reads /proc/self/exe and turns it into the correct> directory> > * dup2(open(get_my_exedir()), 999)>> * ./configure --prefix=/proc/self/fd/999bin/foo calls bin/bar refering to /proc/self/fd/999bin_2/bar does dup2(open(get_my_exedir()), 999) ***FUBAR***possible solution:don't dup2, and only close fds you opened yourself.Disadvantage: Leaky (too), may break scripts..oO(Can you chroot a single filedescriptor or somehow make /proc/self/fd/$n/.. be unavailable?)> It also restricts the problem to passing paths to other processes that > are not subprocesses (eg via rpc). But as each process can have its own > namespace this will always be an issue that needs careful treatment, and > the pain of adjusting software to realpath() it is much lower than > modifying every path in every piece of software. That approach was > already tried and sucks.There may be no "real path" corresponding to /proc/self/fd/4711.IMO it's still best to just symlink the program directory to the correct place and make the programs search in e.g. ~/opt/ and /opt/.-- Fun things to slip into your budgetAn abacus-To unsubscribe from this list: send the line "unsubscribe linux-kernel" inthe body of a message to majordomo@vger.kernel.orgMore majordomo info at read the FAQ at