This error happens if trying to run from a directory with spaces in it:

PS F:\User Files\Documents\Git\revery-quick-start> esy build
info esy build 0.5.6 (using package.json)
C:\Users\ryan\AppData\Local\Temp\__esy-bash__536100110__1__.sh: line 2: cd: too many arguments

We should be quoting the path here:
https://github.com/bryphe/esy-bash/blob/dd790b285119d13e0716880a893aa982eb8198d9/re/lib/EsyBashLib.re#L98

For esy, with the bootstrapped builds, we hit issues where the users .bash_profile (which initializes the OPAM repo), can collide with our build commands - bringing in parts of the OPAM environment that break the build.

We should have an option or a way to pass-through arguments to bash, to ignore the .bash_profile.

Specifically, HKEY_LOCAL_MACHINE\Software\Cygwin\setup\rootdir

Can this be avoided?

When we unpack the package, our postinstall is pretty slow - we're synchronously running all of our tasks (restoring hardlinks and symlinks). We should switch these over to use the async APIs and run them in parallel - would be a major speed up on install!

What's the intention/difference between the x86_64-w64-mingw32-gcc installed by esy-bash and the normal gcc package you can install with Cygwin?

I'm trying to build CMake from source and it fails because their bootstrap detects Cygwin but then tries to compile (when forced) with mingw.

I'm currently attempting to install gcc with Cygwin and then build CMake from source. Will update with results.

Right now, when executing npm install -g esy-bash, it's a slow process, and a Cygwin install window pops up - is there an option to make this even more streamlined?

Another example of installing cygwin here:
https://github.com/starlight/swan-base/blob/f8b0e8fc8515aa1b276559431a85140461c8c09d/SwanSetup.iss#L56

When we execute an esy-bash command, we create a temporary shell script in the temp folder. We should be cleaning these up after execution - at the moment they stick around.

With the native version of esy-bash, the ls command doesn't work:

E:\esy-bash\re\_build\default\bin [master ≡ +1 ~0 -0 !]> ./EsyBash.exe ls -a
C:\Users\bryph\AppData\Local\Temp\__esy-bash__79677993__1__.sh: line 2: ls: command not found

However, this works correctly with the node version:

E:\esy-bash [master ≡ +1 ~0 -0 !]> node .\bin\esy-bash.js ls -a
.        .git         __tests__     bin              jest.config.js  package.json       re
..       .gitignore   appveyor.yml  index.js         LICENSE         package-lock.json  README.md
.cygwin  .travis.yml  bash-exec.js  install-opam.sh  node_modules    postinstall.js

It looks like the difference is that the JS version is somehow including /usr/local/bin and /usr/bin` in the PATH, whereas the native version is not. I'm not sure if this is some difference in how we spin up the bash process? We'll need to make sure these are included in the PATH

This causes failures like this the with this build:

error: sha1 checksum mismatch: expected 59ebdbbaedcda123fc7ed8fb2b302b7d819e9a46 but got Copying
  fetching archive:https://registry.npmjs.org/@esy-ocaml/substs/-/substs-0.0.1.tgz#sha1:59ebdbbaedcda123fc7ed8fb2b302b7d819e9a46
esy: exiting due to errors above

(The extra output broke the result parsing!)

There's a few additional tests that I'd like to hook up with the native piece - ideally, we could get this full suite running against EsyBash.exe: https://github.com/bryphe/esy-bash/blob/master/__tests__/all-platforms/esy-bash-tests.js

They're marked as TODO currently in the test file: https://github.com/bryphe/esy-bash/blob/5132d8301a5a6f1cf6ad62983072a5755c4a80eb/re/tests/lib/EsyBashLibTests.ml#L31

Given the recent break with the latest Cygwin update, it would make sense for us to package up our dependencies / binaries, and install them locally - some ideas her:
https://stackoverflow.com/questions/661939/where-can-i-download-an-offline-installer-of-cygwin/662415#662415

Suggested by @ulrikstrid on Discord - gow is a lightweight alternative to Cygwin. I wonder if it would be possible to use this?
https://github.com/bmatzelle/gow

Sometime __esy-bash__824592099__1__ file has syntax errors like these

mount -c /cygdrive -o binary,noacl,posix=0,user;
cd "C:/Users/user/b-runner/gl/builds/0/xxxxxxxx/ligolang/ligo/_esy/default/store/b/opam__s__tezos_base-842c849a";
"C:/Users/user/AppData/Roaming/npm/node_modules/esy/node_modules/esy-bash/.cygwin/bin/rm.exe" "-rf" "vendors";s";

This is likely happening because the random number collisions in the filename, causing file overwrites. A good solution could be clearing these files after use. They end up getting accumulated in the current state of things.

The postinstall task logging is a bit verbose. We should enable it as an option (perhaps as an environment variable - we could follow with whatever convention npm uses for log verbosity?), but we don't necessarily need to log out all the details of the symlink/hardlink restoration by default - especially with #36 .

I've been trying to build https://github.com/grain-lang/binaryen.ml and it seems that esy-bash is broken on Windows 10, especially when needing to rely on mingw compilers for our C bindings. If I update the esy-bash installation in my esy install, everything works. This requires an attended install otherwise cygwin kills itself during the upgrade.

Can we get a new release of this package that includes the newest cygwin and installed packages?

cc @ManasJayanth

Here is the run that break on windows for Revery
https://github.com/Et7f3/revery/runs/205326721

This code just spins up a process w/ some environment variables - should be feasible to do this as a native reason executable (with much faster perf!)

This is costs time. Can we get native Windows paths understood in the cygwin/msys layer?

We seem some failures due to the unpacking / packing logic (for example, symlinks not being hydrated correctly).

We should run our test suite against the install package, too. We could do an additional run after we've packed and specify the esy-bash root location via an environment variable.