I swear I want this as a general tool for all command-line tools.

Start the tool, and just list all of the options in order of usage popularity to toggle on as desired, with a brief explanation, and a field to paste in arguments like filenames or values when needed. If an option is commonly used with another (or requires it), provide those hints (or automatically add the necessary values). If a value itself has structure (e.g. is itself a shell command), drill down recursively. Ensure that quotes and spaces and special characters always get escaped correctly.

In other words, a general-purpose command-line builder. And while we're at it, be able to save particular "templates" for fast re-use, identifying which values should be editable in the future.

I can't be the first person to think of this, but I've never come across anything like it and don't understand why not. It doesn't require AI or anything. Maybe it's the difficulty involved in creating the metadata for each tool, since man pages aren't machine-readable. But maybe that's where AI can help -- not in the tool itself, but to create the initial database of tool options, that can then be maintained by hand?

(Navi [1] does the templating part, but not the "interactive builder" part.)

[1] https://github.com/denisidoro/navi

▲

pathartl 5 hours ago | parent | next [-]

The problem is always going to be that everyone has their own way of structuring arguments and providing help text. You could probably do it with PowerShell.

▲

darrenf 17 hours ago | parent | prev [-]

I’m trying to understand the “In order of usage popularity” thing — this implies telemetry in CLIs, doesn’t it? Wouldn’t the order of options change/fluctuate over time?

Or if no telemetry but based on local usage, it would promote/reinforce the options you already can recall and do use, hiding the ones you can’t/don’t?

▲

crazygringo 15 hours ago | parent | next [-]

You could make it opt-in telemetry in the tool itself, that would probably be good enough.

But also, you could probably be just as accurate by asking an LLM to order the options by popularity based on their best guess based on all the tutorials they've trained on.

Or just scrape Stack Overflow for every instance of a command-line invocation for each tool and count how many times each option is used.

Ranking options by usage is the least complicated part of this, I think. (And it only matters for the popular options anyways -- below a certain threshold they can just be alphabetical.)

	▲	zahlman 15 hours ago \| parent [-]
		> But also, you could probably be just as accurate by asking an LLM to order the options by popularity based on their best guess based on all the tutorials they've trained on. > Or just scrape Stack Overflow for every instance of a command-line invocation for each tool and count how many times each option is used. Even trusting the developer's intuition is better than nothing, at least if you make sure the developer is prompted to think about it. (For major projects, devs might also be aware that certain features are associated with a large fraction of issue reports, for example.)

▲

reassess_blind 16 hours ago | parent | prev [-]

Just do a best-guess list. Or do a survey. Or just scrape the most common features used across Github repos.