It fails to call bash internally on windows when using cygwin

Hi guys!
Do you have plans to make kscript windows compatible?

It should run under cygwin. At least we implemented a few tweaks around it a while ago. Please submit issues as you encounter them I have not tried the Linux subsystem yet, but since it runs with bash, kotlin and a jdk, kscript should run as well. Mykola D <notifications@github.com> schrieb am Sa., 1. Sep. 2018, 13:08:

…

Hi guys! Do you have plans to make kscript windows compatible? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#154>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAMQ-IfGSo8CWRgY88XvcT8r4_MALwD8ks5uWmq2gaJpZM4WWLi8> .

probably someday this part https://github.com/holgerbrandl/kscript/blob/master/src/kscript which has been currently written in bash shellscript , can be ported to Powershell "also" . That will facilitate it to run with powershell,kotlin and jdk too on MSWindows. ie, no need of cygwin then. Just drop it on MSWindows and run in powershell command prompt.

NOTE: Powershell is also available on linux. So, if you have primarily Linux machines for development, then while developing it, you can test/develop that powershell ported wrapper "kscript" script on linux too . And once you are okay, then can test it on Windows machines atonce.

I guess deployment via sdkman wont work. But if you could provide a powershell launcher via PR, I could add at least a windows release format for download. What do you think?

We could even think about testing it on travisCI with the mentioned linux-support for powershell.

Installation with sdkman works fine but it just gets stuck and never executes. The shell stays in [kscript] Resolving dependencies....
Is there some verbose more to get info or some way to debug it?

Btw, on WSL works fine.

Could you share a specific example? Just to make sure that it runs fine under linux/macos.

Also please note that a few windows related issues were fixed recently via #175 but are not yet released.

The one I tested was just this:

#!/usr/bin/env kscript
import com.github.kittinunf.fuel.httpGet

//DEPS com.github.kittinunf.fuel:fuel:1.15.1

fun getToken(): String {
    val (request, response, result) = "https://httpbin.org/get".httpGet()
            .responseString()
    return result.get()
}
println(getToken())

But a Hello world fails as well, in this case, the "Resolving ...." is not shown, so I guess the script is partially processed.

#!/usr/bin/env kscript
println("Hello from a Kotlin script!")

Also please note that a few windows related issues were fixed recently via #175 but are not yet released.

I'll give a try with the master version and come back.
Thanks!

Same issue with a jar build from master

I've tried your example and it runs fine with macos/linux at least.

Could you check if kscript --clear-cache might solve the problem?

No luck 😿

I'll try to look into the code when I have some time.

I'll try on windows myself later this week.

@vehovsky

Indeed the dependency resolver is broken under windows/cygwin. The reason is that in https://github.com/holgerbrandl/kscript/blob/6c68da86f6b3ec1d2cac3633383288f6b1d18437/src/main/kotlin/kscript/app/AppHelpers.kt#L26
we spawn a bash process to make sure that mvn is in the path (and we use the same approach later to ensure that other binaries such as kotlinc are present as well). However, bash is not in the windows $PATH and instead it's waiting for a keypress after showing the warning:

C:\Users\holger>bash
Windows Subsystem for Linux has no installed distributions.
Distributions can be installed by visiting the Windows Store:
https://aka.ms/wslstore
Press any key to continue...

That's the point when it dies at the moment.

@vehovsky since you recently helped to improve cygwin support: Did you encounter the same problem? Do you have an idea about how to fix it? In general in cygwin, how can we from a java process call a cygwin tool (like kotlin, mvn & similar) which were installed via sdkman within cygwin. They don't seem to be exposed to the windows "Command Prompt"

And btw, the problem does not even require dependency resolution. A simple

kscript --clear-cache ## to make sure that we don't use a precompiled jar from the cache
kscript "println(42)"

is failing in the same way as described above.

Not elegant, but we can check the os (System.getProperty("os.name")) and use a different approach to run the command.

@abelsromero

Not sure @abelsromero because I guess it would just run fine within the increasingly popular linux subsystem, see https://en.wikipedia.org/wiki/Windows_Subsystem_for_Linux

So I guess we rather need to detect the cygwin context somehow and then use a different approach to run the command.

I hope so, I already mentioned using it with WSL.
But this is only available in Win10 and it has some quirks that make it less practical than cygwin for some tasks. As an example, sdkman has many issues which are not sdkman but issues with how WSL manages permissions.

Imo, if the solution for kscripts requires having some "envrionment check" it makes more sense to check the OS, it's simpler and a well known solution. I checked os.name reports Linux in WSL, which is consistent, also checking for the shell in Windows means having to deal with the peculiarities of not only 1 OS, but Mingw, MSYS2 and CYGWIN. wdyt?

I can devote some time to give it a try, and I have all mentioned shells in my machine, but can't devote much time this week.

@ligee

wdyt?
I did not know that os.name reports Linux in WSL, and you're right it would get too messy to have interpreter-specific solutions. So if we can get away with a platform-tuned approach for Windows I'm all for it.

This issue might also simply fade away with the migration to the new scripting api (@ligee) and/or the merge of #49 which both will reduce/avoid external tool invocations.

I followed #49 to #159 which I understand is more advanced right?

Slightly. They center about the idea of entirely avoiding external tool invocations (like mvn) by using jar-dependencies to resolve dependencies and to compile+run the user-script.
If so, we would not have the problem described above because it would all happen within a single jvm-process.

Obsolete

Navigation Menu

Repository navigation

It fails to call bash internally on windows when using cygwin #154

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

It fails to call bash internally on windows when using cygwin #154

Description

Activity

holgerbrandl commented on Sep 1, 2018

zaxebo1 commented on Sep 10, 2018

holgerbrandl commented on Sep 10, 2018

abelsromero commented on Oct 20, 2018

holgerbrandl commented on Oct 21, 2018

abelsromero commented on Oct 21, 2018

abelsromero commented on Oct 21, 2018

holgerbrandl commented on Oct 22, 2018

abelsromero commented on Oct 22, 2018

holgerbrandl commented on Oct 22, 2018

holgerbrandl commented on Oct 23, 2018

holgerbrandl commented on Oct 23, 2018

abelsromero commented on Oct 23, 2018

holgerbrandl commented on Oct 23, 2018

abelsromero commented on Oct 23, 2018

holgerbrandl commented on Oct 23, 2018

abelsromero commented on Oct 24, 2018

holgerbrandl commented on Oct 24, 2018

holgerbrandl commented on Jun 24, 2019

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions