[TUHS] evolution of the cli

[A. P. Garcia via TUHS]

Arnold,

This is exactly the kind of reply I was hoping for. Thank you.

The Plan 9 point is really interesting. Exposing kernel/OS state as a
mounted virtual filesystem (data + ctl) is honestly a cleaner expression of
the same instinct I’ve been circling: make the machine describe itself in a
way operators can both read and act on without having to reverse-engineer
twenty different tools.

If I squint, I can almost see two layers that could coexist:

• Layer 1 (your suggestion): a FUSE-style mounted tree that surfaces live
system objects as directories and plain-text files — /ops/tasks/1234/…,
/ops/netif/eth0/…, etc. Read a file to inspect, echo ... > ctl to act. Any
shell, any awk script, no new language required. That’s extremely
attractive, and it lines up with your “just let me script it” bias.

• Layer 2 (the thing I was sketching): an operator’s console / REPL that
sits on top of that same tree and gives you richer views, grouping,
filtering, summaries, postmortem queries, JSON output, etc. More of an
investigation surface for the 2am incident or the day-after review.

In other words, your Plan 9 model could actually be the substrate. My
higher-level “Task / NetIf / Mount objects with methods” could just be a
friendlier lens on that substrate — not a replacement for it.

That also answers your portability worry in a very old-school way: each OS
could ship its own provider for that filesystem view, however it gathers
the data (Linux via /proc, BSD via sysctl/kvm, etc.), and anything above it
just consumes files.

I really appreciate you pointing me in that direction. It pulls this back
toward something a real Unix person would actually tolerate.


Phil


On Sat, Nov 1, 2025, 2:49 PM <arnold at skeeve.com> wrote:

> Hi.
>
> "A. P. Garcia" <a.phillip.garcia at gmail.com> wrote:
>
> > Arnold,
> >
> > First, thank you. I really appreciate you taking the time to answer
> > directly.
> >
> > I think you’ve put your finger on the most important tension: who is this
> > actually for?
> >
> > I don’t think this shell would be aimed at “most developers,” and I agree
> > with you that most developers neither want nor need to think in terms of
> > kernel anatomy. Where I’m trying to land is much narrower: the people who
> > are responsible for keeping a running system healthy at 2am, and for
> > explaining after the fact what went wrong. Call it SRE / ops / old-school
> > Unix admin / performance engineer. That’s the user I have in mind.
>
> OK, so I'll buy that your approach makes some sense for that crowd.
>
> > Arnold, your point about portability keeps echoing in my head.
> > I’ve been thinking that the right answer might be a plugin architecture
> > instead of a hard-wired Linux core — a stable vocabulary of objects
> (Task,
> > NetIf, Mount, etc.) with back-end modules that know how to populate those
> > objects for each OS.
> >
> > That way Linux can pull from /proc and /sys, BSD from sysctl or kvm,
> macOS
> > from libproc, and so on. The interface stays constant; the provider
> changes.
>
> I like that idea.
>
> > I’m also leaning toward making those providers language-agnostic, maybe
> > using WASM modules, so anyone could extend the system in whatever they’re
> > comfortable writing.
>
> I know nothing about WASM, so I can't really comment.
>
> What's echoing in my head at this point is that something like
> Plan 9's treatment of devices with /dev/xxx/ctl and /dev/xxx/data
> files would be better - if you could expose a file system like
> interface to the kernel data structures.  Maybe via FUSE?
>
> Of course, your query language was sort of SQL-like, and as an
> old Unix hand I prefer shell scripts, so now my bias is showing.
>
> Interesting ideas, though.
>
> Arnold
>