I think the differences are not fundamental, but that the terminal inputs / shells did not evolve as much as they could or should have. There have been discussions all over the world on the merits of command-line vs. GUI, but too little of how tomorrow's command-line can be better than today's command-line.
Things DID improve, e.g. tab-autocomplete evolved very well. But that's not enough, and editor's command palettes show that. I actually thought I'll give some more quick examples than discoverability, but then I realized that you could fill a whole document with them...
Tomorrow's shells would require changes to various command-line tools and possibly even the kernel. Just changing the shell executable is fundamentally limited, so it cannot be more than the first step. But thanks for the links anyway!
> Tomorrow's shells would require changes to various command-line tools and possibly even the kernel.
Hi, author of _murex_ here. I don't believe that to be true. I mean, I do agree that it would be great to replace the 50 years of legacy of TTYs, byte streams, in-lined control sequences (eg ANSI escape sequences), etc but you can still achieve what you're after. And murex does aim to do this because it is as much inspired by IDEs as it is by scripting languages.
To give an example of these feature:
+ Murex does "fuzzy" search against all possible completions (so does Bash et al with addons, but murex does it out of the box). Do this by pressing ctrl+f
+ Murex does in-line spell checking
+ Murex supports typed pipelines (inc complex formats like JSON, YAML and CSV) and will autocomplete commands that support that data type by default. But it will also work seamlessly with existing POSIX / CLI tools too. It does this by passing the type information in a separate channel to the byte stream. So POSIX pipes work the same but processes that support murex can do richer things with the pipes
+ in expansion of the above, structured data is handled intelligently within murex. eg if doing a regex match against a JSON array you don't need to escape out the JSON formatting. Your tools will automatically only work against the values inside the array. And you can use the same commands against JSON, YAML, TOML, CSV, C-Expressions and others -- the commands understand what the file format is and natively adapt to it. Meaning you don't need to learn different tools for working with JSON than you would for CSV, YAML nor any other format.
+ Murex will display descriptions against each command suggestion (Fish does this too)
+ Murex parses man pages to help build up autocompletions if no autocompletion are defined (Fish also does this)
+ If you're running tmux, you can press F1 against any command in murex and it will open a pane alongside your interactive terminal with the man page (if an external command), a cheat sheet, or the code (if a murex function) so you don't have to remove yourself from the terminal to double check a commands usage
+ Murex has a hint line that acts like a status bar. In there you'll see descriptions of each command (also parsed from man pages if external executable) and also details about the type of command (alias, function, external executable), where is sits in your file system (even showing the path of symlinks) -- so you know exactly what command you're calling and what it is supposed to do.
+ syntax highlighting (this is an increasingly common feature in shells these days)
+ syntax completion (eg quotation marks will smart close)
+ multiline pipelines are handled much better (eg you can up array to the line above and murex wouldn't erase the current pipeline to show the previous one)
+ smarter support for pasting multiple lines (murex will detect if you're pasting multiple lines and allow you to preview it before it then runs those lines. Saving potential mistakes where you're pasting the wrong thing from clipboard)
+ murex can in-line images. It supports client specific ANSI escape sequences for iTerm2's, Kitty, Terminology (Enlightenment) as well as Sixel and ANSI blocks; and will auto-detect what mode will work best with your terminal emulator.
+ colours errors in red (inc STDERR)
+ displays stack traces of errors (inc STDERR)
These features are configurable (can be turned off if you wish) too so if any one of them is not to your tastes you can change the default behaviour.
To be clear, it is still beta software but I've been using it as my primary shell for ~5 years and there are other shells that exist that support some of the same feature sets too. So there definitely are other shells out there that are striving to achieve what you're after, and I'd like to think are having some success at it too.
- output less noise that drowns the signal. The toolchain used to build a program from source is particularly problematic here.
- if the output has to be huge, make it structured / collapsible
- output messages that are both human-readable (so humans don't have to read cryptic data that is meant for the computer) and computer-readable (so the computer does not have to parse human-readable messages, which is fragile). Yes, that's hard.
- Provides tools that each solves one problem, and solves it well.
Some things that could have been changes to tools are implemented by tool-specific extensions (IIRC, bash autocomplete of tool parameters works like this). Discoverability can to some extent be implemented like that, including inconsistent naming of command-line options for different tools.
Might require changes to the kernel (details depend on the OS, and on whether the terminal runs inside a GUI window):
- proper handling of color. Right now, color is encoded as in-band information (ANSI escape sequences) that confuse various tools, e.g. grep cannot find a substring if there is a color change in the middle of a substring. The workaround is to have all tools detect if they write to the terminal or a pipe and not output color at all, which means that I can't grep without losing color. This might require changing the kernel because the terminal driver that defines how color is encoded sits there (again, might be different in a terminal window in the GUI).
Dropping the idea of plain text output and input.
In reality such text does not exist. It's always structured text: log files, CSV, configuration file formats, markup formats, source code, ...
Language servers for almost any of these already exist, let's use them in the tools.
Things DID improve, e.g. tab-autocomplete evolved very well. But that's not enough, and editor's command palettes show that. I actually thought I'll give some more quick examples than discoverability, but then I realized that you could fill a whole document with them...