>> 
>>    I'm not sure what to do about this state of affairs.
>> 
>> My solution to this particular problem would be to add the features
>> you want to our own fstat(8), and not bother with lsof.
>
>In this case I don't agree; this smacks of Not Invented Here syndrome.

I think that perhaps the argument was that it would be generally more useful
to have the abilities of lsof built into the OS, and since fstat is most of
the way there already then it would make sense to port lsof's abilities
to fstat.

>I don't know the origins of fstat(8), but lsof is a more mature program,
>it provides more useful information than fstat(8), and it is ported to a wide 
>variety of O/S platforms.

As for being more mature, I remember the days when lsof was just one monster
source file.  The distribution has been cleaned up since then, but to be
honest I always thought lsof was one of the more disorganized packages
available out on the net.

And for it being ported to a wide variety of platforms, the only platform we
care about is netbsd, eh? :-)

But, to be fair to lsof, it does provide a heckofalot more information than
fstat.  lsof looks up the address of the tcb control block, so instead of
getting this:

kenh     rlogin       450    3* internet stream tcp f8883500

you'll get this:

rlogin      453     kenh    3u  inet 0xf8883500        0x0    TCP excalibur.cmf.
nrl.navy.mil:1023->picard.cmf.nrl.navy.mil:login

(But the SOCKETS section of man page for fstat says that they purposely did
not want to duplicate the use of netstat).

Also, lsof allows you to easily find out the pid of a process listening on
a certain port, making it a great security tool.

lsof also shows all the txt references for objects, including shared libraries,
which as far as I know fstat doesn't do.  lsof also gives you file size and
the current value of the file offset for that descriptor.

--Ken