I need a list of the opened files, ports and so on by a process. Now whenever I use lsof -p <PID> I can parse the output, in a python script, but the problem is that sometimes I am getting some columns that are empty. Therefore I am getting bad results while parsing the output.

I know that I can manually look for the FDs in /proc for each process, but this has to be in POSIX standard. So my question is, is there anyway to make lsof print just the list of the opened files and nothing else?

I am thinking something like for example the user specific ps command (ps -eopid,user,comm,command), where we can specify what commands come in the output. In this case I want to specify only the 'Name' columns in the lsof -p <PID> output.

  • How about piping it through e.g. cut or awk for selecting the proper column and then parsing it?
    – FelixJN
    Commented Jul 29, 2016 at 9:35
  • did not try it with cut, but it does not work with awk, because it divides the columns based on the row, so for example in row that has Permission denied, I am just going to get the 'denied' part as an output Commented Jul 29, 2016 at 9:37
  • lsof is not a POSIX command. Commented Jul 29, 2016 at 9:46
  • It is not a POSIX standard? Then do you know any POSIX command that does the same? Commented Jul 29, 2016 at 9:48
  • 2
    The only (remotely) related command in POSIX is fuser, and it's optional (though required for Unix conformance, so often found). Commented Jul 29, 2016 at 10:22

1 Answer 1


lsof has a "post-processable" output format with the -F option (see the OUTPUT FOR OTHER PROGRAMS section in the manual).

lsof -nPMp "$pid" -Fn | sed '
  s/ type=STREAM$//; t end
  s/ type=DGRAM$//; t end
  s/ type=SEQPACKET$//
  : end

Will list open files that resolve to a path on the file system.

  • -nPM disables some of the processing that lsof does by default and which we don't care for here like resolving IP adresses, port or rpc names.
  • -p "$pid", specify the process whose open files to list
  • -Fn: by field output. Ask for the name part.
  • | sed post process with sed to select only the part we're interested in:
  • \|^n/|!d: skip anything that doesn't start with n/
  • s/ type=...$/;t end: remove those strings at the end of the line and jump to the end label if successful.
  • : end: the end label.
  • s|^n||: remove the leading n character that lsof inserts to identify the field being output.

However note that non-printable characters in file names are encoded (like \n for newline, ^[ for ESC...) in an ambiguous way (as in ^[ could mean either ^[ and ESC).

Also, for deleted files, on Linux at least, you'll still get a file path but with (deleted) appended. Again, no way to discriminate between a deleted file and a file whose name ends in (deleted). Looking at the link count will not necessarily help as the deleted file could be linked elsewhere.

See also the removing of type=* which we do for Unix domain sockets that may have actually occurred in the file name.

What that means is that though it will work in most cases, you can't post-process that output reliably in the general case.

Not to mention that lsof itself may fail to parse the information returned by the kernel correctly, or that the kernel may fail to provide that information in a reliably parseable format

  • Thank you very much. This works exactly as I asked, but you're right it still is not always reliable, so I guess I will just loop through the FDs in /proc, it is not going to be POSIX standard, but it is the cleanest option that I have. Commented Jul 29, 2016 at 10:14
  • 1
    Note that if you're going to do readlink()s on /proc/<pid>/fd/*, on Linux at least, you'll still have the problem with deleted files vs files whose name ends in (deleted). Commented Jul 29, 2016 at 10:28
  • Thanks, I know I expect the error in the script Commented Jul 29, 2016 at 10:35
  • 1
    @BetimNeutron, also note that with /proc/pid/fd, you only get files open on file descriptors, not all mmapped ones (/proc/pid/maps for them), and you won't get the paths of Unix domain sockets (see /proc/net/unix or netlink APIs on Linux) Commented Jul 29, 2016 at 10:52
  • If I am not asking for too much...would you mind explaining those options, so if I or somebody else needs them they are there. Commented Jul 29, 2016 at 12:10

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .