Sloth – Mac app that shows all open files and sockets in use | Hacker News Reader

Sloth – Mac app that shows all open files and sockets in use

github.com

549 pointseddyg108 comments

Fifteen years of maintenance and updates (by one developer) for a free and open source tool, and just asking for donations if the user finds it useful! I'm impressed! If I were a user, I would certainly donate.

I like to think that when I see such really nice behaviour, I should supply positive reinforcement since I know how much such things can matter to people. Eg I had a really nice commuter bus ride, when about to go off, I went to the driver and said thanks, I enjoyed the ride, it was very smooth etc. I could tell this person took pride and enjoyment in doing it. I also called his employer and gave praise (using the bus number), hopefully this is reflected professionally for him too.

So you don't have to be a user to show appreciation ;)

But weren’t you a user of the bus system in the scenario you laid out as well?

....that's true! :)

edit: and re-reading my comment I feel it can come across like a manipulative sociopath comment, but I can assure you all that's not what I am. Though, that's exactly what a manipulative sociopath would say.

Not at all! I think those actions were very kind.

After our meal of takeout BBQ last week I called the joint, which was brand new, and thanked them for how good everything was. As a shy telephone-allergic introvert I’d never done that before, but I’m glad I did!

Agree, it feels good doing it. :)

The stock Activity Monitor app provides a sparse-looking version of this (double-click a process, then select 'Open Files and Ports')

Activity Monitor makes it reasonably easy to check which files a process has open, but does not reasonably handle the inverse case of checking which processes have a specific file open.

This can be installed using homebrew with:

brew cask install sloth

I know Homebrew is vetted, but I personally like to always check where this is pulling in its installer file - and it appears to match the domain as is in the Github repo.

https://github.com/Homebrew/homebrew-cask/blob/master/Casks/...

You might already know this but you can do that by command line with 'brew cask audit sloth' to see where it's pulling from...I'm paranoid enough too :O

I did not know that, so thanks for the tip!

I made a mistake! The command is ‘brew cask cat’ to see where it’s coming from.

Which version of homebrew are you using? Because when I try this this is what I get:

  $ brew cask audit sloth                                                                                                                                                                                        
  audit for sloth: passed

I made a mistake! The command is ‘brew cask cat’ to see where it’s coming from.

Audit seems to be checking the formula code not the source of the download?

https://docs.brew.sh/Manpage

> Check formula for Homebrew coding style violations. This should be run before submitting a new formula. Will exit with a non-zero status if any errors are found, which can be useful for implementing pre-commit hooks. If no formula are provided, all of them are checked.

https://github.com/Homebrew/homebrew-cask/blob/master/USAGE....

> audit — verifies installability of Casks

You can see where it pulls from if you provide the --download flag but as far as I can understand it does not do any other validation regarding that.

  brew cask audit virtualbox --download

AFAIK checksums are checked even if you don't run audit.

I made a mistake! The command is ‘brew cask cat’ to see where it’s coming from.

You can simply run `brew cask cat sloth` to look at code.

This looks like such a nice app! Proper Mac UI too. I'm going to try it out as soon as I get home.

This is interesting to me because it's an example of the other side of the "Electron" argument.

`lsof` exists in Linux. At least, my Ubuntu 16.04 has it. So if this were an Electron UI, would we instantly have a Linux version as well? Or is it not that simple?

I do really enjoy the look and feel of this mac version, though.

> if this were an Electron UI, would we instantly have a Linux version as well?

Many Electron apps are only written in JS without any (or no neccessary) platform specific code, but some also interface with the platform. In this case, if it just calls lsof through the shell and the versions are the same, it might actually just work. If it ships with its own binary it'd need to be switched out.

That's right.

Once you've got the equivalent commands for each platform, it should be possible to build and package for all of them (Mac/Win/Linux).

I've just done a tri-platform Electron app which handles quite a few platform-specific commands. (For drive listing, SD-card formatting, file decryption (in custom C apps), etc.)

It does take a lot more work (and lots of time-consuming testing). But it can be done.

Taking something as lightweight as an lsof command line tool and putting an entire web browser and node.js instance on top seems like we are moving in the wrong direction. It’s like we are going to need a terabyte of RAM and a Tesla battery to run basic apps of the future with even half of the performance we got out of our systems 2 decades previously.

It’d be like building a factory around a music box.

I'm not sure that I would call something with about 40 screens of man pages "lightweight".

The size of the program’s man page doesn’t impact the performance characteristics of the program, does it?

No, but "lightweight" doesn't necessarily mean performant. The size of the program's man page might be the thing that makes people want a different, more discoverable interface to the program.

I feel like this argument is the software engineer's version of "smaller government" political ideology. Yes, we want small, fast processes. Yes, we want efficiency. But we want efficiency _for the sake of usability_. For the Linux user, Sloth is (nearly) useless. Electron would have provided great value (at the cost of and under the burden of larger hardware, etc.) Complexity and resource usage creep isn't going away, although I applaud efforts to reduce complexity and use resources parsimoniously.

What are better starting points? QT?

Yes

The app is older than Electron. The people who this tool were written for would probably dislike a big, slow Electron app anyway

And why Electron? Why not QT, or Java swing, or some other language with GTK?

> And why Electron? Why not QT, or Java swing, or some other language with GTK?

In this specific case, the app was targeted for MacOS and OS X earlier. Java really isn't a good solve on that platform. Which also makes it not a good solve for anything on the Mac platform.

I have been wanting to build a UI tool for non-techies to be a front end to a collection of shell scripts that I have been using for day-to-day tasks. I have written the scripts to be a friendly as I can make them with drag-n-drop folders as inputs rather than requiring arguments to be provided. This looks like a good example for me to use as research.

Electron apps are also horrible on the Mac (and probably everywhere else too). Buggy, bloated resource hogs with nonstandard and limited UI and incredibly high input latency for simple actions.

As a Mac user, when I hear “Electron app” I think “company that was too lazy/cheap to make a real Mac app.”

Also, if Electron apps are just a packaged up webpage, could they even do things like run shell scripts locally? I'm also wanting to allow the user to browse for a file and have the full path intact instead of just the name of the file a browser would return.

Not only that, but they have pervasive cross-site scripting vulnerabilities that are now exposing the user to remote code execution!

Also, they tend to have out of date dependencies, and are vulnerable to traditional code execution exploits that were fixed in upstream chrome long prior.

Hmm, I don't know about this. VS Code is an Electron app and I'm not sure if it would benefit that much from being a "real" Mac app. I much prefer that is it consistent across platforms. I do prefer Terminal.app to Hyper though.

I wouldn't mind if Slack had a native app but I'm not too bothered by it.

The VS code team has spent an inordinate amount of time optimizing their Electron usage to achieve some semblance of performance. VS Code is nice but it is still slower than Sublime, let alone Notepad++, Textmate, or Pluma/GTKedit

I can vouch that they're terrible on Linux, too.

It's a lazy, corner cutting way to build a cross platform app, and it shows.

If you want to build a simple UI on top of a script for Mac, I recommend Platypus: https://sveinbjorn.org/platypus

The app has been around for years, is open source, and works really well.

And by the same author as Sloth!

Thanks! This sounds like it might be exactly what I'm looking for, just need to find time to dig into it.

Except how big is the Electron app going to be?

Well, there's that ;)

Between 50Mb and 80Mb for the installer. Over 100Mb installed, depending on what is used.

I wonder if it was possible to port the App to Linux using GnuStep or the Cocotron.

GNUStep also exists in Linux. Maybe the Linux version is just a compile away.

Proper Mac UI, and it's 0.6MB! :)

For me it looks like the binary is 1.4MB (which is still fantastic)

Binary is ~200KB. The rest is mostly images, icons and whatnot, and the auto-update framework (Sparkle). Version 1.0 was 40KB zipped, back in 2004. O tempora, O bloat.

It's not proper in that it is not properly signed. Gatekeeper complains that it cannot be opened because it is from an unidentified developer.

What kind of security risk is this for me?

That is for you to assess. macOS gives you the opportunity to either override the security popup by right-clicking the app and launching it anyway, or not.

Also, the "security risk" doesn't get a whole lot smaller when the app is signed. Only widely known malware apps will get their certificates revoked in time.

The new "notarization" is slightly more thorough but the risk is still up to you and the app permissions for non-appstore non-sandboxed apps are indeed quite open. Malicious or not, an app that is not sandboxed can steal or damage your data anywhere in the filesystem.

So again - all up to you to decide.

Author of Sloth here. I develop free software in my spare time and I'm not willing to pay Apple USD 100 per year for the "privilege" of developing for their platform. It's a sad state of affairs when independent developers like me have to shell out hard cash in order to give software away for free. True, USD 100 isn't much, but I'm opposed, on principle, to paying money to an enormously wealthy megacorporation just to make software for their platform. Not so very long ago, macOS had a vibrant independent developer community. It's now slowly being choked to death with this horrid App Store stuff.

Good for you, man. That was one of the reasons I stopped using OS X.

Keep up the good work, I agree with you on that. I can’t see any reason why Apple don’t give free developer certificates to serious developers

I think that $100 is less of a cash grab and more of a gate to nefarious actors - they can’t trivially cycle through certificates for their malware without spending $100 every time, but $100 is likely not so much that it will hurt an independent developer. I see your perspective though. I have mixed feelings about it as well.

All that an Apple signature proves is that the developer is paying Apple for the privilege. And, theoretically, apple has vetted the app to some minimal extent.

But there is little stopping a signed app from becoming malicious, so from a security standpoint, being signed doesn't ALWAYS mean being "safe".

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

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

Stable? You must be joking?

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.

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.

macOS, with its BSD roots, doesn't have a proc filesystem.

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.

Huh, so that means you need root to run lsof on freebsd?

lsof seems to be setgid on FreeBSD (group kmem).

Surely you must be joking? If command line tools were so unstable Linux wouldn't be possible...

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.

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

Are there any alternatives for other Unices and Unixlikes?

lsof was written by vic abell, who also wrote a graphical java gui for it, glsof.

http://glsof.sourceforge.net/

Any thoughts about pros / cons when compared with Sloth?

Sloth has some features that seem more Mac specific like filtering out non-user applications and such. Also, one is java vs a native (mac-only) app.

It's a wrapper around a tool. Just try it!

Lsof is Unix-standard, part of coreutils, and can be used anywhere, piped and automated.

Sloth exists only on OSX and is a GUI app.

I’d ask the opposite: Any reason anyone would anyone use Sloth over lsof?

> Lsof is Unix-standard

lsof is pretty common, but I don't think it is actually standard in any way, for example it is not part of POSIX or SUS which arguably are the two most influential UNIX related standards.

http://bhami.com/rosetta.html (ctrl-f lsof)

It works very well on macOS, which is an OS that I use for a large amount of time?

Does lsof not work very well on MacOS?

It works, but supposedly this works better.

Is there anything like that for Windows?

Yes, Process Explorer from Microsoft’s free sysinternals tools.

Process Explorer for files, but I'm not sure about sockets.

Process Monitor I think has both.

Sysinternals tcpview for sockets side is easiest to use

In addition to Sysinternal's Process Explorer, there is also a built-in application "Resource Monitor" (resmon.exe) linked on the Performance tab of the regular Task Manager.

If you enable Bash for Windows in the developer tools settings, you will be able to run lsof directly from the command line

If you like this app, you should also check out Task Explorer by reknown security researcher Patrick Wardle.

https://objective-see.com/products/taskexplorer.html

Man, what is up with that UI though? Like 20% of the top space for the program name??

Wardle has his own style for these apps. I’m personally not a big fan if it, since it looks out of place, but I guess it is a “branding” thing for him.

This is a nice little tool. The more I find myself running a full stack application local (when not in Docker), lsof is quite useful. Will try this out for sure!

Is there any way (in general) to see what processes a pipe is connected to (on both ends)?

Maybe it is just me, but I am getting tired of cute names for projects. lsof is easy to remember (list open files), I like that.

Sloth sounds like if you tried to pronounce lsof.

No, not really. S comes after L when pronouncing, no matter how you do it.

My comment was too negative. Looks very useful. I just have trouble remembering names like this. I don't think this is a name/sound that clicks for me.

I get the feeling too. I was just wondering about that this morning. Some times you want a name that is clearly descriptive like lock_and_clean_journal but when you have a new tool that does a lot and in a different way.. a cute name is a good symbol to indicate 'completely new context'. Otherwise we'd get meaningless glue code like

    pony | lulee --pew | eels | cyan ..

> Otherwise we'd get meaningless glue code like

> pony | lulee --pew | eels | cyan ..

I mean we kinda do, it's just that we're used to the bits.

    ls | xargs cat | grep main >> /dev/nul 2>&1

is not inherently more meaningful than what you wrote above, you just have the experience to interpret it.

Incidentally, powershell commands tend to be more "self-explanatory" in their naming, at least in theory.

heh, not untrue, although most are bad shortenings.. ls:list, xargs:arguments, cat:concatenate

MS did try to avoid explosion of idioms but at a tiny verbosity cost. I believe that map/reduce is a bit a good middle ground

I too hate this phenomenon, but this one has version history going back to 2004, so it's not exactly your generic JS framework-of-the-week with nondescript cutesy name.

Not sure why you're getting downvoted but I can relate. There is sort of a fashion to naming projects that I think many people don't understand. To me "cute" tech project names were fashionable in 2000 - 2010 (Shoes gui toolkit for ruby comes to mind) but like any trend, it was overdone and became lame.

yeah, I don't want to be overly negative but I think this must target a very niche, possibly non-existent set of users: people who need to see all open files and sockets for whom lsof+grep is too complicated. Personally I have "sudo lsof -i | grep <port>" burned into my muscle memory and this tool just seems slower

Fifteen years of maintenance and updates for having what on every normal operative system is available in five minutes.

Yep, is definitely a Mac :D

Well lsof is available on a Mac if you want a command line, as is Activity Monitor. Shrug

I was expecting some ncurses-based interface

GUI, not TUI in the title

Holy fat controller! This whole source code is mostly in just a single file. https://github.com/sveinbjornt/Sloth/blob/master/source/Slot...

Curious what patterns you iOS developers out there do to avoid code like this? Personally I am a big fan of ReSwift.

This[1] video with Andy Matuschak helps with refactoring these “Mega” controllers. This[2] article also is good when it comes to breaking down controllers into smaller pieces.

I will admit it’s a hard problem for me. Putting everything into one view controller is so easy and makes certain problems go away. e.g. Storyboards are a lot easier to deal with when their outlets are in the massive view controller. Custom UIviews with storyboards are a huge pain to get working with interface builder.

[1] https://academy.realm.io/posts/andy-matuschak-refactor-mega-... [2] https://www.smashingmagazine.com/2016/05/better-architecture...

The code is pretty clear though. It is well laid out and doesn't feel cluttered.

Author of Sloth here. The controller didn't start out quite so fat, the whole thing was quite slim, 400-500 lines, when I first put Sloth together some 15 years ago. It grew as various additional features piled on over the years. However, your point is well taken. I should refactor things at some point.

Reply on news.ycombinator.com