Miller on Cygwin

[spmundi]

I wonder whether someone can help me with this. I cannot seem to get a version of mlr than runs properly under cygwin. I have downloaded the source, compiled with go, and get a .exe which runs. But it doesn't understand cygwin paths. The version of go I have runs in cygwin, but clearly is creating an executable which is cygwin ignorant. I cannot seem to find a prebuilt version online. I didn't have this issue with mlr 5.10 -- but that was compiled with gcc and not go.

[sskras]

hello,

I have downloaded the source, compiled with go, and get a .exe which runs. But it doesn't understand cygwin paths.

What's the command line, and what does it say?

The version of go I have runs in cygwin, but clearly is creating an executable which is cygwin ignorant.

I guess Golang's runtime itself isn't Cygwin-aware, and so are all executables that it builds.
There seems to be no recent Cygwin-porting efforts:

• cmd/go: make go get aware of Cygwin environment golang/go#23155
• https://github.com/edisonwsk/golang-on-cygwin
• Re: Is it possible to include golang and rust to cygwin?

Then you can use cygpath here to translate between Windows-native and *nix paths:

I cannot seem to find a prebuilt version online. I didn't have this issue with mlr 5.10 -- but that was compiled with gcc and not go.

I guess it's there, under the Assets:
https://github.com/johnkerl/miller/releases/tag/v6.7.0
... these archives to be precise:
https://github.com/johnkerl/miller/releases/download/v6.7.0/miller-6.7.0-windows-386.zip
https://github.com/johnkerl/miller/releases/download/v6.7.0/miller-6.7.0-windows-amd64.zip

But I think these builds will also be aware about Windows-native paths only.

So unless Golang gets a POSIX-on-Windows port (Cygwin, MSYS2, Midipix), I guess the only way would be to translate paths by yourself.

---

But hey, I just tried to reproduce your issue on Cygwin + MSYS2:

... and it looks like MSYS2 behaves in a bit different way, and mlr seems to work here. Do I get this right?

[spmundi]

my command line looks like:
mlr .. /cygdrive/c/path-to-some-file
which fails (file does no exist)
But
mlr 'C:\path-to-some-file'
works.

[sskras]

Thanks.

BTW, could you migrate to MSYS2 (the Cygwin-like environment + a package manager) by chance?
If not, I recommend changing your command line in the way I indicated above my first screenshot, Eg.:

mlr .. /cygdrive/c/path-to-some-file
–>
mlr .. "$(cygpath -w '/cygdrive/c/path-to-some-file')"

EDIT: Fixed a typos and things, added single quotes around the Unix-like path and external double quotes around the resulting Windows-native path (in case they contain spaces).

In case your paths contain no spaces, you can remove all " and all ' symbols from the line.

[sskras]

PS. Using Cygwin on my computer mlr fails to launch at all if I add a verb into the command.
This breakage doesn't even require a filename, Eg. mlr cat fails to start:

Probably a different bug.

[spmundi]

Hello sskras
Yes, thanks, and I was aware of cygpath. It's a bit clumsy, and if, as I do, you have bash scripts everywhere with calls to mlr then it's just a lot of work, with the downside that some future combo of go/miller will revert back to understanding cygwin paths.
I'm sure there must be a way to get "go"to do the right thing, but I know little about that language and nothing about howto configure it.

Thanks for responses

[spmundi]

I am reluctantly forced to abandon the use of miller in my projects. Go has not, and afaik cannot be, ported to work in Cygwin. I have hundreds of calls to mlr which use unix path names. It is not only hugely labor intensive to surround all these paths with cygpath() , but it is not even certain when paths are contained in variables from deep inside other code when such constructs are needed. There is no version of Go for windows that will accept unix style path separators.

I swear that if there is one single thing which has wasted months, nee years, of my time it is Msofts bloody minded refusal in year dot to adopt a forward slash convention. I am convined it was done deliberately to make unix porters suffer.