4 ms·

Any reason you choose to build on the command line interface of lsof rather than reusing its api by diving into its source code?

randomsearch 8y ago
Command line interfaces usually more stable, documented and easy to use.
- Tepix 8y ago
  Stable? You must be joking?
  - simias 8y ago
    For standard Unix tools? Not really, since they're often used in scripts and everything breaks if the formatting changes. Generally any new feature is hidden behind new flags on the command line to avoid breaking anything. There are exceptions of course but I doubt the output of lsof will change any time soon. Meanwhile kernel ABIs can and do change between versions (the API less so, but it still means that you have to rebuild your code). What can happen however is that a tool of the same name might have a different output or behavior on different operating systems (most notably between the GNU and BSD variants). But in this case the kernel API is probably different as well, so you'll have to implement an abstraction layer anyway.
    - akerl_ 8y ago
      In this case, `lsof` is a relatively lightweight parser for /proc. The /proc filesystem API is amazingly stable. The unstable ABI is internal to the kernel itself; the interaction with userspace is where backwards compat is held as the highest guiding principle (see Linus's remarks about breaking userspace). By contrast, lsof can change output at any time. I've not done enough parsing of lsof to be familar with past changes, but have seen meaningful changes in the default output of lsblk, df, and other core CLI tools that wrap system information.
      - rabidcondor 8y ago
        macOS, with its BSD roots, doesn't have a proc filesystem.
        comex 8y ago
        If anyone's curious: Traditionally, lsof on BSD would just open /dev/kmem and read the info directly out of the kernel's data structures! It still does that on FreeBSD, and used to do it on macOS prior to 2006, when Apple added the more sensible (and stable) libproc.h API in one of the Tiger software updates. Sloth dates back to 2004, at which point parsing lsof's output would definitely have been a more sensible choice than replicating the kmem parsing code. On the other hand, if I were writing something like Sloth today, though, I'd use libproc, because I think it'd be easier overall, and it would also make it more feasible to improve the core functionality (like adding a progress bar or lazy querying). However, lsof does have a flag (-F) to specify how to format its output, explicitly documented in the man page as being intended for other programs that want to parse its output, implying that it will remain stable. And Sloth uses this flag. Thus, even from a modern perspective, its approach is perfectly reasonable.
        lawnchair_larry 8y ago
        Huh, so that means you need root to run lsof on freebsd?
        saagarjha 8y ago
        lsof seems to be setgid on FreeBSD (group kmem).
  - tomc1985 8y ago
    Surely you must be joking? If command line tools were so unstable Linux wouldn't be possible...
  - webninja 8y ago
    I have Bash scripts that still run (all of them). Meanwhile I’ve had PHP deprecate functions I was using, I’ve had Python rewrite the requests library and break working 3.X scripts after an apt-get update, and node.js seems to change so fast and require so many dependencies that it’s much less likely to be maintainance-free. Bash is still my favorite scripting and automation language.
peterbraden 8y ago
The API of a unix tool _is_ it's output.

randomsearch 8y ago

Command line interfaces usually more stable, documented and easy to use.

Tepix 8y ago
Stable? You must be joking?
- simias 8y ago
  For standard Unix tools? Not really, since they're often used in scripts and everything breaks if the formatting changes. Generally any new feature is hidden behind new flags on the command line to avoid breaking anything. There are exceptions of course but I doubt the output of lsof will change any time soon. Meanwhile kernel ABIs can and do change between versions (the API less so, but it still means that you have to rebuild your code). What can happen however is that a tool of the same name might have a different output or behavior on different operating systems (most notably between the GNU and BSD variants). But in this case the kernel API is probably different as well, so you'll have to implement an abstraction layer anyway.
  - akerl_ 8y ago
    In this case, `lsof` is a relatively lightweight parser for /proc. The /proc filesystem API is amazingly stable. The unstable ABI is internal to the kernel itself; the interaction with userspace is where backwards compat is held as the highest guiding principle (see Linus's remarks about breaking userspace). By contrast, lsof can change output at any time. I've not done enough parsing of lsof to be familar with past changes, but have seen meaningful changes in the default output of lsblk, df, and other core CLI tools that wrap system information.
    - rabidcondor 8y ago
      macOS, with its BSD roots, doesn't have a proc filesystem.
      - comex 8y ago
        If anyone's curious: Traditionally, lsof on BSD would just open /dev/kmem and read the info directly out of the kernel's data structures! It still does that on FreeBSD, and used to do it on macOS prior to 2006, when Apple added the more sensible (and stable) libproc.h API in one of the Tiger software updates. Sloth dates back to 2004, at which point parsing lsof's output would definitely have been a more sensible choice than replicating the kmem parsing code. On the other hand, if I were writing something like Sloth today, though, I'd use libproc, because I think it'd be easier overall, and it would also make it more feasible to improve the core functionality (like adding a progress bar or lazy querying). However, lsof does have a flag (-F) to specify how to format its output, explicitly documented in the man page as being intended for other programs that want to parse its output, implying that it will remain stable. And Sloth uses this flag. Thus, even from a modern perspective, its approach is perfectly reasonable.
        lawnchair_larry 8y ago
        Huh, so that means you need root to run lsof on freebsd?
        saagarjha 8y ago
        lsof seems to be setgid on FreeBSD (group kmem).
- tomc1985 8y ago
  Surely you must be joking? If command line tools were so unstable Linux wouldn't be possible...
- webninja 8y ago
  I have Bash scripts that still run (all of them). Meanwhile I’ve had PHP deprecate functions I was using, I’ve had Python rewrite the requests library and break working 3.X scripts after an apt-get update, and node.js seems to change so fast and require so many dependencies that it’s much less likely to be maintainance-free. Bash is still my favorite scripting and automation language.

peterbraden 8y ago

The API of a unix tool _is_ it's output.