[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: WINDOWS32 "Signal 127" due to a path in quotes bug
From: |
Eli Zaretskii |
Subject: |
Re: WINDOWS32 "Signal 127" due to a path in quotes bug |
Date: |
Sun, 31 Jul 2005 22:36:04 +0300 |
> Date: Sun, 31 Jul 2005 11:51:20 +0100
> From: "J. Grant" <address@hidden>
> CC: address@hidden
>
> >> 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.