CODEWITHSUNDEEP
gitgocygwin
The Code Buccaneer
The Code Buccaneer

Reputation: 777

Cygwin uses relative and absolute path for environment variables

When I use the below command in Cygwin:

$ go get github.com/gorilla/mux

I receive the below error:

# cd .; git clone https://github.com/gorilla/mux C:\cygwin64\home\USER\Go\src\github.com\gorilla\mux
Cloning into 'C:\cygwin64\home\USER\Go\src\github.com\gorilla\mux'...
fatal: Invalid path '/home/USER/C:\cygwin64\home\USER\Go\src\github.com\gorilla\mux': No such file or directory
package github.com/gorilla/mux: exit status 128

When I use the command:

cd $GOPATH

The correct folder opens.

Does anyone how I can solve this?

Upvotes: 9

Views: 1157

Answers (3)

VonC
VonC

Reputation: 1323115

Try the same command with Git 2.21 (Q1 2019) installed.

See commit 1cadad6 (15 Dec 2018) by Torsten Bögershausen (tboegi).
Helped-by: Johannes Schindelin (dscho).
(Merged by Junio C Hamano -- gitster -- in commit 25d90d1, 14 Jan 2019)

git clone <url> C:\cygwin\home\USER\repo is working (again)

A regression for cygwin users was introduced with commit 05b458c, Git v2.12.0-rc0, Dec. 2012, "real_path: resolve symlinks by hand".

(See "How to git grep the main repository and all its submodules?" for more on that original commit)

In the the commit message we read:

The current implementation of real_path uses chdir() in order to resolve symlinks. Unfortunately this isn't thread-safe as chdir() affects a process as a whole...

The old (and non-thread-save) OS calls chdir()/pwd() had been replaced by a string operation.
The cygwin layer "knows" that "C:\cygwin" is an absolute path, but the new string operation does not.

"git clone <url> C:\cygwin\home\USER\repo" fails like this:
fatal: Invalid path '/home/USER/repo/C:\cygwin\home\USER\repo'

(which is an error message similar to what the OP mentions)

The solution is to implement has_dos_drive_prefix(), skip_dos_drive_prefix() is_dir_sep(), offset_1st_component() and convert_slashes() for cygwin in the same way as it is done in 'Git for Windows' in compat/mingw.[ch].

Extract the needed code into compat/win32/path-utils.[ch] and use it for cygwin as well.

Note: Git 2.22 (Q2 2019) further improves the command, as an earlier update for MinGW and Cygwin accidentally broke MSVC build, which has been fixed.

See commit 22c3634 (08 Apr 2019) by Sven Strickroth (apotek).
(Merged by Junio C Hamano -- gitster -- in commit 70542df, 08 May 2019)

MSVC: include compat/win32/path-utils.h for MSVC, too, for real_path()

A path such as 'c:/somepath/submodule/../.git/modules/submodule' wasn't resolved correctly any more, because the *nix variant of offset_1st_component is used instead of the Win32 specific version.

Regression was introduced in commit 1cadad6 when mingw_offset_1st_component was moved from mingw.c, which is included by msvc.c to a separate file.
Then, the new file "compat/win32/path-utils.h" was only included for the __CYGWIN__ and __MINGW32__ cases in git-compat-util.h, the case for _MSC_VER was missing.

And:

git clone <url> C:\cygwin\home\USER\repo is working (again)

A regression for cygwin users was introduced with commit 05b458c, "real_path: resolve symlinks by hand", Dec. 2016, Git v2.12.0-rc0.

In the the commit message we read:

The current implementation of real_path uses chdir() in order to resolve symlinks.
Unfortunately this isn't thread-safe as chdir() affects a process as a whole...

The old (and non-thread-save) OS calls chdir()/pwd() had been replaced by a string operation.
The cygwin layer "knows" that "C:\cygwin" is an absolute path, but the new string operation does not.

"git clone <url> C:\cygwin\home\USER\repo" fails like this:

fatal: Invalid path '/home/USER/repo/C:\cygwin\home\USER\repo'

The solution is to implement has_dos_drive_prefix(), skip_dos_drive_prefix() is_dir_sep(), offset_1st_component() and convert_slashes() for cygwin in the same way as it is done in 'Git for Windows' in compat/mingw.[ch]

Extract the needed code into compat/win32/path-utils.[ch] and use it for cygwin as well.

Note: The real_path() convenience function can easily be misused; with a bit of code refactoring in the callers' side, its use has been eliminated, with Git 2.27 (Q2 2020).

See commit 49d3c4b, commit 4530a85, commit 3d7747e (10 Mar 2020), and commit 0915a5b (06 Mar 2020) by Alexandr Miloslavskiy (SyntevoAlex).
(Merged by Junio C Hamano -- gitster -- in commit 4d0e899, 25 Mar 2020)

real_path: remove unsafe API

Signed-off-by: Alexandr Miloslavskiy

Returning a shared buffer invites very subtle bugs due to reentrancy or multi-threading, as demonstrated by the previous patch.

There was an unfinished effort to abolish this.

Let's finally rid of real_path(), using strbuf_realpath() instead.

This patch uses a local strbuf for most places where real_path() was previously called.

However, two places return the value of real_path() to the caller. For them, a static local strbuf was added, effectively pushing the problem one level higher:

read_gitfile_gently()
get_superproject_working_tree()

Upvotes: 1

daparic
daparic

Reputation: 4444

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:

Instead of:

go get -u -v github.com/golang/example/hello

You need to instead do it by:

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

Upvotes: 0

user2836287
user2836287

Reputation: 1

I think this comes if you have git both installed locally and in cygwin. For me it helped running the go get command in the git cmd

Upvotes: 0

Related Questions