[barrkel]

Just use ssh from Cygwin. DLL hell was rarely a problem, just always install everything via setup.exe.

The single biggest problem it has is slow forking. I learned to write my scripts in pure bash as much as possible, or as a composition of streaming executables, and avoid executing an executable per line of input or similar.

[jasomill]

On your own system, sure.

As a dependency of a shipping Windows application that needs to cleanly coexist side-by-side with existing Cygwin installations and optionally support silent install/upgrade/uninstall through mechanisms like SCCM, Intune, and Group Policy?

Not so much.

I do use the setup program to build the self-contained Cygwin root that's ultimately bundled into my program's MSI package and installed as a subdirectory of its Program Files directory, however.

[fc417fc802]

Slow forking is only the second biggest problem IMO. The biggest is the lack of proper signals. There's a bunch of software out there that just isn't architected to work well without non-cooperative preemption.

[quotemstr]

Huh? Signals have worked fine for a long time under Cygwin.

[fc417fc802]

That's fake cooperative emulation of signals. It isn't preemptive (unless someone got a kernel driver approved while I wasn't looking?) thus many things either work poorly or not at all. Pause-the-world GC algorithms are a good example. Coroutine implementations also have to be cooperative.

If you're curious, I believe the issue was discussed at length in the Go GitHub issues years ago. Also on the mailing lists of many other languages.

[dspillett]

I've never had a problem installing from setup, but some tools were (maybe still are, it is a long time since I've needed anything not in the main repo) ported to windows using the cygwin dlls were distributed with their own versions and could clobber the versions you have otherwise (and have their versions clobbered when you fix that).

> slow forking

There isn't much that can be done about that: starting up and tearing down a process on Windows is much more resource intensive operation than most other OSs because there is a lot going on by default that on other OSs a process ops into, only if it needs to, by interacting with GUI libraries and such. This is why threads were much more popular on Windows: while they are faster than forking on other OSs too, especially of course if data needs to be shared between the tasks because IPC is a lot more expensive than just sharing in-process memory, the difference is not as stark as seen under Windows so the potential difficulties of threaded development wasn't always worth the effort.

Cygwin can't do anything about the cost of forking processes, unfortunately.

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

[barrkel]

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.

[emmelaich]

You could also use the inbuilt substitution mechanism:

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

[chasil]

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

[Dylan16807]

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

[chasil]

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?

[Dylan16807]

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.

[chasil]

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