The program used as the shell is taken from the variable
If this variable is not set in your makefile, the program
/bin/sh is used as the shell.
Unlike most variables, the variable
SHELL is never set from the
environment. This is because the
SHELL environment variable is
used to specify your personal choice of shell program for interactive
use. It would be very bad for personal choices like this to affect the
functioning of makefiles. See Variables from the Environment.
Furthermore, when you do set
SHELL in your makefile that value
is not exported in the environment to commands that
invokes. Instead, the value inherited from the user's environment, if
any, is exported. You can override this behavior by explicitly
SHELL (see Communicating Variables to a Sub-
make), forcing it to be passed in the
environment to commands.
However, on MS-DOS and MS-Windows the value of
SHELL in the
environment is used, since on those systems most users do not
set this variable, and therefore it is most likely set specifically to
be used by
make. On MS-DOS, if the setting of
not suitable for
make, you can set the variable
MAKESHELL to the shell that
make should use; if set it
will be used as the shell instead of the value of
Choosing a shell in MS-DOS and MS-Windows is much more complex than on other systems.
On MS-DOS, if
SHELL is not set, the value of the variable
COMSPEC (which is always set) is used instead.
The processing of lines that set the variable
SHELL in Makefiles
is different on MS-DOS. The stock shell, command.com, is
ridiculously limited in its functionality and many users of
tend to install a replacement shell. Therefore, on MS-DOS,
examines the value of
SHELL, and changes its behavior based on
whether it points to a Unix-style or DOS-style shell. This allows
reasonable functionality even if
SHELL points to
SHELL points to a Unix-style shell,
make on MS-DOS
additionally checks whether that shell can indeed be found; if not, it
ignores the line that sets
SHELL. In MS-DOS, GNU
searches for the shell in the following places:
SHELL. For example, if the makefile specifies ‘SHELL = /bin/sh’,
makewill look in the directory /bin on the current drive.
PATHvariable, in order.
In every directory it examines,
make will first look for the
specific file (sh in the example above). If this is not found,
it will also look in that directory for that file with one of the known
extensions which identify executable files. For example .exe,
.com, .bat, .btm, .sh, and some others.
If any of these attempts is successful, the value of
be set to the full pathname of the shell as found. However, if none of
these is found, the value of
SHELL will not be changed, and thus
the line that sets it will be effectively ignored. This is so
make will only support features specific to a Unix-style shell if
such a shell is actually installed on the system where
Note that this extended search for the shell is limited to the cases
SHELL is set from the Makefile; if it is set in the
environment or command line, you are expected to set it to the full
pathname of the shell, exactly as things are on Unix.
The effect of the above DOS-specific processing is that a Makefile that
contains ‘SHELL = /bin/sh’ (as many Unix makefiles do), will work
on MS-DOS unaltered if you have e.g. sh.exe installed in some
directory along your