new | ask | show | jobs
matheusmoreira 8 hours 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 8 hours 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 8 hours 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 8 hours 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.