Frederik Eaton wrote:

But it isn't running "in a unix emulation environment."  cygwin is 
simply _not_ such an environment.  The program is started by a different 
shell, but that is _not_ an emulation environment.


Is it an elephant? A tree?

I guess the most accurate way to describe it is that it tries to emulate the _development_ environment of UNIX. It has gnu make and various other utilities and shells compiled to run under win32. So you can build things that rely on shell scripts, because the shell scripts are executed by either (1) a shell, which knows the conventions about how to execute scripts or (2) the make utility, which similarly has been forced to behave such that makefiles that rely on scripting still work.

This does not, unfortunately, extend to the run time environment. That's why I said it isn't an emulation environment. A program that is executing is not different in any way from any other native win32 program that is executing. A program could be set up to check whether it was started from a UNIX like shell, by querying it's parent process, but obviously this has problems.

O/S functions, such as the ones that allow one process to execute another process, are unmodified. There is no library that intersperses itself between the process and the O/S. So there is really no way to change the O/S behavior, specifically with regard to running scripts, but more generally in any way.

Frederik