I have got Cygwin installed in my machine and set its bin folder in my PATH.
I can use all the Cygwin commands in the Windows command prompt.
However, one problem I encountered is that both Cygwin an Windows have a command "find". Whenever I use find, the Windows version is picked up.
Is there anyway I can force using the Cygwin version of find rather than the Windows version?
Make sure the the cygwin executables folder /usr/bin is ahead of the cmd executables folder c:\Windows\system32 in the PATH variable for both the cmd and bash shells to be sure you run cygwin's find instead of windows's find command.
Use which -a find in the cygwin shell to list executable files found via the bash shell's PATH variable.
Use where $PATH:find in cmd shell to list executable files found via the cmd shell's PATH variable.
This is because find is a shell built-in in cmd, so it doesn't even try to go through the executable search path.
In general Cygwin symlinks will not be understood by Windows, but as explained https://cygwin.com/cygwin-ug-net/using.html#pathnames-symlinks it is possible in modern Windows versions to create native Windows symlinks on NTFS file systems, as long as the link doesn't cross file systems.
I would consider instead just wrapping it in, say, a batch script placed in your Cygwin /usr/local/bin with a name like cygfind.bat (or whatever you want to call it) that explicitly calls Cygwin's find by C:\path\to\find.exe.
The wrapper approach has the advantage that if you upgrade Cygwin and find is updated, the batch script wrapping it will still work transparently.
I've never tried it myself but according to this answer you can also use the special #doskey variable to override cmd builtins.
Related
I am following this tutorial where i have to run this command in order to start the zookeeper server.
./bin/zookeeper-server-start.sh config/zookeeper.properties
But the problem is this command is not working properly. I found that .sh file is bash file that required cygwin. I have installed it and then run command like this
C:\cygwin64\bin\bash.exe ./bin/zookeeper-server-start.sh config/zookeeper.properties
But it is showing:
I can confirm that in bin directory the file is exsits. what i am doing wrong?
Here is my directory snapshot from where i running the command:
Note: I have successfully tested bin/windows zookeeper bat file but i want to run it through .sh file as the kafka security tutorial which i am following using this.
From your screenshot, I conclude that you are using Cygwin. So, please add the cygwin tag to your question.
As you can see from the error message, the command dirname is not found by bash, so assuming that your Cygwin installation is not broken, I assume that the PATH is not set correctly; in your setup, dirname.exe should be in C:/cygwin64/bin (please verify this).
Your usage of bash.exe is a bit unusual in that you run it directly from a Windows cmd prompt. The more common way would be to use it from the 'Cygwin Terminal', which you get created a Windows-link to, when installing Cygwin, or to use another suitable Terminal program; I'm using for instance mintty for this task (also available via the Cygwin installer).
Having said this, it is possible to run bash.exe in the way you are doing it, but you then have to ensure, that at least the PATH is set up correctly. One possibility to do this, is to add C:\cygwin64\bin to your Windows PATH, but this has the drawback, that some commands have the same name in the Windows world and in Cygwin, though they serve a completely different purpose, and this will bite you sooner or later. Another problem is that at some point, you will rely on other bash specific setups besides the PATH.
A better way to accomplish your goal is IMO to ensure, that the system wide bash-initialization files are sourced by bash. If I have to run the script from a Windows cmd prompt, I would run it by
C:\cygwin64\bin\bash.exe --login YOURSCRIPT
This will read the file (in your setup) C:\cygwin64\etc\profile before running YOURSCRIPT, so you can check, that the PATH is correctly set there, by looking at this file. In a default installation, this should be the case.
After having read this file, it will try to read the file .bash_profile in your Cygwin HOME directory, so if you need additional settings for your (non-interactive) bash-scripts, create this file and put your settings there.
I'm using a windows 8 and have cygwin installed. However, when I navigate to the folder it's contained in, the only subfolders are usr and var, and neither contains something that looks like a terminal. How can I open a cygwin terminal?
You should use mintty executable for this. In case of a default install path it is located here: c:\cygwin\bin\mintty.exe
Cygwin installation puts a shortcut to the start menu, but perhaps this feature was broken in win8.
I checked this shortcut on my computer, and it contains this command as a "Target":
C:\cygwin\bin\mintty.exe -i /Cygwin-Terminal.ico -
You should create a shortcut like this. Replace the given path, if your cygwin is located anywhere else. -i command line argument is not necessary. For further info check the manual page of mintty, which is located here.
You can run
c:\program files\cygwin\bin\bash.exe
inside the Windows CMD.
When you install cygwin, it normally installs a ".bat" file at the top of the directory-tree containing cygwin, which can run a command-window. For example:
#echo off
C:
chdir C:\cygwin64\bin
bash --login -i
The exact location of the cygwin tree is relevant to the script, of course, and details change occasionally. But the bash executable, starting in cygwin's bin-directory is enough to start a window.
Outside cygwin, you will not see things such as mounted directories and symbolic links. So (from the Windows file explorer) it may look incomplete.
I'm trying to override the windows find command, so that I can call another implementation of find. The other implementation is provided by MSYS and located in C:\MinGW\msys\1.0\bin. On Windows 7, I can open up a CMD, and run:
SET PATH=C:\MinGW\msys\1.0\bin;%PATH%
Since that prefixes the MSYS path before the C:\Windows\System32\ path, when find is called within CMD on Windows 7, the MSYS version executes.
That command doesn't work with Windows 8.1. When I call find in CMD on Windows 8.1, it defaults to the Windows implementation no matter what I do. Is there a way to override it on Windows 8.1?
I'm looking for a solution that only changes the path information of the current CMD instance. For my purposes, I'd rather not have to use powershell (even though the path setting works as expected in powershell).
Thanks!
When you run cmd.exe, make sure that you are not running the command from the C:\Windows\System32 directory (that's where it opens automatically for me). When you are in a directory with a matching command (in this case MS' find.exe) that local copy will take precedence over your PATH variable, even if your MSYS find.exe is listed first in the path.
So, to get it to work for me I run cmd.exe, then
C:\WINDOWS\system32>SET PATH=C:\msys64\usr\bin;C:\Program Files (x86)\CodeBlocks\MinGW\bin;%PATH%
If I run where find I get
C:\WINDOWS\system32>where find
C:\Windows\System32\find.exe
C:\msys64\usr\bin\find.exe
C:\Program Files (x86)\Git\bin\find.exe
If I change directories and run where find I get:
C:\WINDOWS\system32>cd C:\
C:\>where find
C:\msys64\usr\bin\find.exe
C:\Windows\System32\find.exe
C:\Program Files (x86)\Git\bin\find.exe
My path is slightly different because I'm trying this with MSYS2, but the same should apply to the older version of MSYS.
Good luck #mikewesthad!
I get the error from mr. developer: "Couldn't find 'git' executable on your PATH."
I'm running msysgit on Windows 7 and I believe I have the latest Mr. Developer. Any ideas?
You could copy git.exe to git with no file extension ,then the problem could be solved. The clue is found by the link provided by Chis.
For my case, I use the portable version of msysgit since I wanted full control of the set up and installation.
In README.portable, you'll read the following
How to start using PortableGit
If you are comfortable with a Unix-like shell, just launch
'git-bash.bat'.
If not, just launch 'git-cmd.bat'.
Alternatively, you can execute these commands to modify the %path%
variable temporarily:
set gitdir=c:\portablegit
set path=%gitdir%\cmd;%path%
Adjust the 'gitdir' according to your setup. As long as you do not
close the command window, you can now simply type "git" or "gitk" to
really call "c:\portablegit\cmd\git.cmd" or
"c:\portablegit\cmd\gitk.cmd".
Personally, I run the shell by invoking git-cmd.bat so that I'll gain access on unix commands, like ls, mv, etc.
Make sure your System PATH includes your msysgit directory, assuming you've installed and built it correctly.
I have a rough idea that git.cmd is only a wrapper (but added to PATH by default), but I found out that git.exe works as well and I intend to use it as a workaround to this issue (comments to it rather, regarding chcp on XP64). Would that be not recommended for any reason at all? Also, is git.cmd really needed in the first place?
Note: The chcp issue I am referring to is not caused by missing PATH entries as in 'chcp' is not recognized as an internal or external command, operable program or batch file. on a Windows PC
git.cmd no longer exists in current versions of msysgit (e.g. 1.8.0). git.cmd was a wrapper that has been replaced by a new wrapped called git.exe. This is not to be confused with the actual git.exe.
If you take a look at the Git directory in %ProgramFiles(x86)% or %ProgramFiles%, you will see the following structure:
Git
|-- bin
| |-- git.exe
|-- cmd
|-- git.exe
The wrapper has existed in msysgit for a long time in order to properly set up the environment for using git from cmd.exe. If you are using the included bash shell, it will run git.exe directly.
You can compare the old cmd version with the new executable wrapper here:
git.cmd
git.exe wrapper
You don't really need to worry about any of this magic, just understand that you should call the wrapper from anything but the msysgit bash environment. When you add git to the path in the installer, it's the Git\cmd directory that is added. I don't recommend ever adding all the included utilities to your system path, as this can cause a lot of problems, especially if you have other msys or cygwin installations. I've never actually tried it in recent memory, but I would imagine it puts both the cmd and bin directories in your path, with cmd taking precedence.
For me, there is one huge advantage to the new git.exe wrapper: it makes code that calls git more portable. Previously, if I wrote a python script that called git, I would have to either execute the command with a shell environment (subprocess.Popen() with shell=True) or run the cmd file explicitly. Now, I can just execute a process with 'git' as the name, regardless of the OS. This is because CreateProcess() on Windows will not execute a batch file (.cmd is an alias for .bat), you need to invoke cmd.exe to execute it.
There are three options when you install msysgit.
The first is that nothing is put on PATH and you have to use Git Bash.
The second is that git.cmd and gitk.cmd are added to PATH so that you can use it in cmd, Powershell, cygwin etc. without affecting other tools that you have on Windows. ( This git.cmd is a wrapper enabled you to do this, to answer the question).
The third ( my favourite) is to add all the tools, and git.exe, in PATH and use this. This will affect Windows tools and you will be able to use the full set of tools that MSYS comes with.
I have always used the third option. I have never seen how it affects me ( I use Powershell and powershell cmdlets and never standard Windows commands) If you are like that and you want Mingw exes at your disposal, go for the third option and you will be good.
According to the git for windows installer you have the option of adding git.exe to your path during the setup. You should be fine using that option.