jkb at mrc-lmb.cam.ac.uk wrote in message news:<9n24q2$j09$1 at pegasus.csx.cam.ac.uk>...
> In <3B936214.ECED52B0 at sanger.ac.uk> Ed Griffiths <edgrif at sanger.ac.uk> writes:
>> ...
> For C the sed statements mainly just boil down to a strrchrs. The symbolic
> link stuff uses ls in /bin/sh, but lstat is a better choice for C
Readlink(2) is the correct choice in C for resolving symbolic links.
> ...
> We try to have the policy of "if it works for you on the command line then it
> should work within our programs". This then covers not only PATH, but all
> those other quirky environment variables that some apps require.
> ...Indeed. I've always wanted the ability of finding the location of a file by an
> open file descriptor. Things like lsof seem to imply that this information is
> available in the kernel somewhere, but perhaps not on all Unixes.
With two exceptions -- Linux, and some versions of Tru64 UNIX --
lsof gets path name components from the kernel's DNLC (Dynamic Name
Lookup Cache). One system, AIX, denies lsof access to its DNLC.
Using the DNLC is a hit-or-miss proposition, since a busy system
will cause path name components cached in the DNLC to expire quickly.
In spite of that limitation, lsof often is fairly successful in
assembling path names. More information on lsof's path name assembly
may be found in the lsof FAQ.
Vic Abell, lsof author
