Perl *** couldn't commit memory for cygwin heap, Win32 error

I'm leaning toward won't fix but I'll give Chuck a chance to weigh in on the issue. It is expected that PATH is set such that it doesn't contain such a trap and the users environment is under the users control which isn't an issue for MinGW developers. We deliver MSYS such that the paths are set by the MSYS environment and if a user modifies his environment then it is the users responsibility to ensure that the added paths do not interfere with the working environment. We have no control over the PATH beyond what is delivered by default.

This is a new behaviour - I had a previous version of MinGW perl.exe from about a year ago which did not have this problem.

I am going to assume you mean that the "new behavior" is the "couldn't commit memory for cygwin heap, Win32 error 0" message. Certainly not the fact that an executable script coming first in the PATH will be executed, that is not "new behavior". If what I say is true then you need to correct your bug report Summary.

Yes - Using the older version of perl.exe, the "sh" file was ignored and the perl program executed normally using "sh.exe".
Using the latest perl.exe, the "sh" file is not ignored and causes the error message.

<blockquote>Yes - Using the older version of perl.exe, the "sh" file was ignored and
the perl program executed normally using "sh.exe".</blockquote>

Maybe it did, but the issue is still a user issue. The user could just as easily have another sh.exe in the PATH before /bin. We cannot guard against stupidity on the users part.

I'm leaving this open because of the "cygwin heap" issue. I've modified the Summary to match the open issue.

I'm sorely tempted to just close this, as "invalid". The "cannot commit memory for cygwin heap" is often a symptom of misuse: attempting to start MSYS utilities directly from cmd.exe, which is unsupported, instead of from a properly initiated MSYS shell session, as they should be used; the OP's use of backslashes in example path names strongly hints that he (or she) is engaged in precisely such improper usage.

Other than that, I completely agree with you, Earnie, that there absolutely should not be an executable sh anywhere where perl.exe can find it — executables on Windows need a .exe extension, (unless they are shell scripts, intended to be invoked from a properly initiated MSYS, or equivalent, shell session); the MSYS execlp(), (or spawnlp(), or whatever else MSYS' perl.exe may call to invoke a sub-shell process), shouldn't even consider any file for execution, if it does not have a valid executable extension.

Feel free to pass this on to Cesar, for further comment, but I see no reason why this should be deemed as anything other than inappropriate usage by the OP; I vote for immediate dismissal.

Closing because of age. If you think this needs further work open a new ticket on OSDN.