4 ms·

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

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.

_kb 3y ago
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?
- oblio 3y ago
  fish shell.
  - _kb 3y ago
    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.
JeffSnazz 3y ago
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....
- blackbear_ 3y ago
  There is for Python: https://github.com/chriskiehl/Gooey https://github.com/chriskiehl/Gooey
- indymike 3y ago
  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 https://blog.deepjyoti30.dev/tab-autocomplet-cli-apps . Someone probably already has done this...
  - JeffSnazz 3y ago
    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.
    - indymike 3y ago
      > 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).
- CubsFan1060 3y ago
  https://github.com/Textualize/trogon https://github.com/Textualize/trogon
- PurpleRamen 3y ago
  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.
  - mooreds 3y ago
    There are some reasonably complex git tuis. https://github.com/extrawurst/gitui https://github.com/extrawurst/gitui is one
- arccy 3y ago
  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
bee_rider 3y ago
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.
- dwaltrip 3y ago
  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.
palata 3y ago
> 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...

_kb 3y ago

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?

oblio 3y ago
fish shell.
- _kb 3y ago
  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.

JeffSnazz 3y ago

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

blackbear_ 3y ago
There is for Python: https://github.com/chriskiehl/Gooey https://github.com/chriskiehl/Gooey
indymike 3y ago
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 https://blog.deepjyoti30.dev/tab-autocomplet-cli-apps . Someone probably already has done this...
- JeffSnazz 3y ago
  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.
  - indymike 3y ago
    > 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).
CubsFan1060 3y ago
https://github.com/Textualize/trogon https://github.com/Textualize/trogon
PurpleRamen 3y ago
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.
- mooreds 3y ago
  There are some reasonably complex git tuis. https://github.com/extrawurst/gitui https://github.com/extrawurst/gitui is one
arccy 3y ago
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

bee_rider 3y ago

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.

dwaltrip 3y ago
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.

palata 3y ago

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