4 ms·

I'm simultaneously amazed and horrified (by the strange but amazing love child you've created between bash and ruby). I spent years (nearly a decade) trying to

I'm simultaneously amazed and horrified (by the strange but amazing love child you've created between bash and ruby). I spent years (nearly a decade) trying to blend ruby and bash to make the perfect shell, and after never being quite satisfied, I eventually gave up and embraced bash. This does get closer/further than I ever could, and is a fascinating project. I'm going to give it a spin, though I can already imagine the biggest obstacle I'll hit: rubish not being available in the remote environments I need it to, meaning I'll either have to install it (and it's not lightweight currently), or I'll have to live in two different worlds, which isn't usually sustainable. Kudos though, and great work! I can tell you put a lot of thought and effort into it.

matheusmoreira 5mo ago
> 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.
- montroser 5mo ago
  Many, many people have tried...
  - matheusmoreira 5mo ago
    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.
    - freedomben 5mo ago
      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.
      - matheusmoreira 5mo ago
        > 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.
        freedomben 5mo ago
        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.
    - sxldier 5mo ago
      Sorry, which library feature?
      - matheusmoreira 5mo ago
        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
  - em-bee 5mo ago
    ... 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.
    - nasretdinov 5mo ago
      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
      - em-bee 5mo ago
        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)
      - zenoprax 5mo ago
        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.
      - matheusmoreira 5mo ago
        Really like using fish as my interactive shell too.
    - montroser 5mo ago
      Many have succeeded writing functional alternative shells for sure, but none have replaced bash at any meaningful scale.
- 3eb7988a1663 5mo ago
  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/ https://oils.pub/
  - rirze 5mo ago
    I was excited for this years ago, but when I tried it about 2 years ago, it felt awkward. Is it different now?
    - 3eb7988a1663 5mo ago
      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.
  - matthewmc3 5mo ago
    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) }`.
- dylanz 5mo ago
  I've used bash for 20+ years. I've tried so many other shells but always go back to bash. Thanks Brian!
  - matheusmoreira 5mo ago
    Why do you always come back?
- fsckboy 5mo ago
  >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.
itchyouch 5mo ago
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.

matheusmoreira 5mo ago

> 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.

montroser 5mo ago
Many, many people have tried...
- matheusmoreira 5mo ago
  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.
  - freedomben 5mo ago
    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.
    - matheusmoreira 5mo ago
      > 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.
      - freedomben 5mo ago
        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.
  - sxldier 5mo ago
    Sorry, which library feature?
    - matheusmoreira 5mo ago
      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
- em-bee 5mo ago
  ... 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.
  - nasretdinov 5mo ago
    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
    - em-bee 5mo ago
      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)
    - zenoprax 5mo ago
      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.
    - matheusmoreira 5mo ago
      Really like using fish as my interactive shell too.
  - montroser 5mo ago
    Many have succeeded writing functional alternative shells for sure, but none have replaced bash at any meaningful scale.
3eb7988a1663 5mo ago
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/ https://oils.pub/
- rirze 5mo ago
  I was excited for this years ago, but when I tried it about 2 years ago, it felt awkward. Is it different now?
  - 3eb7988a1663 5mo ago
    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.
- matthewmc3 5mo ago
  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) }`.
dylanz 5mo ago
I've used bash for 20+ years. I've tried so many other shells but always go back to bash. Thanks Brian!
- matheusmoreira 5mo ago
  Why do you always come back?
fsckboy 5mo ago
>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.

itchyouch 5mo ago

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.