> It's really not that hard,

if you are doing it often that's true. But for people like me who do it once every month or two it really is hard to memorize, especially if it's not exactly the same task.

What I would love would be an interactive script that asked me what I was trying to do and constructed a command line for me while explaining what it would do and the meaning of each argument. And of course it should favour commands that do not re-encode where possible.

▲

crazygringo 19 hours ago | parent | next [-]

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.

▲

josephg 13 hours ago | parent | prev | next [-]

> What I would love would be an interactive script that asked me what I was trying to do and constructed a command line for me while explaining what it would do and the meaning of each argument. And of course it should favour commands that do not re-encode where possible.

My ChatGPT history is full of conversations like this.

I have mixed feelings about using chatgpt to write code. But LLMs certainly make an excellent ffmpeg frontend. And you can even ask them to explain all the ffmpeg arguments they used and why they used them.

▲

larodi 21 hours ago | parent | prev | next [-]

Indeed why not have —tui option and some basic menu? Even a simplified scripting with reasonable API would be better.

I find myself bothering exactly zero times to memorise this obnoxiously long command line. Claude fills in, and I can explore features better. What’s not to like? That I’m getting dumber for not memorising pages of cli args?

Love the project, but as with every Swiss knife this conversation is a thing and relevant. We had similar one reg JQ syntax and I’m truly convinced JQ is wonderful and useful tool. But I’m not gonna bother learning more DSLs…

▲

navane 14 hours ago | parent | prev | next [-]

I also use ffmpeg once a month. My new plan: build my own scripts like the ones in op. But self built, only for that operation or three that I do.

▲

magicalhippo 18 hours ago | parent | prev [-]

And they change quite frequently, from our POV.

That said, I started wrtiting scripts when I use ffmpeg some time ago. At least then I have a non-zero starting point next time.