In Emacs, there is a big difference between M-x vterm (which emulates a 70s terminal), M-x shell (which doesn’t emulate a terminal, but still runs e.g. bash underneath), and M-x eshell (which replaces bash etc. completely, and thus offers abstractions like “cd into an ssh: path”, “cp this file from an ssh: path”, “pipe this file through an Emacs function”, etc. that you normally don’t expect). If you’re into alternative ways of working with shells this might be interesting.
(With that said, I myself went back to a “real” terminal. These days I’m using Zsh in iTerm2.)
Alternatively, you could install default Ubuntu and run https://github.com/hiAndrewQuinn/shell-bling-ubuntu to switch your terminal to fish, kitty, and get a whole slew of other niceties in there by default. I found myself doing this a lot at my last job in VMs, which is why I have this set of shell scripts lying around and easy to audit.
As another big rg and tree (and ncdu, do you know of this) user, I highly suggest rotating one monitor 90 degrees. These tools with long output really benefit, as does web browsing, coding, and even the ability to see an entire page of a PDF without scrolling or making it tiny.
Though in a sense I think the most viable solution would be almost the opposite for UNIX: a reduced (and strict) shell syntax intended to be the target of crosscompilation rather than manual use. If it’d be possible to make that a subset of the standardized sh, there’d be automatic compatibility from the start and adoption wouldn’t need to happen on the consumer side.
Still, we have binaries already. Binaries are much more capable than what I’m suggesting, though they are platform dependent. A variant of WASM, maybe?
Not if they're .NET/IL/CLR (which is an ECMA standard).
If we were breaking away from the old style shells completely, then https://www.nushell.sh/ would be my preferred upgrade.
Then, using the same interactive syntax locally and remotely is simply less jarring, since switching between e.g. the Fish and Bash for-loop syntax every hour causes lots of mix-ups. (I write a lot of loops interactively in the CLI.)
I used Fish for ~5 years and loved it, but I ended up going back to Zsh myself.
There's also the question of what new language is worth the cost of the transition period (no new shell I've seen justifies the change).
There is still the issue of the proper interpreter actually being installed, however.
Yeah, that's what I mean with "make it easy". The script header should announce requirements (like what language and language version it is written in, and the shell should be able to ensure those requirements before running the script - without ignoring security aspects of course). E.g. every script should be able to bootstrap itself, no matter what programming language is used (and that might even include compiled languages).