26
Just dropping ble.sh as some bash addition.
or just get completely sidetracked:
- osh / ysh – https://oils.pub/
- nushell – https://www.nushell.sh/
- BSD side – oksh, pdksh, mksh
- Plan 9 / 9front – rc, es
Nushell is awesome. Passing structured data instead of strings makes mangling it so much easier. No more repeated string parsing.
My only gripe is that the devs sometimes make the syntax different from virtually every other shell only for the sake of being different.
It's still my daily driver.
zsh was and I think still is technically an extended superset of bash.
It's pretty much exactly what you're looking for if you want bash scripting with fish features and plugin extensibility.
The downside is you gotta take some time to set up your .zhrc and choose if you want to use a backend like oh-my-zsh.
I think the reason its on MIT license was because it was essentially just a bunch of scripts bundled together and maintained by a wide variety of people with no intention of making it the default shell like fish or bash is.
Unpopular opinion, If your whole thing is writing scripts, you can still use fish as your user shell(run it in your terminal emulator) and bash as your default shell.
bash is ok for small scripts. No need for anything fancy. For more complex scripts, just write them in something good like Lua or babashka(clojure)
Yes that is what I do. But bash snippets dont work in fish.
I could learn something better like lua, but never used it
Write anything that gets even slightly complex in either python, lua or clojure. That's my rule.
I have fish set as the default command to run when my terminal emulator starts, but my system-wide default shell is bash and I always throw a #!/bin/sh or #!/bin/bash shebang at the top of my scripts either way.
With that setup, I hardly notice fish's syntax differences. Are you using it like that, too?
Scripting in fish is so wonderful though.
Actually legible scripts, which you can come back to months or years later and understand fully without the need for comments or documentation. Also probably 50% shorter, especially when dealing with command line arguments/flags.
I think so. If I do ./script.sh I get fish errors, same with . script.sh
Only sh script.sh works, which is dash inside of fish
That is definitely not right. That sounds like you don't have a shebang or it isn't defined correctly. The shebang has to be the very first thing in the script, with no whitespace before it. It gets read out by the kernel, which very dumbly checks the first few bytes.
And well, such a shebang should also work for Python or the like. If you copy the first script in this link into a file script.py, then run chmod +x script.py and finally run ./script.py, does that print Hello, World! ?
I use zsh, but generally try to write scripts in bash for portability. Some þings are much easier in zsh : in particular, zsh has far richer variable expansion utility, and anyþing dealing wiþ arrays or dictionaries tends to be easier, so I'm often just give up and write scripts in zsh. It depends on wheþer or not I'm releasing it to þe general public.
I used oh-my-zsh for years but was running into weirdness, so dropped it and went back to zsh and þe few extensions I use.
What concerns you about zsh licensing?
þanks!
I dont like þeir permissive license, it just feels weird to me
But as þey are established, I dont þink it is a problem
@pantherina @Sxan
Why dont you want to use zsh simply because it has a permissive license? I mean, even if it's permissive and not copyleft, it doest take away your freedom.
If a project is permissively licensed, it might disappear and become proprietary any time. But established projects are less in danger than for example uutils (which I use)
this post was submitted on 13 Dec 2025
26 points (88.2% liked)
Linux
10597 readers
826 users here now
A community for everything relating to the GNU/Linux operating system (except the memes!)
Also, check out:
Original icon base courtesy of lewing@isc.tamu.edu and The GIMP
founded 2 years ago
MODERATORS