4 ms·

Bash is ugly and rife with pitfalls, but it can be incredibly productive for certain classes of problems if you know what you’re doing. Trying to use Python or

Bash is ugly and rife with pitfalls, but it can be incredibly productive for certain classes of problems if you know what you’re doing. Trying to use Python or Go to whack some external commands together feels very cumbersome to me. For pure programming, “real” languages are absolulely preferable in almost every way, but all of them fail when it comes to running external programs and redirecting their output in a way that doesn’t make me pull my hair out. As a heavy user of both “real” programming languages and shell scripting languages, I’m left craving something that brings the best of both worlds. There are a number of newer shell projects in this vein that are very exciting, like Oil [0], Elvish [1], and Xonsh [2]. I was also hopeful that Neugram [3] would go somewhere, but the project seems to have died out. While many people cite Bash’s lack of portability as a reason not to use it, I find Bash to be very portable for my use cases and avoid using these newer shells for their lack of portability. Maybe one day we can have nice things. [0]: https://github.com/oilshell/oil https://github.com/oilshell/oil [1]: https://github.com/elves/elvish https://github.com/elves/elvish [2]: https://github.com/xonsh/xonsh https://github.com/xonsh/xonsh [3]: https://github.com/neugram/ng https://github.com/neugram/ng

throwaway823882 6y ago
Sad that none of those projects took the easy route. If you want to replace Bash, do it the way Bash replaced Bourne: Make it backwards compatible. Bash acts like 'historical versions of sh' if it was invoked as sh. So, a Bash replacement could act like Bash if it was invoked like bash. Then implement all the extra crazy shit if you invoke it as slash or something. Assuming it was a small, fast, compiled binary, this would take off in all the distros pretty much immediately. And if you really want it to succeed, implement a spec first, and implementations second. Add a slash implementation to Busybox, and then it's on every embedded Linux system in the world.
- maddyboo 6y ago
  It would certainly be nice, but I wouldn’t call that the easy route. Creating a new shell that’s fully backwards compatible with the monstrosity that is Bash sounds like a massive undertaking. POSIX or the Bourne shell is probably an easier target, and there are numerous alternative shells that are POSIX-compatible and add nice new features or optional alternate syntaxes. But I agree, to properly dethrone Bash would probably require backwards compatibility with it.
  - hnlmorg 6y ago
    Personally I don't see the point dethroning bash. I mean Bash still hasn't completely dethroned the Bourne shell. And now there is a lot more competition in shells than there ever was. Personally I think the better approach is to accept that bash/sh will always be about for legacy stuff and for alternative shells to carve out a niche elsewhere. Particularly because to some of bash/sh's pain points can't be addressed without break compatibility in the first place (like handling file names with spaces).
- hnlmorg 6y ago
  Literally the first in the GPs list, Oil shell, aims to do just that. > Oil is a new Unix shell. It's our upgrade path from bash to a better language and runtime. https://www.oilshell.org/blog/2021/01/why-a-new-shell.html https://www.oilshell.org/blog/2021/01/why-a-new-shell.html
hnlmorg 6y ago
It's worth adding mine to the list too: [4]: https://github.com/lmorg/murex https://github.com/lmorg/murex Superficially it's quite similar to elvish (purely by coincidence) but it's aimed around local machine use (eg by developers and devops engineers) so is as much inspired by IDEs as it is by shells.
andrewshadura 6y ago
> Trying to use Python or Go to whack some external commands together feels very cumbersome to me. Try https://amoffat.github.io/sh/ https://amoffat.github.io/sh/ from sh.contrib import git git.reset(hard=True)
- maddyboo 6y ago
  Wow that’s cool. Thanks for sharing.
- PhantomGremlin 6y ago
  How is this better than just using subprocess? Faster? More elegant? The doc says: sh is a full-fledged subprocess replacement It would be nice if that page had some sort of comparison. I guess the examples shown are sufficient if you're a regular user of subprocess?

throwaway823882 6y ago

Sad that none of those projects took the easy route. If you want to replace Bash, do it the way Bash replaced Bourne: Make it backwards compatible. Bash acts like 'historical versions of sh' if it was invoked as sh. So, a Bash replacement could act like Bash if it was invoked like bash. Then implement all the extra crazy shit if you invoke it as slash or something. Assuming it was a small, fast, compiled binary, this would take off in all the distros pretty much immediately. And if you really want it to succeed, implement a spec first, and implementations second. Add a slash implementation to Busybox, and then it's on every embedded Linux system in the world.

maddyboo 6y ago
It would certainly be nice, but I wouldn’t call that the easy route. Creating a new shell that’s fully backwards compatible with the monstrosity that is Bash sounds like a massive undertaking. POSIX or the Bourne shell is probably an easier target, and there are numerous alternative shells that are POSIX-compatible and add nice new features or optional alternate syntaxes. But I agree, to properly dethrone Bash would probably require backwards compatibility with it.
- hnlmorg 6y ago
  Personally I don't see the point dethroning bash. I mean Bash still hasn't completely dethroned the Bourne shell. And now there is a lot more competition in shells than there ever was. Personally I think the better approach is to accept that bash/sh will always be about for legacy stuff and for alternative shells to carve out a niche elsewhere. Particularly because to some of bash/sh's pain points can't be addressed without break compatibility in the first place (like handling file names with spaces).
hnlmorg 6y ago
Literally the first in the GPs list, Oil shell, aims to do just that. > Oil is a new Unix shell. It's our upgrade path from bash to a better language and runtime. https://www.oilshell.org/blog/2021/01/why-a-new-shell.html https://www.oilshell.org/blog/2021/01/why-a-new-shell.html

hnlmorg 6y ago

It's worth adding mine to the list too: [4]: https://github.com/lmorg/murex https://github.com/lmorg/murex Superficially it's quite similar to elvish (purely by coincidence) but it's aimed around local machine use (eg by developers and devops engineers) so is as much inspired by IDEs as it is by shells.

andrewshadura 6y ago

> Trying to use Python or Go to whack some external commands together feels very cumbersome to me. Try https://amoffat.github.io/sh/ https://amoffat.github.io/sh/ from sh.contrib import git git.reset(hard=True)

maddyboo 6y ago
Wow that’s cool. Thanks for sharing.
PhantomGremlin 6y ago
How is this better than just using subprocess? Faster? More elegant? The doc says: sh is a full-fledged subprocess replacement It would be nice if that page had some sort of comparison. I guess the examples shown are sufficient if you're a regular user of subprocess?