What if Haiku’s CLI shell was as friendly as possible to use?
Haiku is primarily a GUI-oriented system sure, but there might be times when someone just has to use a terminal. I think it would be a good idea if it is more approachable and easier to use, in contrast to just having a spartan terminal environment.
I’m not suggesting that Haiku should go full-on Powerline with Nerd Fonts, two-line prompts (although I like this), right-side prompts, etc. But more like having features that improve interactive use such as:
autosuggestions
tab completion navigable with the arrow keys
command history search navigable with the arrow keys
syntax highlighting
etc.
The technical details of how this could be done, I’m not going to get into all that here in this first post in the topic. It could be done via zsh + plugins, fish, a couple utilities shipped like hstr, or something else.
But it’s the overall idea of having a better, easier, default terminal experience in Haiku that I want to put forward. At the very least, this could serve as a passable stopgap until a truly native shell (as discussed here) comes that goes even further.
It’d be nice if something like Commando from A/UX exists for Haiku:
This alongside some of the features I already mentioned earlier would prolly be the farthest that the idea of a friendlier terminal could be taken without a native shell, but this may take an inordinate amount of effort.
Many of these things can’t be done, or can’t be done reliably reliably with a posix conforming shell, and changing the posix shell to not be confirming is something I’d be against.
We have discussed ideas of how to make a better shell for Haiku before, here:
If we do change the shell I’d be more in favor of mksh…
Personally I am used to the simplicity of the very basic setup provided in Haiku and I like it that way.
Providing a super complicated default setup may make it harder to understand and customize. When you do your own thing, maybe it’s better to start from a blank page.
But, the nice thing with shells is you can easily replace the default one and share your configuration. So, this could start with an haikuports package for fish or zsh with some pre-configuration. And if after a while, it looks like alrost everyone is using it, it may become the default someday?
A lot about fish makes sense to me. But the lack of backwards-compatibility has to take it out of contention as a default. There are a googolplex of bash scripts out there that will run under zsh or mksh but not under fish.
We can’t SHFT-ALT-Fkey to a tty in Haiku, so having a dead-simple, straightforward terminal emulator is non-negotiable. Even in Linux, the distro might use a bells-and-whistles emulator, but xterm or rxvt always seems to get installed as a last-line-of-defence backup system.
So I am not in favour of getting rid of Terminal as we know it. That doesn’t mean there can’t be a second, more user-friendly access to the CLI.
Often forgotten, it seems, we do have Konsole. It actually has a lot of extra features already (fond of the splitview myself, who needs a terminal multiplexer?) Not a default package, of course, and rightfully so, but that might be a good place to experiment via add-on packages before we start radically changing Terminal.
Alternatively, fork a new version of Terminal (Fun idea: call it “Terminal H” with an airport theme) that serves as the development platform, while leaving Terminal itself untouched.
Once that is up and running, we can change the documentation to point newbies to the friendly version, while leaving Terminal in place for the hard-core devs and dev wannabes like me
Every feature I’ve mentioned (except for A/UX’s Commando) is possible with zsh + plugins, with some of them being possible with bash + plugins too. Both are POSIX-compliant shells. While typically such plugins are managed with a plugin framework (e.g. zinit, Bash-it, etc.), they can be used without them and this is what I’d recommend for Haiku.
I get that it’s possible, but it can’t be done reliably. As interpretation of argument info on commands is basically arbitrary you don’t know if a tool might accept “–” for example, or maybe that is just true for one version and not another.
One example is posix echo. Posix sais echo takes no arguments, so shouldn’t in theory support --, but some implementations give it arguments regardless. Does it now support – or not? who knows. You can only try to suplement the behavious in files describing the behaviour as you think it works now for a specific command. But there is no way to do this reliably…
This holds especially true for autosuggestions and syntax highlighting.
Regardless, the way bash works is “ok”. I prefer mksh because you can use ctrl^C and have it save your input draft in the history and get back to it. But we should not fundamentally change how this works, the shell is already wierd and foreign compared to normal text input. Where is the mouse cursor support? Why can’t you just select text and delete it from the commandline? etc
You can prefix your command with a # and bash will happily store it in the history as a commented out line.
mksh is a nice simple korn-style shell. I think this discussion here is about getting a shell that does more, not less (there are valid reasons to go either way, of course)
If a command has a manpage, then this can be parsed by the shell for autocompletion and autosuggestion reliably. This can break if the command and its manpage do not match each other, but then again that’s a problem (bad documentation) which should be fixed anyway regardless of shell functionality.
Not really. How it looks in the manpage is a convention. We don’t even have our own manpages but mostly cobbled together ones, so this still wouldn’t be reliable. That’s the key part here, sure you can do it with some ammount of sucess, but you can never trust this system or the autocompletion. Also manpages are not a good source to parse this info from…
We don’t really use manpages anyway. If possible we use HTML docs instead (check git help ), so not sure forcing this to manpages makes sense in any case…
