In article <9n24q2$j09$1 at pegasus.csx.cam.ac.uk>,
<jkb at mrc-lmb.cam.ac.uk> wrote:
>>However ignoring this stuff, my personal choice is simply to use system()
>(assuming it's not setuid and so security isn't an issue) or execlp() to run
>programs and let the users set up their PATH correctly.
>
I agree.
>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.
And here!
>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.
Have you ever looked at the sources for lsof? :-) Most of the things
it does are completely system-specific. Many of these things are
not portable even between versions of the same OS; for example you can
do what you want here really trivially on Linux 2.2 or later through
/proc/$pid/fd/$fd, which is a symbolic link to the file the descriptor
has open. Linux 2.0 and earlier just have an inode number, I think.
A few years ago the author of lsof had to drop support for IRIX, because
SGI were refusing to supply him with kernel struct details he needed.
Don't know whether that's still the case.
Sigh. UNIX can be really horrible at times, can't it? I seem to have
opened a can of worms here. Sorry!
Tim.
--
"It is the job of Sales and Marketing to insulate those who know what
they're talking about from each other"
-- I know who said this, but I'm not telling.
