/cc @alexbrainman @rsc

@davidsonff thank you for creating the issue. Your request sounds reasonable, but I do not know how hard it is to implement this. I have not used Cygwin myself, so I do not know much about it. I will install Cygwin on my computer when I have free time and report back here.

Alex

I've used go get successfully under Cygwin. I think I have .profile set GOPATH to the windows path explicitly instead of using the tilde which gets you the Unix path.

I am using Cygwin on my windows 10 , I can run
go get golang.org/x/tools/cmd/... successfully, as a fact, I run go get all the time, didn't see any issues so far.

OK. I'll close this. Thanks for the input!

@davidsonff did you solve your problem? I suspect your problem was having paths like /a/b/c instead of c:\a\b in GOPATH? Is that correct?

Thank you.

Alex

Yes! It's solved. It is a bit complicated to get it all working but I suppose that's to be expected!

Thanks for all the help!

@davidsonff how did you make it work in cygwin?

I'm getting a git error related to the GOPATH when using go get. See below output

$ go get -u github.com/golang/dep/cmd/dep
# cd .; git clone https://github.com/golang/dep C:\Users\myself\go\src\github.com\golang\dep
Cloning into 'C:\Users\myself\go\src\github.com\golang\dep'...
fatal: Invalid path '/cygdrive/c/Users/myself/go/src/C:\Users\myself\go\src\github.com\golang\dep': No such file or directory
package github.com/golang/dep/cmd/dep: exit status 128```

Any help appreciated. Also, sorry for bumping this closed issue 😁 

@davidsonff I suspect you want your GOPATH contain Windows paths, not Unix paths. And you want your paths delimited with ";", not with ":".

Alex

@dentych @alexbrainman - Here's my go env from within Cygwin:

$ go env
set GOARCH=amd64
set GOBIN=C:\cygwin\home\davidfr\gocode\bin
set GOEXE=.exe
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOOS=windows
set GOPATH=C:\Users\davidfr\gocode
set GORACE=
set GOROOT=C:\Users\davidfr\go
set GOTOOLDIR=C:\Users\davidfr\go\pkg\tool\windows_amd64
set GCCGO=gccgo
set CC=gcc
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 -fdebug-prefix-map=C:\cygwin64\tmp\go-build067672003=/tmp/go-build -gno-record-gcc-switches
set CXX=g++
set CGO_ENABLED=1
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config

I also recall that there was a problem as to which git I was using: the windows copy or the Cygwin copy. That had to be sorted, too.

Frank

@davidsonff Dude, you're a frikkin genious!! My problem disappeared when I used the Git for Windows executable in Cygwin, instead of the Cygwin installed version.

Thank you very much! 👍 🎉 😁

To everyone who might also have the same problem as me. I installed "Git for Windows" from https://git-scm.com and uninstalled the Git cygwin package. Then made sure that C:\Program Files\Git\mingw64\bin was added to my PATH variable 😀

EDIT: I had to use C:\Program Files\Git\mingw64\bin as PATH instead of C:\Program Files\Git\cmd. Vim was not working correctly when using the latter, but everything works using the former.

This used to work, but it broke in mid-2017 (or earlier?) with a Cygwin update, resulting in the fatal: Invalid path '/cygdrive/c/path/to/gopath/src/C:\path\to\gopath\src\github.com\foo\bar': No such file or directory error.

Prior to this, it worked as long as you set GOPATH to a Windows path instead of a Cygwin one (i.e. export GOPATH=$(cygpath -w "$(pwd)").

I'm pretty sure this is a Cygwin problem.

Alternative workarounds include

• using Git Bash instead of Cygwin, or
• running go get under Docker for Windows.

Expanding on @mappu 's comments. Under Cygwin go get -v -insecure github.com/soniah/gosnmp was failing with messages like fatal: Invalid path '/home/shamilt7/C:\cygwin\home\shamilt7\go\sr.... (-insecure flag because of proxy issues).

My solution:

Install gitbash.

# open a cmd.exe prompt as Administrator
cd c:\cygwin\bin
mv git.exe git.exe.old

#  then under Cygwin:
% which git
/cygdrive/c/Users/shamilt7/AppData/Local/Programs/Git/cmd/git

% go get -v -insecure github.com/soniah/gosnmp
github.com/soniah/gosnmp (download)
created GOPATH=C:\cygwin\home\shamilt7\go; see 'go help gopath'
github.com/soniah/gosnmp

Do another Windows Facepalm.

Although by using Windows' git-bash.exe is a work around, yet some might find it fundamental to stay in their cygwin environment. To make it work in cygwin, do this:

git clone https://github.com/golang/example $(cygpath -u $GOPATH)/src/github.com/golang/example

I've written a small command line tool in Go, which translates the command line args of git by the code seen below, and then invokes it.

if strings.HasPrefix(strings.ToLower(arg), "c:") {
  args[i] = strings.Replace("/cygdrive/c"+arg[2:], "\\", "/", -1)
} else {
  args[i] = arg
}

Place that in $HOME/bin and put that on your $PATH first.

https://gist.github.com/thekid/83b8ac613dba829d0c6cacdc33e50cdb

Just a little report, not really any new information. Yet it might be useful for someone:

I come here from trying to use VirtualBox as an executer from GitLab CI. This executor connects to VBox only via SSH and expects a posix compatible shell behind it.

This rules out any Microsoft's OpenSSH and other SSHD implementations using PowerSHell or CMD. The MS Vagrant boxes come with a windows sshd that spawns a simple sh and are not usable for this.

So cygwin with the posix shell and sshd is the way to go. I stumbled over the same go get issue. But as it was said before: This is specifically the cygwin git client that has the issue. Uninstalling the cygwin git client, installing the GIT for Windows client (and making sure it is in the path) suddenly fixed the issue and everything worked!

This is caused by git/git@1cadad6

I'd like to confirm that this issue is still very much present, and this issue should be re-opened, until properly fixed. The reasoning behind this is:

• The latest x64 Cygwin adheres very much to all POSIX standards and thus resemble any (Fedora) related *nix distribution. Therefore the building of compatible GO distro should be more similar to those, than to Windows... (although through WLS, windows is also move closer to POSIX nixes) This also means that Windows PATH support in Cygwin, is better than ever.

• There is absolutely nothing wrong with git installed on Cygwin, so whatever quirks you see are due to how Windows apps like to butcher paths. Unfortunately this include how go get -u is behaving (as shown in the hashed (#) error output above.

• GOPATH should not need to contain a leading ; in order to work.

My first attempt to install was using the latest MSI installer into C:\Go. That failed as I have reported here. Next, I suppose I will try to build from sources, but unfortunately the documentation for building on other systems seem very hard to find and read if any.

As @AudriusButkevicius pointed out, this is some kind of old regression (that was just recently fixed?) in git which has somehow propagated down into the go get code. I have since managed a work around, using the very same installation as above.

• Use GO MSI installer into default directories.
• To use the default Cygwin git with the go get you need to temporarily change the GOPATH with:
  export GOPATH="C:\Users\XXX\go" to export GOPATH=";C:\Users\XXX\go"
  Did you catch the difference?
• Unfortunately Cygwins git is rather outdated (2.17.0) from 2014 🤦‍♂️ and thus still have the (now re-fixed) bug, which seem to only occur when called from a non posix compliant console/app.

Something that I think might help a lot here, might be an environment variable, say, GOGIT to specify the path to the git to use. That way I could use a Windows-native git for use with go get instead of the Cygwin git that does not handle mixed paths well. Alternatively, it could point to a wrapper script such as @thekid's. Of course the same could be achieved by putting my own git in a directory and putting that directory early on my $PATH. This is problematic for using git-bash for Windows since it will also put other non-Cygwin binaries on the $PATH before the Cygwin /bin which is highly undesirable. That's why I think an explicit GOGIT I could set would be more useful.

Another minor nuisance in this area, though I'm not exactly sure why it's happening, is that if you do manage to get go get to use Cygwin's git (e.g. using @E3V3A's workaround) it works, but the repositories are cloned with permissions set to 0777 without applying my umask. This is normal when running native Windows programs, but it's surprising given that go get is calling the Cygwin git which should create files with the correct permissions. I'm not sure why that is.

@embray you should be asking all these questions to Cygwin developers. I doubt any Cygwin developers listening on this issue.

go program is a normal Windows program, and it uses standard CreateProcess Windows API to run git.exe when it needs to run Git command. You should ask Cygwin developers, if what go command does is inappropriate, and what they suggest go command should do instead.

Alex

@embray

GOGIT

Having a GOGIT may be good idea even for other OS's, especially since it seem that GO want to handle GIT presence somewhat differently. However, I doubt GO devs are up to implementing this, as the proper fix should be elsewhere.

but the repositories are cloned with permissions set to 0777

(Un?)fortunately Windows ignores Cygwins umask, for most practical purposes, and AFAIK. So that should not matter, at least not until you have your git somehow detecting any such changes, and want to add those changes, as in git status.

@alexbrainman

I doubt any Cygwin developers listening on this issue.

LoL! Cygwin developers never listen anywhere! (They still insist using an 1980's era email list, that is practically impossible to post and reply to as their (own) anti-spam filters that barely allow anyone through.) 💩

That said, because Cygwin is trying to grab and fix any windows PATHs it thinks it finds, and the GO path mechanism to the git.exe is trying to play smart-ass, everything backfires. In this respect having a GOGIT would seem a great idea, while being an easy fix that doesn't depend on any Cygwin devs, or git's maintainers involvement,

BTW. I filed an issue to the Cygwin-git maintainer here:
cygporter/git#40
But from his response, it doesn't seem to be something that is going to get updated...ever. Due to Cygwins package vs anti-virus issues.

Cygwin developers never listen anywhere

I am sorry to hear that. Not sure what to suggest here.

In this respect having a GOGIT would seem a great idea,

I do not know what the problem is, but you can try create a proposal for that. See https://github.com/golang/proposal for details.

Alex

I was under the impression is the fix is already in cygwins git, yet it has not been releases yet?

Edit: nvm git for cygwin is not maintained by the cygwin people but some local hero.

FWIW I am a "Cygwin developer" to the extent that I have had a few patches merged, and use it every day often non-trivially. They will too happily fix things if the problem is with Cygwin. However, in this case, I don't believe the problem is really with Cygwin, but rather with mixing Cygwin tools (which in most cases happily convert transparently between Windows paths and POSIX-style paths), with non-Cygwin native Windows tools that have no clue about POSIX paths, or how to properly join paths.

I do not know what the problem is, but you can try create a proposal for that. See https://github.com/golang/proposal for details

The problem is that go's tools just use whatever git it finds first on the $PATH. It would be possible to work with those tools in a Cygwin shell so long as it's possible to point them to using a different path for the git executable.

It would also be a non-issue if go's core tools could work natively on Cygwin (not produce Cygwin-compatible binaries--it would still be better generally to produce native Windows binaries). But that's another can of worms. I haven't even tried doing it, though I suppose one would have to start with the bootstrap toolchain first...

Thank you @embray for trying to explain the problem to me. But I still do not understand.

The problem is that go's tools just use whatever git it finds first on the $PATH.

go.exe behaves here just like any other Windows program. How else would you run Windows program?

It would be possible to work with those tools in a Cygwin shell so long as it's possible to point them to using a different path for the git executable.

I do not understand what you are proposing here. You can set your Cygwin $PATH to whatever you like. No?

It would also be a non-issue if go's core tools could work natively on Cygwin

I do not use Cygwin myself - I do not know how to implement what you are suggesting. But yourself and others are free to submit appropriate changes to Go.

(not produce Cygwin-compatible binaries--it would still be better generally to produce native Windows binaries)

Again. I do not understand what you say here.

Alex

You can set your Cygwin $PATH to whatever you like. No?

The problem is that windows vanilla git does not play ball with cygwins tty, hence need for a special git, which doesn't seem to play ball with go due to how its using it and the regression in git when used inside cygwin.

Actual solution to this issue is to get a new version of git releases on cygwin.

The problem is that windows vanilla git does not play ball with cygwins tty

We cannot help that.

hence need for a special git, which doesn't seem to play ball with go due to how its using it and the regression in git when used inside cygwin.

I don't understand that. But do not worry explaining.

Actual solution to this issue is to get a new version of git releases on cygwin.

I am happy to leave it alone. Considering I don't use Cygwin myself.

Alex

@AudriusButkevicius
Is quite on the spot of being right, except the Cygwin TTY which has nothing to do with the problem.
It's not a terminal problem, its a PATH checking problem.

@alexbrainman
The problem here is that there are now 3 parts trying to outsmart the user in how to pass paths to whatever git is available.

1. Windows installed GIT
2. Cygwin installed git package that remain outdated and cannot be simply maintained due to shitty Cygwin mailing list development policies.
3. GO trying to understand WHATEVER-IT-FINDS paths and block those that seem not proper.
   (Yes, the code in GO is blocking certain types of paths and telling user they are not correct, while the Cygwin environment would probably fix them.)

@embray
If you are a Cygwin Dev, would you mind telling Cygwin list about this problem?
(And ask them to update and fix the git package!? AFAICR, It currently even include a bunch of old security vulnerabilities.)

A proper fix rests on behalf of both projects:

1. Cygwin git package need to get updated.
2. GO need to stop trying to be smart about (Windows) PATHs

I.e. If the user pass a GOPATH as "/home/user/go", then that's what it is, not ";C:\Uuser\user/home/go" or whatever cockup it thinks it should be, and then tries to pass that on to git.

3. GO trying to understand WHATEVER-IT-FINDS paths and block those that seem not proper.
(Yes, the code in GO is blocking certain types of paths and telling user they are not correct, while the Cygwin environment would probably fix them.)

I am not aware of such code in go.exe. Can you, please, point me to the go.exe code that does that?

Thank you.

Alex

@alexbrainman

I am not aware of such code in go.exe. Can you, please, point me to the go.exe code that does that?

Are you joking!? You have an entire directory dedicated to handling paths with literally thousands of lines of code. For example, all the smartness built into this.

I don't think making blanket statements like that is of any use, if you know what exact piece of code cripples cygwin, please point that out, if you don't - shut it - as you add nothing to the conversation other than insults to people who contribute their spare time working on something you don't even have to pay for.

@AudriusButkevicius

I don't think making blanket statements like that is of any use, if you know what exact piece of code cripples cygwin, please point that out, if you don't - shut it - as you add nothing to the conversation other than insults to people who contribute their spare time working on something you don't even have to pay for.

Woah! Hold on there Pistolino, what exactly are you adding to the conversation with this insult and attitude?

I happen to know what I am talking about since I resolved the issue long time ago after having inspected the GO code. I do not recall the exact place of the problem so if you wanna play issue police I suppose you should also complain about developers saying that there is no code trying to deal with handling PATHs. Nu Taip?

Please stay polite and follow the Gopher code of conduct (https://golang.org/conduct). Thanks.

Are you joking!?

I am trying to be funny most of the time. But not this time. This time I was trying to help you.

You have an entire directory dedicated to handling paths with literally thousands of lines of code. For example, all the smartness built into this.

I don't see how this source file could be responsible for what you called

3. GO trying to understand WHATEVER-IT-FINDS paths and block those that seem not proper.
   (Yes, the code in GO is blocking certain types of paths and telling user they are not correct, while the Cygwin environment would probably fix them.)

So, unfortunately, I cannot help you.

Alex

To all - The root cause of this issue is that Cygwin Git has had broken path
handling for some years now:

git/git@05b458c

which i personally reported on the Git mailing list

https://marc.info?m=154255455209070

and was fixed here

git/git@1cadad6

so anyone having a problem can upgrade to Git 2.21.0 and issue is fixed.

and to @AudriusButkevicius - mate you clearly dont know what you are talking
about. "windows vanilla git" is not a thing. while there have been some efforts
(by me) to create a windows native git, to date not one has accomplished that
yet (that i know of). and even if they did, its a dubious proposal because most
windows users run Git with Cygwin or MSYS2 anyway, so it would be a waste. so
the "windows vanilla git" currently is Cygwin Git or MSYS2 Git.

and as others have said it has nothing to do with Cygwin TTY or any TTY for that
matter, but with older Cygwin Git path handling. please stop posting as you are
only spreading ignorance.

and to @embray yes, yes it is a cygwin issue. as i and others have linked, it
was an issue with Cygwin Git thats now been fixed. Again, please stop posting
if you only spread misinformation.

Sorry I dropped out of this discussion for a bit.
@AudriusButkevicius

The problem is that go's tools just use whatever git it finds first on the $PATH.

go.exe behaves here just like any other Windows program. How else would you run Windows program?

This was sort of taking the quote out of context. This is just the start of the problem. My point was simply that the problem could be worked around if it were possible to configure Go by giving it a specific path to the desired git executable. I don't think this is all that unreasonable given that relying on system $PATH resolution won't work consistently in all contexts (e.g. I would want to set an environment variable for "GOGIT" to the same path regardless whether I'm using Go in a Cygwin shell, or from a native Windows command prompt).

The discussion on this issue is long and confused enough as-is that probably a new issue should be opened for that feature request, if it would be welcome.

It would also be a non-issue if go's core tools could work natively on Cygwin

I do not use Cygwin myself - I do not know how to implement what you are suggesting. But yourself and others are free to submit appropriate changes to Go.

Yes, I've started experimenting with it at least, as I suggested by getting the bootstrap toolchain to build on Cygwin. It's a little bit challenging as there are many bits to fiddle with, but it's certainly doable and I made significant progress in just an hour or so of playing with it.

(not produce Cygwin-compatible binaries--it would still be better generally to produce native Windows binaries)

Again. I do not understand what you say here.

Here I was just stating that it would be useful to be able to use the Go toolchain in a Cygwin shell, but to produce binaries for a plain Windows target.

@cup

and to @embray yes, yes it is a cygwin issue. as i and others have linked, it
was an issue with Cygwin Git thats now been fixed. Again, please stop posting
if you only spread misinformation.

Speaking of "misinformation" it's clearly not a "Cygwin issue" as there was no bug in Cygwin itself. Cygwin is the POSIX-compatibility layer built on top of Windows an,d takes the form of a DLL, plus a larger ecosystem of packages that are linked to that DLL. The issue here was a bug in Git itself, and its behavior with handing mixing of POSIX paths and Windows paths--a challenging issue that mostly only occurs when mixing Cygwin and non-Cygwin tools, as I explained, and I'm glad it's been fixed.

But that's not an issue with Cygwin itself. My main suggestion was just that it would be useful to be able to point to a different git executable for Go to use and that point still stands. I won't tell you to "stop posting" though because I don't think that's my place, but it's a pretty crappy thing to tell someone when you're at the time same spreading misinformation.

My point was simply that the problem could be worked around if it were possible to configure Go by giving it a specific path to the desired git executable.

I still don't see what "the problem" is. Why do you prefer to have GOGIT environment variable to listing git.exe directory in the PATH?

The discussion on this issue is long and confused enough as-is that probably a new issue should be opened for that feature request, if it would be welcome.

If you ask my opinion, I would not support adding GOGIT environment variable without understanding what is the problem that GOGIT solves.

Alex

The "problem" it solves, ultimately, is just if you want Go's tools to use a different path to the git executable than the first one on the path. This is not so unusual in other contexts, as it's often desirable, for one reason or other, to override the default path to a program (see e.g. the common CC environment variable, or even LESS.) It could even be used to pass additional flags to the normal git command if desired.