createProcess function is can't exec a *.cmd or *.bat file

[taiju]

-- Sorry, I'm poor English.

createProcess function is can't exec a *.cmd or *.bat file.

I can exec foo command when foo.cmd is placed of system environment variable paths. However, createProcess function is can't exec foo. (foo.cmd too)

It catch an error that error message is does not exist (No such file or directory).

reproduction screenshot

about this problem

This is not usually a problem. However, It may be a problem. For example, some of the commands built by NodeJS (with NPM) are wrapped with .cmd file.

• SEE
  • https://docs.npmjs.com/misc/config#bin-links
  • https://github.com/npm/cmd-shim
  • https://github.com/npm/bin-links

Concretely, I'm facing this problem at here.

[snoyberg]

I don't understand why the first example from the command line itself worked. If foo.cmd is in the bin subdirectory, how does the shell find it? Is there a PATH env var set? Is that env var being passed in to ghci?

Similarly, does running proc "foo.cmd" instead work?

[taiju]

There is Path env var set. bin subdirectory is included it.

the env var passed in to ghci.

proc "foo.cmd" instead work.

Although it can be executed on the command line, it can not be executed on the createProcess in some cases (For example, commands that wrapped by npm).

※ 指定されたパスが見つかりません means "The specified path can not be found".

[snoyberg]

OK, so narrowing this down further, it seems like the problem is: given a plain executable name like foo, the process package will find foo.exe if it exists in directories of the PATH, but it will not find foo.bat and foo.cmd. Is that accurate?

[taiju]

Yes, it is accurate.
Additionally, createProcess can't resolve cwd path in foo.cmd well such as a screen shot above.

[snoyberg]

I've looked into the source code on Windows. Ultimately, we're passing the command line to the CreateProcess function, which seems to document this behavior:

If the file name does not contain an extension, .exe is appended. Therefore, if the file name extension is .com, this parameter must include the .com extension. If the file name ends in a period (.) with no extension, or if the file name contains a path, .exe is not appended.

(From MSDN on CreateProcessA.)

I don't see which screen shot demonstrates the claim about the CWD path. I will note that on POSIX systems, that's the expected behavior. However, from the same MSDN docs, it should work as you expect on Windows:

If the file name does not contain a directory path, the system searches for the executable file in the following sequence:

1. The directory from which the application loaded.
2. The current directory for the parent process.

[taiju]

I don't see which screen shot demonstrates the claim about the CWD path.

I'm sorry for bad explanation. Please see below.

I expected %~dp0 output result point to the path of foo.cmd. However, %~dp0 point to the ghci CWD path. (I couldn't found official informations of %~dp0.)

[snoyberg]

I'm going to guess in all of these cases, if you instead use shell (not proc), you get the behavior you're looking for. If that's the case, I would say that the library is acting as expected.

[taiju]

Thank you! shell is acting as expected!
I understood that the problem that I'm facing is not a System.Process library problem, but a System.Process library user side problem.

[snoyberg]

You're welcome, no problem