Windows support

[dundalek]

There is a trouble running a startup script on Windows. In order to make closh on Windows I imagine two ways could work:

1. Create a .bat file to run closh and use a package manager like Chocolatey or Scoop.
2. Keep using npm for and try out cygwin to make the bootstrap shell script work.

If anyone uses Windows please give it a shot. Any help is appreciated.

[mnewt]

For option 1, probably would need to think about Windows differences such as:

• backslashes everywhere
• PATH with ; instead of :
• lack of pty
• differences in i/o redirection

[dundalek]

There is now a CI setup running windows builds. So the first step would be to make the tests pass (some tests need to be fixed, for some the implementation needs fixing).

[sogaiu]

FWIW, following the CI setup link just gave:

Project not found or access denied.

[dundalek]

I disabled Windows CI a while ago because it was getting in a way.

Also we started with node.js version which was more difficult to run on windows. I think the Java version should be easier to make running on windows.

Are you familiar with windows to try things out?

[sogaiu]

Not sure if I know enough, but just spent some time loading up Windows-related context for a different project that is using the Windows support for Graal's native-image.

I thought I might take a look to see if there was anything manageable -- though I'm mostly interested in fast startup times. If it could be made to work, it seems like the node.js version would start a fair bit faster. Does that seem correct?

[dundalek]

Yeah, the node.js version should be slightly faster. But it is not the best we can do since I was not yet able to hook into lumo build system and make it compile as a single binary.

If startup times are your top concern, I would also suggest checking out joker.

As for windows builds in general maybe if we wait long enough the need can go away as WSL improves. So in the future one could probably just run the Linux binary on Windows.

[sogaiu]

Thanks for your comments and suggestion.

I had considered joker, but my primary interest at the moment is editor tooling for Clojure involving the use of rewrite-clj, and assumed that library wouldn't work with joker. But perhaps I should confirm :)

Regarding WSL, I heard a version 2 had become available recently. Is that something you've tried already?

[supernovae]

I'm running Windows 10 Build 1909 and WSL. Closh works fine in WSL Ubuntu 1804 with Windows Terminal . All I had to do was run apt-get install openjdk-11-jre and then download jar and run java -jar closh-zero.jar now, that may not be "works in windows" CMD folks, but since WSL can bridge windows anyway, I'd say, it's pretty awesome

[rbeesley]

Running in a PowerShell window on Windows 10, not under WSL at all, I can get closh to run by starting it with clj -m closh.zero.frontend.rebel, and it handles things like (+ 1 2) with no difficulty. It seems like find-executable could be the biggest obstacle.

If I run (sh cmd.exe) I can get closh on PowerShell to open a command prompt. As one might expect, (sh pwsh.exe) will open PowerShell >5.1 if it is installed and on the path. Interesting "bug" there in that PowerShell running under closh seems to block most characters from being written, so trying to exit is a problem. I don't know if that's the fault of PowerShell running on closh, or a problem with PowerShell. There was a similar problem with cmd.exe, but it was not as difficult to work around and I didn't see it at first. It seems as though characters are being passed back to closh and are on the command prompt when you exit the shell. The good news, is that as long as there is an executable, it seems to work. For example (sh winver.exe) will produce a windows version dialog.

But this is the problem. Under cmd.exe a lot of commands are internal commands, so there is no executable on the PATH. There is a similar problem with PowerShell, and that is that the PowerShell Cmdlets might be aliases. PowerShell is also like *nix in that you need to refer to a file by its full path or refer to the current directory to execute a script, like .\Get-Version.ps1. I could figure out no such way as it is implemented to execute a .ps1 script. It will however run a batch script. If I run (sh Get-Version.cmd) I can see two cmd.exe shells open to execute the script. I was unable to run (sh "cmd.exe" "-C echo foo") as a way of running a command. It is possible I am just not familiar with the way arguments are passed in closh.

Under WSL, like @supernovae, I really had no problem running it. WSL is the Windows Subsystem for Linux and it runs closh just as it would on any other Linux distribution.

I used OpenJDK 8 for all of my testing, both in WSL and on Windows directly.