[TUHS] evolution of the cli

[Arnold Robbins via TUHS]

Glad to help.  You can send me some shares in your start-up
company to repay me. :-)

Seriously, I am glad to help. It sounds like you could be
on to something worthwhile.

Arnold

"A. P. Garcia" <a.phillip.garcia at gmail.com> wrote:

> 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
> >