Hacker News Reader

Comment by bluetomcat | Hacker News Reader

The principal problem of any sufficiently advanced CLI tool is the combinatorial explosion of options. With more than a dozen options, you start having special cases like "it does foo when the bar option is used, baz otherwise". In a GUI, you generally express exclusivity or inclusivity with the use of the correct UI elements – a checkbox can become disabled when something else is selected.

View on HN

With all these command-line parser libs, I'm surprised there aren't more libraries that automatically generate a graphical interface for them. Would be super useful for e.g. ffmpeg, cc, curl, etc. Especially for people unfamiliar with the program....

There is for Python: https://github.com/chriskiehl/Gooey

Early on (late 90s and early 00s) there were a lot of command line to gui kinds of tools (there were also a lot of tries at web-ifying, CLI tools also). I can't remember the name, but there was even a terminal emulator that tried to present commands as dialogs.

* There is no enforced standard for commands other than using a file name to invoke them.

* Different languages and frameworks have different and multiple ways of parsing command lines. For example Gooey (a python gui tool) works with scripts written with the argparse library but dodes not work with optparse.

* The terminal is not the shell. That means that to present a gui, you'll have to launch something that runs outside of the terminal to present the gui.

* It's common for developers to write command line tools with out understanding the shell and os's input and output system beyond reading and writing files. I routinely have to teach jr developers about stdio, stderr, pipes etc...

That said, there's great potential to take advantage of shell autocomplete files to make better guis for commands: https://blog.deepjyoti30.dev/tab-autocomplet-cli-apps . Someone probably already has done this...

The idea is that you'd build it into whatever command-line parsing tool you use. Presumably this would be runtime-specific. And yes, the entire point is to escape the terminal and rely on native interface constraints (e.g. disabling/enabling) to reflect the usage of the tool.

> whatever command-line parsing tool you use

Hmm. Writing a wrapper that uses autocomplete definitions might be more useful... There's also the approach of Zenity that gives you the ability to create GUIs from shell scripts. When you do have a gui from parser tool, it can be quite nice (like Python's gooey).

https://github.com/Textualize/trogon

It doesn't even need to be a full GUI, just having an interactive interface for weaving commandline-spells on the fly would already improve the access. But then again, this would demand a more complex interface than a commandline. I'm not sure how easy this is implementable with your average shell&terminal.

There are some reasonably complex git tuis. https://github.com/extrawurst/gitui is one

a good shell completion function is like 80% of the way there, it can even include descriptions for flags, and the smart ones will know about exclusions and such

> The principal problem of any sufficiently advanced CLI tool is the combinatorial explosion of options.

Which is actually also a problem with GUIs. Many times, with a few CLI commands you can do a ton of stuff that you just cannot represent in UI without having tons of buttons...

I know people write these kinds of programs and I write these kinds of programs, but the obvious solution to this predicament is that we should have more, simpler tools so that instead of a combinatorial mess of options, you get a collection of composable tools.

People want to solve their problems in the simplest way possible.

They will only use composition if there isn’t a tool that solves the problem by itself.

That would be an interesting interaction to explore with a colourised terminal. Essential have contextual colouring on input so that mutually exclusive params are either shaded in the case of clear precedence or highlighted for conflict. It's not an area I've played with but wonder if that could be hacked into exisiting autocomplete mechanisms?

fish shell.

I was hinting/hoping at something beyond what fish does.

Rather than just structural colouring (params are colour a, valid paths colour b etc) the input is recoloured as you type in response to validity for the specific tool you're about to invoke.

Reply on news.ycombinator.com