3 ms·

I would be very happy to see shells shed the idea that everything needs to be done in the context of emulating a terminal from the 70s. But even though new shel

I would be very happy to see shells shed the idea that everything needs to be done in the context of emulating a terminal from the 70s. But even though new shells exist, I always end up writing shell scripts in ancient Bourne because I want them to run out of the box instead of requiring a third-party shell to be installed. Is there no appetite for a new default shell that could be adopted by Linux, macOS, and BSDs?

hiAndrewQuinn 2y ago
You could be the first! Fork Ubuntu, leave everything else the same, but have it run `fish` as the default shell with `bash` as a fallback. Alternatively, you could install default Ubuntu and run https://github.com/hiAndrewQuinn/shell-bling-ubuntu 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.
- dotancohen 2y ago
  You've really modernized the CLI there. I've been resisting doing that because I SSH into other machines often enough, but with your script I might just start. Thank you, nice work! 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.
sakjur 2y ago
Having been recently exposed to PowerShell, I’m quite impressed by the balance they’ve struck in developing a new shell. I wouldn’t want to switch out Bash for PowerShell, but that’s mostly based on the same reasoning as you have (I can’t be bothered to install new shells everywhere). 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?
- Timwi 2y ago
  > Binaries are much more capable than what I’m suggesting, though they are platform dependent. Not if they're .NET/IL/CLR (which is an ECMA standard).
  - sakjur 2y ago
    Fair, though that’s still dependent on having a platform that follow that spec, in this case the common denominator for the platforms in question is POSIX rather than CLR.
flohofwoe 2y ago
IMHO instead of offering a builtin programming language, shells should make it easy to launch scripts written in 'foreign' languages (maybe via a more informative shebang block at the top). I want to write my 'shell scripts' in Python, Typescript or Lua and those scripts should work on any shell and on any platform (including Windows outside WSL).
- dotancohen 2y ago
  That's what /usr/bin/env is for: a standard path to reference interpreters. There is still the issue of the proper interpreter actually being installed, however.
  - flohofwoe 2y ago
    > 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).
    - poincaredisk 2y ago
      This is already possible with #!/usr/bin/env nix-shell
- kragen 2y ago
  unix tried that in the 70s, ms-dos batch files tried it in the 80s. turns out offering a builtin programming language is good actually
jrimbault 2y ago
The Redox project uses their own Ion shell https://doc.redox-os.org/ion-manual/ https://doc.redox-os.org/ion-manual/ which isn't posix
setopt 2y ago
> I would be very happy to see shells shed the idea that everything needs to be done in the context of emulating a terminal from the 70s. 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.)
aragilar 2y ago
Over what timeframe do you expect this to happen? It'll take at least 10 years for a new default on all systems (which is a challenge in of itself) to propagate to the point where you could rely on it. 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).
viraptor 2y ago
Switching away from being bash compatible would be really unexpected. Too many existing scripts and websites explaining how to do things. Maybe something like http://www.oilshell.org/ http://www.oilshell.org/ has a chance though? If we were breaking away from the old style shells completely, then https://www.nushell.sh/ https://www.nushell.sh/ would be my preferred upgrade.
- poincaredisk 2y ago
  I use fish personally. I don't see value in using a bash compatible shell for interactive use (I can run bash scripts anyway, just like I can run python and perl scripts)
  - fragmede 2y ago
    The value is in using the same language for scripting as interacting with the computer as a shell, so that you're more fluent in that language when it comes out writing things with that language.
  - setopt 2y ago
    The benefit is if you often have to work on remote servers where only Bash is available. 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.

hiAndrewQuinn 2y ago

You could be the first! Fork Ubuntu, leave everything else the same, but have it run `fish` as the default shell with `bash` as a fallback. Alternatively, you could install default Ubuntu and run https://github.com/hiAndrewQuinn/shell-bling-ubuntu 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.

dotancohen 2y ago
You've really modernized the CLI there. I've been resisting doing that because I SSH into other machines often enough, but with your script I might just start. Thank you, nice work! 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.

sakjur 2y ago

Having been recently exposed to PowerShell, I’m quite impressed by the balance they’ve struck in developing a new shell. I wouldn’t want to switch out Bash for PowerShell, but that’s mostly based on the same reasoning as you have (I can’t be bothered to install new shells everywhere). 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?

Timwi 2y ago
> Binaries are much more capable than what I’m suggesting, though they are platform dependent. Not if they're .NET/IL/CLR (which is an ECMA standard).
- sakjur 2y ago
  Fair, though that’s still dependent on having a platform that follow that spec, in this case the common denominator for the platforms in question is POSIX rather than CLR.

flohofwoe 2y ago

IMHO instead of offering a builtin programming language, shells should make it easy to launch scripts written in 'foreign' languages (maybe via a more informative shebang block at the top). I want to write my 'shell scripts' in Python, Typescript or Lua and those scripts should work on any shell and on any platform (including Windows outside WSL).

dotancohen 2y ago
That's what /usr/bin/env is for: a standard path to reference interpreters. There is still the issue of the proper interpreter actually being installed, however.
- flohofwoe 2y ago
  > 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).
  - poincaredisk 2y ago
    This is already possible with #!/usr/bin/env nix-shell
kragen 2y ago
unix tried that in the 70s, ms-dos batch files tried it in the 80s. turns out offering a builtin programming language is good actually

jrimbault 2y ago

The Redox project uses their own Ion shell https://doc.redox-os.org/ion-manual/ https://doc.redox-os.org/ion-manual/ which isn't posix

setopt 2y ago

> I would be very happy to see shells shed the idea that everything needs to be done in the context of emulating a terminal from the 70s. 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.)

aragilar 2y ago

Over what timeframe do you expect this to happen? It'll take at least 10 years for a new default on all systems (which is a challenge in of itself) to propagate to the point where you could rely on it. 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).

viraptor 2y ago

Switching away from being bash compatible would be really unexpected. Too many existing scripts and websites explaining how to do things. Maybe something like http://www.oilshell.org/ http://www.oilshell.org/ has a chance though? If we were breaking away from the old style shells completely, then https://www.nushell.sh/ https://www.nushell.sh/ would be my preferred upgrade.

poincaredisk 2y ago
I use fish personally. I don't see value in using a bash compatible shell for interactive use (I can run bash scripts anyway, just like I can run python and perl scripts)
- fragmede 2y ago
  The value is in using the same language for scripting as interacting with the computer as a shell, so that you're more fluent in that language when it comes out writing things with that language.
- setopt 2y ago
  The benefit is if you often have to work on remote servers where only Bash is available. 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.