bugmake - Bugs: bug #40241, CreateProcess failure with unixy...


bug #40241: CreateProcess failure with unixy paths

Submitted by:  Mike Hommey <glandium>
Submitted on:  Fri Oct 11 11:54:37 2013  
Severity: 3 - NormalItem Group: Enhancement
Status: FixedPrivacy: Public
Assigned to: NoneOpen/Closed: Closed
Component Version: 4.0Operating System: MS Windows
Fixed Release: 4.1Triage Status: Verified

Add a New Comment (Rich MarkupRich Markup):

You are not logged in

Please log in, so followups can be emailed to you.


(Jump to the original submission Jump to the original submission)

Tue Oct 22 15:57:54 2013, comment #19:

OK, thanks. I committed the changes to the repository, and I'm closing this bug.

Eli Zaretskii <eliz>
Project Member
Tue Oct 22 10:04:06 2013, comment #18:

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.

Mike Hommey <glandium>
Tue Oct 22 09:01:30 2013, comment #17:

MSYS Make 3.82.90 from the URL below does work well with -jN:


I use that build all the time.

Yes, using single quotes are also a possibility.

Eventually, I need to know whether the last patch I suggested is OK for your use case. If it is, I will commit those changes to the Make repository.

Eli Zaretskii <eliz>
Project Member
Tue Oct 22 08:44:18 2013, comment #16:

Using single quotes seems to be another workaround.

Mike Hommey <glandium>
Tue Oct 22 08:35:54 2013, comment #15:

3.8x deadlocks with -jN.

As for paths, it's a complex issue. We can't reliably use msys paths everywhere (and for many reasons, we don't want to use more msys paths)

Mike Hommey <glandium>
Tue Oct 22 08:22:17 2013, comment #14:

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

Eli Zaretskii <eliz>
Project Member
Tue Oct 22 07:41:04 2013, comment #13:

Err, I was not looking at the right thing. It is bash not handling quotes properly:

CreateProcess(C:\mozilla-build\msys\bin\sh.exe,C:/mozilla-build/msys/bin/sh.exe -c "c:/full/path/to/python.exe foo.py \"a\" b d",...)

Mike Hommey <glandium>
Tue Oct 22 07:26:26 2013, comment #12:

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

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

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

Mike Hommey <glandium>
Tue Oct 22 04:55:45 2013, comment #11:

Why not msys make? First, because i haven't found an msys make 4.0 build, and using msys make has its own quirks that are best avoided entirely.

Why "/usr/bin/touch"? Well, it's not actually /usr/bin/touch, it's mostly /usr/bin/install or others, and that's because that's what comes out of configure.

Interestingly, I'm testing your patch with BATCH_MODE_ONLY_SHELL undefined, and so far, it builds fine, but I'm only half-way through.

Mike Hommey <glandium>
Tue Oct 22 04:23:40 2013, comment #10:

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.

Eli Zaretskii <eliz>
Project Member
Tue Oct 22 03:48:45 2013, comment #9:

I'm using a msys bash shell, and i'm having problems with it unless I set BATCH_MODE_ONLY_SHELL.

AFAICT, the patch I attached makes things use BATCH_MODE_ONLY_SHELL as I'd expect, so it works for me. I don't know why you don't want to hook at that level. How many people do you think will be using commands starting with a forward slash that actually point to existing paths on the current drive?

Mike Hommey <glandium>
Tue Oct 22 02:58:47 2013, comment #8:

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.

Eli Zaretskii <eliz>
Project Member
Mon Oct 21 21:43:36 2013, comment #7:

Without testing this patch I know I'll probably have trouble with it, as $SHELL doesn't handle quotes right and I'm setting BATCH_MODE_ONLY_SHELL, which your patch ignores for those.

Mike Hommey <glandium>
Mon Oct 21 16:44:22 2013, comment #6:

My patch did had 2 conceptual problems, sorry.

Please try this patch instead.

(file #29434)

Eli Zaretskii <eliz>
Project Member
Mon Oct 21 02:48:32 2013, comment #5:

It worked for me, but of course I don't have your exact setup. I will have another look.

(Don't worry about leaking memory, I just wanted to see if this kind of change fixes your problem. The actual change will have all this straightened up.)

Thanks for the feedback.

Eli Zaretskii <eliz>
Project Member
Mon Oct 21 00:23:55 2013, comment #4:

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

Mike Hommey <glandium>
Fri Oct 18 14:48:37 2013, comment #3:

Thanks for the test case.

I'm reluctant to "go slow" in this case, because that would change the semantics of the command, as it doesn't have any shell-specific features.

Instead, could you please try the attached patch?

(file #29405)

Eli Zaretskii <eliz>
Project Member
Tue Oct 15 21:56:07 2013, comment #2:

Something like:

/usr/bin/touch $@

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

Mike Hommey <glandium>
Tue Oct 15 19:41:38 2013, comment #1:

Can you show a Makefile recipe that fails in this way?

Does it fail because /usr/bin/install is actually mapped to some directory like C:\MSYS\bin, and /usr/bin does not really exist in the filesystem? Or does it fail because you think CreateProcess chokes on forwards slashes?


Eli Zaretskii <eliz>
Project Member
Fri Oct 11 11:54:37 2013, original submission:

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.

Mike Hommey <glandium>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):

Attached Files
file #29434:  w32_unixy_shell.dif added by eliz (2kB - application/vnd.ms-excel)
file #29405:  w32_unix_exec_path.dif added by eliz (671B - application/vnd.ms-excel)
file #29354:  diff added by glandium (558B - application/octet-stream - Proposed patch)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -unavailable- added by eliz (Posted a comment)
  • -unavailable- added by glandium (Submitted the item)

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.


    Please enter the title of George Orwell's famous dystopian book (it's a date):



    Follow 7 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Tue Oct 22 15:57:54 2013elizStatusNone=>Fixed
      Fixed ReleaseNone=>4.1
      Triage StatusNone=>Verified
    Mon Oct 21 16:44:22 2013elizAttached File-=>Added w32_unixy_shell.dif, #29434
    Fri Oct 18 14:48:37 2013elizAttached File-=>Added w32_unix_exec_path.dif, #29405
    Fri Oct 11 11:54:37 2013glandiumAttached File-=>Added diff, #29354

    Back to the top

    Powered by Savane 3.1-cleanup