It creates a new array named _pathargs that we will use in place of pathargs() I created a function to munge the argument list for paths.
MINGW VS CYGWIN FULL
But if you have a full path it gets messy. When windows version of gvim starts up it asks the OS what directory it is in and doesn't know anything about the cygwin munging of it to /cygwin/c or whatever. Sure a relative path name like a file in the current directory works fine.
But the command line argument processing is an issue when file paths are involved. That at least makes it read my _vimrc file in my Windows home directory. If not use a full path name version that cygwin understands!): HOME=$WINHOME gvim 2>&1 & Now I can start the non-cygwin git (like from git bash) or natively installed gvim like this (assuming they are in PATH. bashrc: WINHOME=$(cygpath -m "$USERPROFILE")
I found a variable in my cygwin environment that has the proper directory name - USERPROFILE. You can use forward slash just fine to simplify things, so the command "cygpath -m" can do that. That sucks in that you can't easily doįrom gvim, but that didn't seem to work anyway and I'm not solving that today.įirst set a variable with the full path windows style HOME. We have that available in $ORIGINAL_PATH. I'm going with the assumption that the Windows program will not be able to launch cygwin programs and so needs the original windows path, not the cygwin one. But these programs are looking for the one you have in "C:/users/yourname_001" or some such. In cygwin shell that is going to be "/home/yournameisSue". Since the Windows commands we are most interested in are Unix style, they mostly revolve around the $HOME variable for finding those config files. The environment the command finds itself in when it looks for configuration files (.vimrc/_vimrc/.gitconfig etc.). The path to file name arguments passed to the external (windows) command. Three issues in this context (windows native gvim and git bash being my main concerns). We still have the general class of problem for calling a windows executable from cygwin. I could be wrong about that and just haven't studied the cygwin implementation enough to fix it. It's kind of funny to see that git bash includes the cygpath command for converting Windows and Posix file paths, because git bash afaik is based on MinGW, which is a distinct solution from Cygwin.Īlthough the answer to use the cygwin git is viable, there are issue that the "git bash" version has improved, especially integration with the windows open-ssh implementation. Other than that they are mostly very similar. And as I alluded above, even if you do compile it for Cygwin it likely won't work in git bash.
MINGW VS CYGWIN CODE
I've had very mixed success calling cygwin apps from the git bash window, too.Īlso, cygwin is a full posix environment, not just a bash interpreter, so you can often compile non-distributed code within it, so for example if you found the source of a nice Linux tool you found, you can usually compile that tool for Cygwin. I actually have both on my workstation, because there's things I can't do in git bash.
MINGW VS CYGWIN INSTALL
With git bash, you get what you get, and it's a bit more difficult to install additional tools. You can also install X and many X applications.
MINGW VS CYGWIN SOFTWARE
But ultimately they are different implementations of bash/shall in Windows.Ĭygwin has a large body of optional software you can install, including multiple different programming languages, compilers, various network tools, and so on. There is a lot of overlap between the two.
0 kommentar(er)
