Hacker News Reader

Hacker News

Comment by chasil | Hacker News Reader

Parent Full thread

chasil

Try using the Windows busybox port of "Bash":

https://frippery.org/busybox/index.html

It has a subset of bash implemented on Ash/Dash. Arrays are not supported, but it is quite fast.

The forking problem is still present, though.

View on HN

Cygwin bash isn't slow either. The problem is a typical bash script isn't a series of bash operations, it's a series of command line program executions.

For example, someone might do something like this (completely ignoring the need to quote in the interests of illustrating the actual issue, forking):

    for x in *; do
      new_name=$(echo $x | sed 's/old/new/')
      mv $x $new_name
    done

Instead of something like this:

    for x in *; do
      echo $x
    done | sed -r 's|(.*)old(.*)|mv \1old\2 \1new\2|' | grep '^mv ' | bash

This avoids a sed invocation per loop and eliminates self-renames, but it's harder to work with.

Of course the code as written is completely unusuable in the presence of spaces or other weird characters in filenames, do not use this.

No, seriously, give an ash-derivative a try.

Dash has been benchmarked as 4x faster than bash. The bash manpage ends by stating that "bash is too big, and too slow."

> No, seriously, give an ash-derivative a try.

To solve the problem or because you saw "slow" and "bash" and wanted to bring up something cool but unrelated?

If I go from 10 seconds of forking and .04 seconds of shell to 10 seconds of forking and .01 seconds of shell, I don't actually care about how cool and fast the shell is. And I've never had the speed of bash itself be a problem.

No, because the Ada gsh also proved that the POSIX shell syntax could perform far better.

Bash is prominent in announcing that it is "too big and too slow." It has said this for years. Why are its supporters so firmly in denial?

Your focus here, with a whole comment just quoting the line, makes it sound like you're motivated by smugness, not an actual attempt to help.

Optimizations are cool and all, but being 4x faster at something that's already taking negligible time is not something that makes a big difference.

How long ago was that line written anyway? It feels like complaining about emacs using its "8 megabytes" of memory in the modern day.

The solution to this problem is to reduce the number of forks. Faster code on either side is aesthetically nice but unhelpful.

It's not "denial" to acknowledge that an already-fast program has a faster replacement and then get back to working on the bottlenecks.

I actually need a fast shell.

So did Debian and Ubuntu, so they demoted bash.

Whatever smugness you are interpreting here is diametrically opposed to the facts of this situation, and repeat after me:

It’s too big and too slow.

> diametrically opposed to the facts of this situation

What do you think 'this situation' is?

Repeat after me: The situation is that fork is using almost all the runtime.

The only solutions are fixing fork or forking less. Your suggestions are not related to the actual problem the user is having.

  $ rpm -q bash
  bash-5.1.8-9.el9.x86_64

  $ man bash | sed -n '/BUGS/,/^$/p'
  BUGS
       It's too big and too slow.

You could also use the inbuilt substitution mechanism:

    $ parameter='fisholdbits'
    $ echo ${parameter/old/new}
    fishnewbits

Reply on news.ycombinator.com