> Date: Sun, 31 Jul 2005 11:51:20 +0100 > From: "J. Grant" <[EMAIL PROTECTED]> > CC: [email protected] > > >> I could not replicate the "Signal 127" message, I could replicate "Error > >> 127", maybe the different win32 build options effect this in a way that > >> it is incorrectly named as a "Signal" 127 error. > > > > All I can say is that I cannot reproduce even the "Error 127" message > > with the MinGW build of GNU Make 3.81 beta3. I get "Error 2", which > > is entirely reasonable (it's the Windows code for "file not found"). > > Did you run with -j8?
Both with and without it, with identical results. > > Note that only the second test causes the "error 127" thing. So I > > submit that this error code comes from the ported shell that you use > > (what port of which shell is that, btw?). In other words, it's not a > > Make issue, it's an issue with your port of sh: it returns 127 when it > > fails to run this command. The shell I use (a port of zsh) returns 1 > > in that case, which is what I'd expect. > > It is the MSYS /bin/sh.exe, GNU bash v2.04. I just tested this on a Debian GNU/Linux box, and indeed Bash exits with status of 127 when it cannot find a command via PATH search (this is also documented in the Bash manual). On the same machine, zsh exits with a status code of 1. So the shells behave differently in this case on GNU/Linux as well. In other words, this is a feature ;-) In any case, as long as we don't see "Signal 127", we cannot claim there's a bug in the ported Make. To test how the Windows port handles signals, craft a Makefile whose execution takes some time, then interrupt it with Ctrl-C or Ctrl-BREAK, and see what happens. The expected behavior is for Make to announce that it was interrupted by the Interrupt and remove any target files that it didn't finish to make. > http://lists.gnu.org/archive/html/help-make/2003-09/msg00006.html > I found an old email from Paul indicating return codes: > > > 0 > > Successful completion. > > 1 > > The target was not up-to-date. > > >1 > > An error occurred. I think this is not relevant in our case: this convention is for Make, not for the shell. > Is there a standard convention for zsh failing to exec then? (1) ? It didn't fail to exec, it simply didn't find the file it was supposed to run: c:/quote_path.exe does not exist on my machine. (Does it exist on yours? How about the other file, c:/working_test_without_quotes.exe?) My Posix references seem to say that the shell must return 127 in this case, so Bash behaves correctly while zsh does not. But that's not a Make issue. _______________________________________________ Make-w32 mailing list [email protected] http://lists.gnu.org/mailman/listinfo/make-w32
