Code change:
pub fn get_linker(sess: &Session) -> (String, Command, Vec<(OsString, OsString)>) { let envs = vec![("PATH".into(), command_path(sess))]; <ins> // If our linker looks like a batch script on Windows then to execute this // we'll need to spawn `cmd` explicitly. This is primarily done to handle // emscripten where the linker is `emcc.bat` and needs to be spawned as // `cmd /c emcc.bat ...`. // // This worked historically but is needed manually since #42436 (regression // was tagged as #42791) and some more info can be found on #44443 for // emscripten itself. let cmd = |linker: &str| { if cfg!(windows) && linker.ends_with(".bat") { let mut cmd = Command::new("cmd"); cmd.arg("/c").arg(linker); cmd } else { Command::new(linker) } }; </ins> if let Some(ref linker) = sess.opts.cg.linker { <del> (linker.clone(), Command::new(linker), envs) </del> <ins> (linker.clone(), cmd(linker), envs) </ins> } else if sess.target.target.options.is_like_msvc { let (cmd, envs) = msvc_link_exe_cmd(sess); ("link.exe".to_string(), cmd, envs) } else { let linker = &sess.target.target.options.linker; <del> (linker.clone(), Command::new(&linker), envs) </del> <ins> (linker.clone(), cmd(linker), envs) </ins> } }

Related discussion:
text: It would be a shame though, because I suppose a lot of people use in their build script and would be happy if it worked seamlessly on all the platforms. Personally, I don't have a Windows machine to test my code on, I just assume std code is cross-platform if I don't use OS specific modules. Maybe it is a wrong assumption to make, but so far it has worked out pretty well and that is just amazing! I guess I'm just asking to not dismiss this issue too quickly because it is not "our fault" and see if we can end up with something better. Even if it wasn't working flawlessly in a cross-platform way before, I would consider diverging further as a serious regression that should at least be well thought out.
The fact that you even can run bat files with honestly feels like a backwards compatibility hack that Microsoft wishes they could undo. A bat file is not a binary, and when you do run it the process which is actually running is . Unfortunately the fact that is able to run bat files at all leads people into the false belief that it is any good at that. In fact, imposing the requirement that be able to run bat files precludes us from adding the ability to run binaries from paths longer than ! In order to support long paths, we'd have to specify the application name in the parameter, which does not support executing bat files directly! So please, just use instead of executing bat files directly so that Rust will have the ability to make better in the future.
I would like to excuse for the terse form (I'm on mobile only) so please take this with grain of salt. It might be but I have not encountered a modern language stdlib that would not allow running bat files within the PATH. But if this is the policy then either forbid it explicitly in API or at least document such limitation in the docs. neither are any other executable scripts on NIXes. IMHO this is besides the point Please note that we are discussing two completely different entities. You are mentioning the internal Windows implementation and its limitations which I perfectly understand. While I'm talking about the user facing rust API that IMHO should hide as many platform specific warts as possible and document its limitations if former is not possible.