> I can already imagine the biggest obstacle I'll hit: rubish not being available in the remote environments I need it to

The ubiquitousness of bash is among the few reasons why it continues to endure. It will be eternal if nobody tries to replace it.

Many, many people have tried...

Yeah. I will probably join their ranks at some point.

Bash maintainer actually implemented the library feature I suggested and it's already dramatically cut down the amount of unsightly bash code I need to keep around and maintain.

I'm getting pretty tired of coping with old stuff just because it's there though. Went through this phase with GNU make too.

I struggle with this too. On the plus side, the devil you know is often better than the devil you don't know, and anything new will require re-learning a lifetime's worth of muscle memory. It's also nice to know that your bash scripts are going to be hyper-portable and will still work even many years later. The muscle memory is also real. However it isn't great to be constrained with unsightly code for sake of extreme backwards compatibility. I've found a nice balance personally where I use ruby if I need anything that bash isn't good at, but it's never a perfectly clean split.

> It's also nice to know that your bash scripts are going to be hyper-portable

Doubt. I'm up to my neck in bashisms, and I require the very latest bash on top of that.

  import() {
    local f
    for f in "$@"; do
      [[ -v loaded[$f] ]] && continue
      loaded[$f]=1
      source -p "${HOME}/.local/lib/bash" "${f}"
    done
  }

  import arguments terminal

The -p flag for source landed in bash 5.3.

Well yes, if you're using newer features, it's not going to be available on older systems that lack a newer bash version with those features available. I think that's pretty reasonable, otherwise we'd have to freeze the language and never add anything. But your older scripts will be very portable between future systems, and across different distros once they update. If you need to target an older system, you can't use newer features, but that's true of everything so I wouldn't expect any different from bash.

Sorry, which library feature?

I proposed adding an import builtin to bash on the mailing list. Sent patches too. Didn't go very well, to say the least.

Nevertheless, a version of the feature landed in bash 5.3.

  source -p "${HOME}/.local/lib/bash" file

You can use that to implement the library import function yourself.

  import() {
    local f
    for f in "$@"; do
      [[ -v loaded[$f] ]] && continue
      loaded[$f]=1
      source -p "${HOME}/.local/lib/bash" "${f}"
    done
  }

  import arguments terminal

... and many also have succeeded. fish would not be as popular as it is otherwise, other alternative shells that break bash compatibility are being worked on and are gaining traction, elvish, nushell, murex...

mixing shells is not as hard as some people claim. it's like switching programming languages. i do that all the time. but then, i avoid bash scripting as much as i can (or shell scripting in general). if you actually enjoy bash scripting then switching may be harder.

I might be in a minority, but I actually prefer fish as an interactive shell and bash (or plain /bin/sh) for scripting, if anything because that's what I'm used to :), and it's portable

I did the same thing but I'm now pushing it a bit further: POSIX shell rather than Bash for scripts. If what I'm doing can't be done with that it suggests that I should probably just write it in Python or Perl instead.

Fish scripting is limited to functions/aliases and this works out well since they're easy to read and tweak over time.

that's a sensible approach. fish does have the best interactive interface out there. i switched to elvish because i like it better for complex commandlines, mainly because it has support for more advanced data structures and also integrates json well. (and i realized that using braces for code blocks is nicer in a complex one line command, but both are better than bash for interactive use)

Really like using fish as my interactive shell too.

Many have succeeded writing functional alternative shells for sure, but none have replaced bash at any meaningful scale.

disagree. the fact that i can see more and more support for fish and also start seeing support for elvish shows that those alternative shells have reached a scale meaningful enough that tool developers actually consider it worth their effort to support them. what else is that if not evidence that alternative shells have reached a meaningful scale?

before fish basically noone dared to break bash compatibility. zsh is bash on steroids and other incompatible shells like csh, tcsh, ksh, etc were dead ends in that they kept a niche status.

fish was the first shell to break out of that and actually get noticed and gain a following. i believe that all other alternative shells after fish were encouraged only because of fish's popularity.

I am deeply hopeful that Oil Shell (now just Oils) will get embraced by a big distro as the standard shell at some point. The lowest friction migration I see available while still offering a bunch of improvements.

https://oils.pub/

As far as I can tell with oils, they haven't fully defined what YSH is going to be yet - you basically have OSH (the bash compatibility syntax), with the option to add YSH features as a bolt on. It'd be like Zsh shipping with a built-in Fish-mode to create hybrid scripting. The interesting thing with shells like Xonsh and now rubish is that theoretically the shell language isn't some new thing you have to learn like with elvish and nushell, but is a known programming language with shell features. Rubish looks like it takes the most interesting parts of Oils and Xonsh, in that it's bash compatible, but you could also do a Ruby statement like `ls.each { |f| printf "%s: %d bytes\n", f, File.size(f) }`.

I was excited for this years ago, but when I tried it about 2 years ago, it felt awkward. Is it different now?

No help here. I daily drive fish, and subscribe to the philosophy that more than 5 lines of bash is probably a mistake. That being said, I still run into bash everywhere and wish that there was a more robust default installed already. Something which did not require pathological monitoring by shellcheck.

>The ubiquitousness of

and here I was thinking ubiquity was ubiquitous for this concept

>ubiquity of bash is among the few reasons...

I guess I'm getting older than I thought, I feel uneasy pangs every time I use a bashism because /bin/sh is the ubiquitous one.

I've used bash for 20+ years. I've tried so many other shells but always go back to bash. Thanks Brian!

Why do you always come back?

I had a very similar reaction.

I went the same way with simply bumping up my bash skills.

Part of me feels like I'd prefer pry loaded with a library that provides shell like methods for doing ruby-esque things.