From several tests, it does seem to work, despite it not following BATCH_MODE_ONLY_SHELL, which is probably due to sh.exe not screwing up with quotes with unixy paths.

Using single quotes seems to be another workaround.

Indeed, that's what I see as well.

Can you use the MSYS file name notation instead, as in "/c/full/path/to/python.exe"?  My testing indicates that the problem disappears when this format of file names is used.

Btw, these are exactly the problems that convinced me long ago to use only MSYS Make when I need MSYS Bash to be the shell in Make.  (It is true that there's no MSYS Make 4.0 yet, but do you really need 4.0?  3.82.90 is available.)

Ah no, I'm hitting it again without BATCH_MODE_ONLY_SHELL.

Here is a small testcase:

$ cat > foo.py <<EOF
import sys
print sys.argv
EOF

$ cat > Makefile <<EOF
foo:
        c:/full/path/to/python.exe foo.py "a" b c
EOF

$ make
["foo.py", "a b", "c"]

This does not happen if using "python" instead of "c:/full/path/to/python.exe".

... which turns out to be a make bug when not using the shell, contrary to what i thought. It happens to be fixed by BATCH_MODE_ONLY_SHELL because it forces the use of a shell in most cases and unbreaks things.

I actually tested the patch with MSYS Bash.  Can you show me one or two examples of it mishandling quotes?  I use MSYS Bash quite a lot (although not from the native Make), and never saw any problems with quotes.

And, btw, if you use MSYS Bash, why not use MSYS Make as well?  Then all your problems with file names will be gone.

Also, I don't quite understand why you need to use something like "/usr/bin/touch" and not just "touch" (assuming commands are on PATH).

IOW, I wonder whether the use case you presented is really justified, and moreover justifies changes in Make.  I imagine you already have to cope with quite a few quirks given your peculiar combinations of tools; perhaps one more simple quirk will remove this problem without any need to change Make?

As for your proposed patch: I understand that it works for you.  But your use case is quite marginal and borders on situations that the native Windows build of Make is not supposed to support.  If such behavior is to affect everybody, it better be right.  Your patch makes decisions at the wrong place, where it is not yet known what the first word on the command means; it could very well not be the command to execute, but something else entirely.  That is why I suggested the alternative change in the place where Make knows positively that it is looking for an executable file.

As for your question about the number of people using commands that start with a forward slash: I don't know, but I can easily imagine that this number is not smaller than the number of people having your specific problem.  Moreover, while unlikely, using such file names in the native Windows port of Make is a legitimate use case that I cannot possibly dismiss, sorry.

What does "doesn't handle quotes right" mean?  It's a Unixy shell, right?  What kind of shell are you using?

BATCH_MODE_ONLY_SHELL cannot be catered to at this stage, it's something considered at a higher level.  But that higher level doesn't know whether the command is a file reachable by following the filesystem.

So if you cannot use the proposed patch, I guess this problem has no solution.  I can only suggest to use quotes on the command line, which will force Make to use the shell.

My patch did had 2 conceptual problems, sorry.

Please try this patch instead.


(file #29434)

Besides the fact that your patch would leak the strdup'ed string, it doesn't work:

$ ./Release/make_msvc.net2003.exe -f test.mk --trace
test.mk:2: target 'foo' does not exist
echo foo
foo
/usr/bin/touch foo
/usr/bin/sh: (/w foo: No such file or directory
test.mk:2: recipe for target 'foo' failed
make_msvc.net2003: * [foo] Error 127

(test.mk is the same as in comment #2, but with an additional "echo foo" in the recipe)

Note without the "echo foo", the error message is borked:
$ ./Release/make_msvc.net2003.exe -f test.mk --trace
test.mk:2: target 'foo' does not exist
/usr/bin/touch foo
/usr/bin/sh: Ó<.wÿ: No such file or directory
test.mk:2: recipe for target 'foo' failed
make_msvc.net2003: * [foo] Error 127

Which suggests unintialized memory use or something alike.

Something like:

foo:
        /usr/bin/touch $@

fails because /usr/bin/touch doesn't exist in the filesystem (so, to answer your question, the former).

When using a MSVC-built make 4.0 with some autoconf/automake-driven projects with a bash shell, some commands retrieved during configure are set with a full unixy path, like /usr/bin/install.

In such cases, the command fails in make because CreateProcess fails.

One way to look at it is that if the command line begins with a forward slash, it's likely to be a unixy path, and it should thus be treated by the shell instead of CreateProcess.