Comment by jiveturkey
1 day ago
> 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.