std::process::Command doesn't execute .COM files on Windows

[cengiz-io]

Hello!

(This is probably just another case of #37380)

I'm working on #32665 and my implementation uses default pager executables depending on the platform. (less for *nix, more for Windows)

I spawn pager process like this

let pager = env::var("PAGER").unwrap_or(String::from("more"));

Command::new(pager).arg(file_path).output()

And that fails to run on Windows 10 due to this line: src/libstd/sys/windows/process.rs#L145

Since more is actually more.com, it needs to be executed with a different suffix than hardcoded .exe

There was a note about CreateProcess from @afiune but I don't know how that relates.

Thanks a lot!

cc @Mark-Simulacrum, @alexcrichton

[retep998]

That code is only used when a custom PATH is specified due to attempts to emulate posix behavior (and really could be improved quite a bit). Otherwise it just follows the default CreateProcess behavior. To quote MSDN:

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.

Perhaps what you really want is ShellExecute instead of CreateProcess?

Related issue #37380

[alexcrichton]

If CreateProcess is intended to work with *.com files then definitely sounds like a bug to me! (I'm not sure what the "expected" behaior here about CreateProcess is)

[retep998]

CreateProcess will execute *.com files only when you explicitly set the extension to .com. This is the behavior that Rust's Command has on Windows, except when you specify a custom PATH in which case the "posix compatibility" code does the search with somewhat different semantics regarding extension handling. I'll have to do some syscall tracing to know how exactly CreateProcess does the search so I can fix the custom PATH searching one day.

Given the current stance of Command on Windows is to get as close to CreateProcess as possible (aside from custom PATH handling), attempts to spawn pager failing to execute pager.com seems like not a bug to me.

[ollie27]

This is basically a dupe of item 2 of #37519. Command::new("more.com") should work fine now as long as there is no more.exe in the %Path%.

[alexcrichton]

Ah ok, thanks @ollie27! I'll close in favor of that isue then.

[afiune]

Even though I agree that we are replicating the behavior of CreateProcess, I wish we could have a way to execute batch files in Windows. (.bat, .com, etc) ❤️

We might have two options:

Extend Command to execute batch files

The documentation says you can: (here)

To run a batch file, you must start the command interpreter; set lpApplicationName to cmd.exe and set lpCommandLine to the following arguments: /c plus the name of the batch file.

We could add extra sugar to Command so that it becomes a first citizen for executing anything in Windows world.

Create another module - ex. BatchCmd()

Create some other module that gives you the ability to execute batch files in Windows. This idea is a bit odd since you are creating an specific module for a platform and doesn't makes sense to me but it's an option.

[retep998]

@afiune What you really want is a wrapper around ShellExecuteEx. That would handle all the magic of executing whatever sort of scripts or batch files you want (or most other kinds of files too).