Completely agreed. Not sure what the historical reasons for lsof and ss are, but unix tools are structurally in a hard place when it comes to having sensible defaults over the long term.

Generally speaking, you can only have sensible defaults over time if you're able to change the defaults over time. New users and new use-cases come with time, and so what constitutes a "sensible default" changes.

However (and this is a drum I like to bang[0]), because unix tools only deal in usually-text bytestreams without any higher level of abstraction, consumers of those tools end up tightly coupled with how output is presented. Without any separation between data and its representation, the (default) representation is the tool's API. To change the default representation is to make a backwards-incompatible API change. A good example of this is how ps aux truncates longer than like 7 characters.

[0] https://www.cgl.sh/blog/posts/sh.html

Hah yes, I've come to unashamedly - by muscle memory since the 1990's - find myself always typing 'ps auxw[w...]', where [w...] is some arbitrary number of w's depending on how heavy my index finger feels at the moment of typing.

> change the defaults over time

however this breaks backward compatibility, as you noted. in the golden age of unix it was critical to maintain backward compatibility so that local tooling didn't magically break.

HP-UX seems to have an env var UNIX95 that affects XPG4 compliance in operation/output. Solaris always had a /usr/xpg[46] path (and /usr/ucb). GNU tools have POSIXLY_CORRECT. and so on.

I never liked using any of those because then you're on some other system, or in a break glass situation, and none of the tooling works as you expect. In the today world of a near monoculture of linux, it's fine I guess. And there's no reason today that complex commands like `ss` shouldn't be controllable via env var.

love your blog, thanks for the link.

> love your blog, thanks for the link.

Thank you!

Configuring configuration via env var is a good historical example. I think that especially works nicely when you Buy An Operating System. You know, one that is created and provided by A Vendor. In principle, the vendor can architect a unified metaconfiguration system, e.g. one or several env vars that align behavior to a standard.

But I dunno if it would work so well to to hypothetically apply that tactic to a modern bazaar-based OS like Linux. Distros do amazing, valuable work to unify things, but modern Linux is basically a zillion software packages in a trench coat. So either the distro carries a zillion patches to have a few env vars, or the distro carries no patches and there are a zillion env vars. Either way, total cost of maintenance explodes.

Maybe when people say "text is the universal interface," they really mean that once you've released a textual interface, the interface becomes universal, unchanging for all time.

"Like, ss without any options shows such arcane, rarely needed details as send/receive queue size but not the application socket belongs to.

And omits listening sockets which is main use for such tools."

IMHO this would be one of the many arguments in favor of compiling from source rather than using "binary packages"^1

https://mirrors.edge.kernel.org/pub/linux/utils/net/iproute2...

   (
   printf '/int state_filter = 0;/a\\\n'
   printf 'state_filter = (1 << SS_LISTEN) | (1 << SS_CLOSE);\\\n'
   printf 'show_processes++;\\\n'
   printf 'show_queues = 0;\\\n'
   echo
   echo "s/dhalBet/q&/"
   printf '/switch (ch) {/a\\\n'
   printf "case 'q':show_queues=1;break;\\\n"
   echo
   )|sed -i -f/dev/stdin misc/ss.c

This changes the default to display all sockets, hide the queues and show the processes using each socket

It also adds adds a -q option to display the queues

1. IMHO this is also an argument against "cloud computing", i.e., using someone else's computers where pre-installed kernels and binary packages are the norm

> I know picking the right defaults is hard

I think we understand that UX problem much better now than developers did back in the 70s. In general, not just for ss/lsof

I think the same applies for many of the new breed of command line applications like fd and ag/rg.

Being able to use them intuitively trumps ubiquity, speed or features.

But it's not tradeoff! You can make default view useful without trading versatility.

Another annoying part is not supporting json or even CSV. Some tools got modernized with it (like iproute2 tool set), but for these you might as well do /proc scraping yourself...

That's true in general. But default view is still subjective. The challenge probably lies in recognizing the larges subset of your user base that would like it to be a certain consistent way.

ss is from the same batch of modernization as iproute2.

Depends on the use case.

If used in scripts, ubiquity and speed can be important. Then again, the output of ss is not ideal for script processing.

That's the problem, it's not good for humans, it's not great for scripts

Very curious what is wrong about the rg defaults.

The only one I change is to add `--no-ignore`.

Nothing.

fd, rg and ag all work how I expect them to work and the arguments and order fit in with my expectations for modern cli applications.

They're recursive, they ignore things I don't care about and I can just give them the string I'm looking for, no path, no -name or --recursive etc.

find and grep do similar things but work entirely differently and their args aren't even in the same format.

Don’t “netstat -utan” and “ss -utan” show basically the same thing?

"utan" means "without" in Swedish, so I use the more flowery "-tulpan" as my mnemonic. It means tulip.