8 ms·

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.

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.