Re: How to choose the shell?

[Eli Zaretskii]

> From: Paul Smith <psmith@gnu.org>
> Cc: jfreeman08@gmail.com, make-w32@gnu.org
> Date: Sun, 05 Sep 2021 14:38:52 -0400
> 
> 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.

I understand the principles.  The devil is in the details.

First, how do you invoke the shell?  On Unix we do "$SHELL -c", right?
What to do on Windows?  Most Windows shells don't support "-c".

Next, what are the characters special to the shell, and how to escape
them?  We currently use Unix conventions for that, with some Windows
fixups, but that won't necessarily work with an arbitrary Windows
shell.  What to use instead?

> 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.

Agreed.

> 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.

Not sure how this is related to the main issue at hand.