undefined

points

[-]

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.

by freedomben7 hours ago|

parent|

[-]

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.

by matheusmoreira6 hours ago|

parent|

[-]

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

by freedomben6 hours ago|

parent|

[-]

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.

by em-bee5 hours ago|

prev|

[-]

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

by nasretdinov4 hours ago|

parent|

[-]

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

by zenoprax4 hours ago|

parent|

[-]

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.

by em-bee4 hours ago|

parent|

prev|

[-]

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)

by matheusmoreira4 hours ago|

parent|

prev|

[-]

Really like using fish as my interactive shell too.

by montroser4 hours ago|

parent|

prev|

[-]

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

by em-bee4 hours ago|

parent|

[-]

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.