I don’t really want to go “skill issue” here–least of all because in spite of writing an obnoxious amount of bash over the last few years I still fuck it up regularly–but I do think it’s important to note there’s a difference in kind for these complaints.
Having nonstandard shells on different machines is the result of not just using a common shell–you’re almost always (yes, yes, containers are a thing, sit down there in the back) gonna have either sh or bash if you want it (and yes at least for a while the default bash on OSX was old and you needed to upgrade it to get things like associative arrays). There is a reason I put my skill points into bash instead of zsh, fish, oilsh, ksh, csh, or even powershell–all better shells, none as ubiquitous. But, anyways, that complaint is at least about shells.
The shortcuts and terminal-itself complaints about things like keyboard shortcuts and copy-paste behavior are unique to the terminal environment, and vary across using a browser window, one of any of the dozen X11 terminals, PuTTY (remember that lol), and so on and so forth–but again, that’s neither the shell nor the programs.
And then finally, issues around discoverability and arguments and whatnot are squarely the problem of the utilities. Some utilities are nice and straightforward (albeit this is more a BSD thing than a GNU thing) and have a single command with some flags. Some utilities are relatively consistent but simply so large as to defy easy reference (I’m looking at you FFMPEG, where the problem domain is simply so large it can’t be wrapped up neatly). Some tools have some warts (git), and some tools seemed like they deliberately eschewed reasonable and legible convention (seriously, fuck the constellation of nix and nixos CLI tooling).
Anyways, I think that it’s worth it to remember that these frustrations are really probably clustered around different layers of the stack, and to approach it that way instead of by vertical slice (though we do tend to think in terms of “I just want to look at cat pictures on the terminal and get street cred” instead of “okay so I’m pretty sure uxrvt supports color sixel and I think I remember how to get curl to use redirection to aalib in bash”).
FWIW Oils is unique among these, in that it has OSH, which is POSIX and bash-compatible. (YSH is the incompatible shell)
OSH is actually more POSIX compatible than dash, the default /bin/sh on Debian
It’s also the most bash-compatible shell.
Right now you will get better error messages, and it’s faster in some cases, but eventually we will add some more distinguishing features, like perhaps profiling of processes
There is also a developing “OSH standard library” for task files and testing, which runs under bash too
Definitely agree about the layers. Can you imagine a similarly open-ended survey about frustrations with GUIs? But the lack (or mere locality) of standards and conventions is a real problem in any human interface, even apart from the inadequacies of the standards that do exist.
That worse-is-better, least-common-denominator thing about bash, though: that’s a wicked problem. Not a huge one, but still. It’s the reason I gave up on fish, despite liking basically everything about it better than any other shell I’ve tried. At least oils has a well-though-out compatibility story that could enable systematic upgrades… but that’s still a lot of work, against (or any way across) stiff currents of cultural inertia.
There’s a general feeling that shell scripting is difficult but also that switching to a different less standard scripting language (fish, nushell, etc) brings its own problems.
My tolerance to ditch a shell script and go to a scripting language is pretty low. It’s just too messy and powerful. Screwing up can be costly so I don’t even bother.
To me the linked survey responses are more interesting than the complaints. I am impressed that 67% of respondents know Ctrl-R and over 50% know C-a and C-e. That’s some serious Emacs literacy rate :)
The bsky and mastodon responses are interesting to compare too.
I think actual Emacs literacy is fairly reduced (there’s actually results about Emacs use and they’re on the order of 8-13%) – lots of people use them without actually using Emacs. I’ve introduced them to colleagues who used vim, and they continued to use their obviously inferior editor vim afterwards, too.
Forever ago I think OS X (it was OS X at the time…) supported Emacs keybindings in its UI, too.
Regarding the documentation issue, two suggestions:
https://tldr.sh/ allows to quickly get examples for CLI tools. E.g. tldr tar shows how to create or unpack an archive. While manpages provide a reference documentation, tldr adds the necessary examples.
Btw. in 2023 I made a note for myself: “currently the Rust client appears to be the best one”. No idea if that’s still the case.
for some reason there are no manpages for Bash built-in commands (like “alias”), and instead help must be used. I added this line to my ~/.bashrc to automatically get the help output if I use man: man() { /usr/bin/man "$1" || help "$1"; } .
It would be nice though if Bash “just” fixed this and provided its help contents also as manpages. But the cynic in me thinks that we will more likely get a man replacement that does a live query to ChatGPT, than Bash providing manpages.
I’d love to see a modern terminal implementation. Using non standard keys shouldn’t be this hard. Some, like Kitty, have tried but those are more of an addon instead of a redesign.
If you want to better manage your command history by project with docs/comments take a look at tome playbooks (by me). It also helps with multiline pasting.
Curious if you’ve tried Ghostty. Seems promising. I’ll need history search and better scrollback UX before I switch full time myself, but I believe the keybindings are configurable and the speed is impressive.
I meant the keys for apps running in the terminal. For example mapping different actions for Tab and Ctrl+I in vim can be difficult, even more so with tmux in the middle.
I’ve thought about this too. I think it’s kinda gotten to the point where you’d kinda need to be willing to throw away old bad ideas and accept that it will break some programs. Make an experimental rework of some of the core pieces, wait for/help libs like ncurses and termbox to use that functionality, and then help other terminals implement it. Even just a standard feature-detection mechanism would be really nice.
Some, like Kitty, have tried but those are more of an addon instead of a redesign.
“Fully rewrite the terminal” is not the path forward. Kitty’s design is appropriate, IMU it’s basically a switch that enables a full keyboard protocol that any app can opt into. Just like Kitty was able to add a full graphics protocol to the terminal, it can be extended, people just need to agree on extensions.
I’d rather have a new terminal protocol and a legacy layer. That would encourage more developers to support it IMO and make it easier for users as well to find out what works with what.
I don’t really want to go “skill issue” here–least of all because in spite of writing an obnoxious amount of bash over the last few years I still fuck it up regularly–but I do think it’s important to note there’s a difference in kind for these complaints.
Having nonstandard shells on different machines is the result of not just using a common shell–you’re almost always (yes, yes, containers are a thing, sit down there in the back) gonna have either sh or bash if you want it (and yes at least for a while the default bash on OSX was old and you needed to upgrade it to get things like associative arrays). There is a reason I put my skill points into bash instead of zsh, fish, oilsh, ksh, csh, or even powershell–all better shells, none as ubiquitous. But, anyways, that complaint is at least about shells.
The shortcuts and terminal-itself complaints about things like keyboard shortcuts and copy-paste behavior are unique to the terminal environment, and vary across using a browser window, one of any of the dozen X11 terminals, PuTTY (remember that lol), and so on and so forth–but again, that’s neither the shell nor the programs.
And then finally, issues around discoverability and arguments and whatnot are squarely the problem of the utilities. Some utilities are nice and straightforward (albeit this is more a BSD thing than a GNU thing) and have a single command with some flags. Some utilities are relatively consistent but simply so large as to defy easy reference (I’m looking at you FFMPEG, where the problem domain is simply so large it can’t be wrapped up neatly). Some tools have some warts (git), and some tools seemed like they deliberately eschewed reasonable and legible convention (seriously, fuck the constellation of nix and nixos CLI tooling).
Anyways, I think that it’s worth it to remember that these frustrations are really probably clustered around different layers of the stack, and to approach it that way instead of by vertical slice (though we do tend to think in terms of “I just want to look at cat pictures on the terminal and get street cred” instead of “okay so I’m pretty sure uxrvt supports color sixel and I think I remember how to get curl to use redirection to aalib in bash”).
FWIW Oils is unique among these, in that it has OSH, which is POSIX and bash-compatible. (YSH is the incompatible shell)
OSH is actually more POSIX compatible than dash, the default
/bin/shon DebianIt’s also the most bash-compatible shell.
Right now you will get better error messages, and it’s faster in some cases, but eventually we will add some more distinguishing features, like perhaps profiling of processes
There is also a developing “OSH standard library” for task files and testing, which runs under bash too
Definitely agree about the layers. Can you imagine a similarly open-ended survey about frustrations with GUIs? But the lack (or mere locality) of standards and conventions is a real problem in any human interface, even apart from the inadequacies of the standards that do exist.
That worse-is-better, least-common-denominator thing about bash, though: that’s a wicked problem. Not a huge one, but still. It’s the reason I gave up on fish, despite liking basically everything about it better than any other shell I’ve tried. At least oils has a well-though-out compatibility story that could enable systematic upgrades… but that’s still a lot of work, against (or any way across) stiff currents of cultural inertia.
FWIW, the testing story in Nushell is pretty nice, and the structured data types make mistakes less costly and easier to diagnose. Not prod-ready yet, but IMO so much nicer than POSIX.
To me the linked survey responses are more interesting than the complaints. I am impressed that 67% of respondents know Ctrl-R and over 50% know C-a and C-e. That’s some serious Emacs literacy rate :)
The bsky and mastodon responses are interesting to compare too.
I think actual Emacs literacy is fairly reduced (there’s actually results about Emacs use and they’re on the order of 8-13%) – lots of people use them without actually using Emacs. I’ve introduced them to colleagues who used vim, and they continued to use
their obviously inferior editorvim afterwards, too.Forever ago I think OS X (it was OS X at the time…) supported Emacs keybindings in its UI, too.
macOS still has some Emacs bindings in text fields.
Regarding the documentation issue, two suggestions:
https://tldr.sh/ allows to quickly get examples for CLI tools. E.g.
tldr tarshows how to create or unpack an archive. While manpages provide a reference documentation,tldradds the necessary examples.Btw. in 2023 I made a note for myself: “currently the Rust client appears to be the best one”. No idea if that’s still the case.
for some reason there are no manpages for Bash built-in commands (like “alias”), and instead
helpmust be used. I added this line to my ~/.bashrc to automatically get thehelpoutput if I useman:man() { /usr/bin/man "$1" || help "$1"; }.It would be nice though if Bash “just” fixed this and provided its help contents also as manpages. But the cynic in me thinks that we will more likely get a
manreplacement that does a live query to ChatGPT, than Bash providing manpages.I’d love to see a modern terminal implementation. Using non standard keys shouldn’t be this hard. Some, like Kitty, have tried but those are more of an addon instead of a redesign.
If you want to better manage your command history by project with docs/comments take a look at tome playbooks (by me). It also helps with multiline pasting.
https://github.com/laktak/tome
Extrakto, also for tmux, makes it easier to select and copy (also mine):
https://github.com/laktak/extrakto
Curious if you’ve tried Ghostty. Seems promising. I’ll need history search and better scrollback UX before I switch full time myself, but I believe the keybindings are configurable and the speed is impressive.
I meant the keys for apps running in the terminal. For example mapping different actions for Tab and Ctrl+I in vim can be difficult, even more so with tmux in the middle.
I’ve thought about this too. I think it’s kinda gotten to the point where you’d kinda need to be willing to throw away old bad ideas and accept that it will break some programs. Make an experimental rework of some of the core pieces, wait for/help libs like ncurses and termbox to use that functionality, and then help other terminals implement it. Even just a standard feature-detection mechanism would be really nice.
Not sure you’d have to break anything if you add a translation layer. Isn’t that what tmux and vim with its integrated terminal are doing already?
“Fully rewrite the terminal” is not the path forward. Kitty’s design is appropriate, IMU it’s basically a switch that enables a full keyboard protocol that any app can opt into. Just like Kitty was able to add a full graphics protocol to the terminal, it can be extended, people just need to agree on extensions.
I’d rather have a new terminal protocol and a legacy layer. That would encourage more developers to support it IMO and make it easier for users as well to find out what works with what.
Cool, go for it.
My biggest issue is that I open too many terminals in my tiling window manager.