> -----Original Message-----
> From: cygwin-owner On Behalf Of Bob Byrnes
> Sent: 15 September 2004 01:25
> On Sep 14, 4:01pm, Dave Korn wrote:
> -- Subject: Bizarre behaviour of "make --win32"
> >
> > It appears to be using sh.exe, regardless of the --win32
> flag. But if I
> > add stdout redirection to the command in question, it uses cmd.exe.
> >
> -- End of excerpt from "Dave Korn"
>
> On non-Cygwin, UNIX platforms, GNU make will optimize away the shell
> invocation for simple commands, which are identified by lack of known
> shell metacharacters (like ">"). For example, "foo bar baz" would be
> executed directly, using something like execvp(), but "foo bar > baz"
> would run /bin/sh -c "foo bar > baz".
Bingo. That sounds like the one. This is causing me complicated
interactions with the fact that windows shell doesn't follow cygwin
softlinks, but something launched from within a cygwin process does. Which
is ultimately why my makefiles sometimes succeed in launching python.exe (a
softlink) and sometimes fail, according to whether redirection is in use or
not.
> If the Makefile sets the SHELL make variable to something other than
> the default /bin/sh, then this opimization is disabled: GNU make
> conservatively assumes that it has no idea about the syntax for the
> nonstandard shell, ignores potential metacharacters, and just always
> runs $(SHELL) -c "command". This can have performance implications,
> as you might imagine.
>
> I don't know offhand what happens with --win32,
--win32 is supposed to use cmd.exe rather than sh.exe to launch
subprocesses, in order to understand windoze-style backslash-separated paths
without having to double up all the backslashes to avoid them being taken as
metachar escapes by the *nix shell. So it's basically wrong behaviour: this
optimisation effectively launches the subprocess within a unix environment
rather than a cmd.exe environment, regardless of MAKE_MODE.
>but the difference in
> behavior with stdout redirection that you report is probably related
> to this optimization. I thought --win32 was supposed to use cmd.exe,
> but I don't know what the equivalent of execvp() would be for simple
> commands, or if make --win32 knows about cmd.exe metacharacters.
> What makes you think that sh.exe is being used?
NTFileMon from sysinternals, but on closer inspection, it turns out to be
a red herring: sh.exe is in fact not being invoked from make directly, but
by a call to os.system (....) in a python script; some activity from it just
at the point where make was launching a subcommand got in the way and fooled
me.
The only thing that has been going wrong here is that when make invokes
the command through execvp it runs in the same unix-y environment that make
is running in itself, which defies the purpose of the --win32 switch; when
the redirection of the command disables this optimisation, it correctly
launches cmd.exe to execute subcommands.
Now that I've got the inconsistent behaviour explained, I need to figure
out how to make it possible to invoke python from a makefile that might be
run from either bash.exe or cmd.exe and use either cygwin python or win32
python according to which is installed, and without any dependency on which
order in $PATH they come......
cheers,
DaveK
--
Can't think of a witty .sigline today....
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
