Re: How to choose the shell?

[Paul Smith]

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.

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.

> > We don't escape anything at all: we provide the expansion of the
> > command as the first argument.
> 
> I was alluding to the code described by this comment in job.c:
> 
>     /* 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:

> > In other words, GNU make should basically run the equivalent of
> > this
> > "pidgin code":
> >    argv = [$(SHELL)]
> >    argv += $(split $(.SHELLFLAGS))
> >    argv += ["<command>"]
> >    exec(argv);
> 
> > It's up to the user to make sure the above construct actually
> > works, if they're not using a default SHELL.
> 
> 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.  I guess there
could be some programs that don't use normal command line parsing
operations at all.  I don't know what to do about that.  My personal
opinion is we should ignore it and let the user worry about it.

Maybe I'm still confused and the Win32 API is even more esoteric and/or
difficult WRT process invocation than I thought.

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

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.