[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: How to choose the shell?

From: John Freeman
Subject: Re: How to choose the shell?
Date: Sat, 4 Sep 2021 11:33:01 -0500

On Sat, Sep 4, 2021 at 10:46 AM Eli Zaretskii <> wrote:
GNU Make avoids calling the shell for commands that don't require any
shell functionality it knows about.  This is how GNU Make works on all
platforms, and the Windows port doesn't change that.  So if you don't
have ls.exe or ls.bat or ls.cmd somewhere on Path, the above is
expected, regardless of the value of SHELL in the Makefile.  (You can
see from the error message that it tried to invoke 'ls'; the shell is
nowhere in the call it shows that failed.)

To trigger the use of a shell, you need to use some feature on the
command line that needs a shell.  For example, redirection or some
fancy quoting.

I have since discovered [this thread](, the very previous thread on this mailing list, working through the exact same problem. I'm happy that there is a workaround, but this seems to me like undocumented behavior. It is not mentioned anywhere in the [pages]( on Recipe Execution. One might argue that the parenthetical statement "(In practice, make may take shortcuts that do not affect the results.)" implies this behavior, but I think we can see that this behavior _does_ affect the results. At the very least, I think this behavior should be explicitly documented. Perhaps a footnote?

My preference would be to have some other workaround that doesn't require me to modify every recipe line, e.g. a special variable `.FORCE_SHELL`.
> - I can see that `ComSpec` is set in my default environment. In PowerShell, I can read it as `$env:ComSpec
> ` or `$env:COMSPEC`, but in a Makefile, it is only available as `${ComSpec}`. If I remove and re-add the
> variable under the name `$env:COMSPEC`, it becomes available in the Makefile as `${COMSPEC}`, but I
> still get the same error from the `ls` recipe.

I'm not sure I understand why you think this is a problem.
Environment variables are case-insensitive on MS-Windows, so why does
it matter whether you have ComSpec or COMSPEC?

I was under the (correct) impression that environment variables are case-insensitive on Windows, but I went through this extra trouble just to prove that case-sensitivity was not a factor in this behavior that deviates from the [documented behavior]( The documentation says it will use the shell passed as `COMSPEC`, but it didn't. We now both realize that it might have if it actually "invok[ed] a new sub-shell for each line of the recipe" like it [said it would](

reply via email to

[Prev in Thread] Current Thread [Next in Thread]