On Thu, Jan 7, 2010 at 10:05 PM, Adam Thompson <athom...@athompso.net> wrote:
> In article <20100104163847.gc1...@fuckup.hcl-club.lu>, j...@hcl-club.lu
...
>> Here's a exerpt from HandleSpawnTerminal() in xenocara/app/xterm/misc.c:
>>
>> /*
>> * Determine the current working directory of the child so that we can
>> * spawn a new terminal in the same directory.
>> *
>> * If we cannot get the CWD of the child, just use our own.
>> */
>> if (screen->pid) {
>> char child_cwd_link[sizeof(PROCFS_ROOT) + 80];
>> sprintf(child_cwd_link, PROCFS_ROOT "/%lu/cwd", (unsigned long)
screen->pid);
>> child_cwd = Readlink(child_cwd_link);
>> }
>>
>> So it obviously tries to access procfs to get that value. Is there a way
>> to access the same value via the OpenBSD API?
...
> Other than that, it's certainly possible to do it, as the fstat(1)
> command can do it from userland. fstat(1) accomplishes this through
> kvm_openfiles(3) and kvm_getfile2(3).
Look more closely: fstat doesn't actually show the path to the
process's working directory. The problem is that the kvm (and sysctl)
interfaces don't provide access to the file's path. You get the dev_t
and ino_t values and the mount-point, but getting the path from that
requires scanning the entire tree.
(Hmm, add a field to kinfo_file2 and have the KERN_FILE2 sysctl() call
vfs_getcwd_common() for each file? That could get real expensive...)
Philip Guenther
