How to get filename of an open file descriptor

Skip Ford skip at menantico.com
Fri Nov 16 12:40:20 PST 2007


Robert Watson wrote:
> On Wed, 14 Nov 2007, Skip Ford wrote:
> 
>>>I agree regarding the duplication with ps(1) -- however, I'm generally of 
>>>the opinion that ps(1) is overburdened as tools go, and that the goals 
>>>are actually somehwat different--procstat(1) intentionally doesn't have 
>>>the ability to generate a list of processes, for example, taking pids 
>>>explicitly as the argument; likewise, historically ps(1) has not been 
>>>interested in printing more than one line per process (although I think 
>>>-h changed this). I'll do a bit more investigation as to how easily it 
>>>can be wedged in, and do recognize the concern here.
>>
>>I understand, and I sort of knew that from the beginning which is why I 
>>didn't provide feedback immediately.  I don't have a suggestion as to what 
>>I think should be done.
>>
>>While procstat(1) currently takes a list of pids, I wouldn't be surprised 
>>if somebody adds code to list all processes, unless you block it.  I think 
>>it would be useful, especially since some of it's options produce 
>>single-line per pid output, such as credentials.
>>
>>The two utilities do provide different information, it's just a little odd 
>>to have two utilities with basically the same name.  But I can't think of 
>>a more appropriate name for procstat(1).
> 
> FWIW, it looks like on Solaris, there are a series of psig(1), pstack(1), 
> ptree(1), etc, tools for similar sorts of per-process inspection purposes.  
> I think I prefer bundling it into a single tool, but it's certainly a 
> similar idea.  Maybe I should just rename procstat(1) to pinfo(1) and be 
> done with it?

Either of those options works for me.  If I were the first person
ever to make the decision, I'd go with pinfo(1).

However, Linux doesn't have separate utilities like Solaris but does 
have a procinfo(8) utility in addition to their ps(1).  Their procinfo(8)
displays system status as gathered from procfs.  In other words, anything
that's not process related that's available via procfs gets displayed
with procinfo(8).

So, needless to say, it isn't per-process like ours would be nor does it
provide anywhere near the same type of information as pinfo(1) currently
(or ever) would:

http://www.linuxcommand.org/man_pages/procinfo8.html

So, even though the Solaris way of separate utilities seems like
overkill to me, that's what I'd vote for following.

If that's what you decide should be done and you want a hand, I
can do the work.  Just let me know the names of the utilities and
supply Solaris manpages if they have matching commands, and I can
convert your code so you can be working on bigger and better things.

But, again, even pinfo(1) would be better than procstat(1) to me
so if that's what you decide, I don't have a problem with that.
At least our two utilities wouldn't have essentially the same
name.

-- 
Skip


More information about the freebsd-hackers mailing list