Search code examples
linuxbashbatch-filecmdcygwin

Run "./" bash/batch file with cygwin


Well the idea goes as followed,

I have a bash file for linux, there I obviously run it by making ./my_run. The problem is I'm in windows so I downloaded and installed cygwin. I added cygwin bin to the Enviromental Variables and check that at least "ls" works so I guessed I did it well. When I try to run it with the cmd it displays:

'.' is not recognized as an internal or external command,
operable program or batch file.

As if the cygwin variables were not correctly installed (as I said I tried ls and works). Then I tried it directly with cygwin and when doing the ./my_run I got it to work right.

So how is that I can use some commands like ls but when doing ./ it doesn't work on the cmd? How can I fix this?


Solution

  • Well, cygwin is only a shared library and a lot of stuff (the programs) using it (read Cygwin doc). cygwin.dll changes internally path resolution / chars to allow you to say ./my_script and converts it to .\my_script before doing the actual windows call, it also adds the proper extension to executables to allow it to execute windows binaries. This magic persists as long as you use it. cmd.exe is a Microsoft Windows command shell that is completely unaware of Cygwin's shared library and by that reason it doesn't use it, so it will not call it for path translation, even if you populate the environment of zetabytes of stuff. When you run in Cygwin terminal, you are running bash shell, which is a Cygwin executable, linked to cygwin.dll. It manages to use Cygwin library for all the unix system call emulations, so when you pass it e.g. to exec("./my_script", ...);, it internally converts that to try for ./my_script, then .\my_script, ./my_script.exe, ... and the same for .com and .bat extensions.

    This fact often makes some people to say that Cygwin is not a good, efficient, environment. But the purpose was not to be efficient (and it is, as it caches entries and makes things best to be efficient) but to be compatible.

    In your example ls is a Cygwin executable that mimics the /bin/ls executable from unix systems. It uses the Cygwin library, so all path resolution will be properly made (well, under some constraints, as you'll see after some testing) and everything will work fine. But you cannot pretend all your Windows applications to suddenly transform themselves and begin working as if they where in a different environment. This requires some try and error approach that you have to try yourself. And read Cygwin documentation, it is very good and covers everything I've said here.