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 16:47:03 -0400
> 
> On Sun, 2021-09-05 at 22:29 +0300, Eli Zaretskii wrote:
> > > We don't provide -c at all: we provide the options in the
> > > .SHELLFLAGS variable.
> > 
> > But there's a default if it is not provided, right?
> 
> Sure, but if the default is wrong (just like with SHELL) the user has
> to change it.

And what is the right flag for PowerShell?  Looks like -Command?

In general, on Posix platforms users only need to care about
.SHELLFLAGS when they use a "shell" that isn't really a shell, because
all shells support the default -c.  Here we are talking about a shell
which _requires_ using .SHELLFLAGS.  I wonder how many users will know
that.

> Consider someone using SHELL := perl ; that won't work with -c either
> even on POSIX.  That's why we created .SHELLFLAGS in the first place.

That's in the "you asked for it" department.  If we are to support
PowerShell better than we support Perl and its ilk, we should do
better, IMO, similarly to what we do with cmd.exe.

> >     /* SHELL may be a multi-word command.  Construct a command line
> >        "$(SHELL) $(.SHELLFLAGS) LINE", with all special chars in LINE 
> > escaped.
> >        Then recurse, expanding this command line to get the final
> >        argument list.  */
> 
> I've always felt that this code was FAR too complicated and never
> understood why it needed to be that way.  I suppose there was a desire
> to allow the SHELL variable to contain multiple words, quoting, etc.
> and have that DTRT but I think it's ultimately futile to try to support
> this.
> 
> I'll need to look at the details about how it works today but I think
> that regardless of that it SHOULD work essentially as I laid out:

It's not just that: once we are through with escaping special
characters, we call construct_command_argv_internal recursively, which
again attempts to avoid calling the shell to execute $SHELL, so it
again goes through all the rigmarole of parsing the command with its
quotes and escapes.

> > Before it works, we need to make sure argv[] won't fail the 'exec'
> > call due to these minor details.
> 
> Yes, it's frustrating the way Win32 requires explicit quoting of
> arguments.  However, as far as I'm aware this quoting is generic and
> doesn't depend on the actual command being invoked.

It is generic, but it's "tricky", because there's no 'exec' on
Windows, really.  The low-level API that starts processes wants the
command line as a single string, so we need to quote parts of it that
include whitespace and other special characters.  You can see the
quirks in subproc.c.  I have no idea whether PowerShell will require
any changes there, it's all pure heuristics based on many years of
trial and error.  Submitting batch files for execution by cmd.exe
needs special tricks there, for example.

> > > This is why I raised the generalization of batch files as an issue:
> > > some commands may not be able to accept "<command>" on the command
> > > line like that, and if we could provide a _generic_ way to allow
> > > makefiles to change that final argv value to something else like a
> > > reference to a batch file where <command> was written, it could
> > > help.
> > 
> > Sure, but each shell has its own rules how to write batch files.  We
> > can support known shells, but what to do with unknown ones?
> 
> I'm saying that to gain portability *GNU make* should write the batch
> file.

Yes, that's what I meant as well.

> The batch file would contain exactly whatever text is in the recipe.
> The question is how to provide that filename to the command we invoke.

How to provide the file name is an issue (and PowerShell is different
here as well, AFAIU: it requires use of the -File switch), but it is
not the only issue.  The batch file may need some preamble specific to
a shell.  For example, for cmd.exe we add "@echo off" there.  I have
no idea whether PowerShell needs something special, nor whether the
nominal .ps1 extension has to be used for the batch file-name
extension.  These are all issues that need to be figured out before we
can declare that we support batch files for any shell.