On Sun, 2021-09-05 at 20:15 +0300, Eli Zaretskii wrote: > But the way we build the batch file assumes cmd.exe, because we have > no idea how to write scripts for other programs that can be used as > "shells". Also, we have no idea about the quoting used by other > shells, so the tests that decide to "goto slow" due to fancy quoting > are also prone to fail.
I'm not sure I understand. Clearly if SHELL is not changed then we need to do whatever is necessary to get the default shell (sh or cmd) to work. I understand that this involves more complexity with cmd than sh. But if the user changes SHELL to something that's not known to make then it's up to the user to make that work. In that situation we should simply pass along the expanded recipe lines as they are written in the makefile, using the value of SHELL as the command and the value of .SHELLFLAGS as the flags. It's up to the user to make sure it works with their customized setup, it's not something GNU make can do anything about. So it shouldn't try. Perhaps there's a good argument to be made, in 2021 with PowerShell ubiquitous on Windows system and also available on non-Windows systems, that we should teach GNU make how to use PowerShell as an optional "builtin shell" so that if the user sets SHELL to PowerShell we can handle that properly. But that's just another special case; we need to solve the general case as well. It's also possible that generalizing the batch file model of command invocation would be good; there are situations even in GNU/Linux, which has far higher limits than Windows, where providing an entire command as a single argument causes exec to fail by exceeding limits. We have SHELL and .SHELLFLAGS. Maybe adding a new variable like .SHELLARG that controlled the format of the argument somehow (either the command string, which would be the default, or some way to write it to a temporary file and pass that file to the SHELL) would be useful.
