[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.

> 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]