[Top][All Lists]

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

Re: exporting SHELL in dos/windows

From: Eli Zaretskii
Subject: Re: exporting SHELL in dos/windows
Date: Fri, 11 Mar 2005 18:06:37 +0200

> Date: Fri, 11 Mar 2005 09:01:13 -0500
> From: address@hidden
> For POSIX compatibility the next version of GNU make doesn't export any
> value of SHELL that you set in your makefile.  Instead, the value that
> was taken from the environment when make starts is passed on in the
> environment of the sub-shell.  Note this DOES NOT impact the way in
> which make chooses which shell to invoke commands in: that still uses
> the value set in the makefile or inherited from the environment.
> This only impacts the value of the SHELL environment variable which is
> passed in the environment to sub-commands.
> If you want the make variable value to be exported you can export it
> explicitly with "export SHELL" then the make value will be passed
> through the environment.
> Eli doesn't think this new behavior is appropriate for the DOS port; he
> would like the old behavior back.

Let me explain why this is bad for the DOS (a.k.a. DJGPP) port of

The reason is that Make in its DOS port does not automatically call
the shell when it sees a command that requires shell features (such as
redirection or quoting).  It doesn't call the shell because DOS shells
are too dumb.  Instead, it calls the library function `system' to run
the command.  The DJGPP version of `system' emulates the DOS shell and
adds a few useful features to that emulation, like support for forward
slashes in redirection, smart quoting, a `cd' command that changes
drive as well as directory, support for /dev/null, etc.  (It will
still call the shell for batch files and built-in commands.)

For this emulation to DTRT, `system' needs to look at the value of
SHELL in the environment.  If the value it sees points to a Unixy
shell, such as the ported Bash, `system' simply invokes that shell and
lets it handle the command, since a Unixy shell is much smarter than
`system's own shell emulation.  If SHELL points to something that is
not a Unixy shell, the internal shell emulation is invoked instead.

So it's imperative that the value of SHELL set by the Makefile is
pushed into the environment, otherwise `system' will not work
correctly when the Makefile says SHELL = /bin/sh.  But if SHELL is
pushed into the environment, it will wind up being exported to the
child programs.

So that is the reason why the DOS port does need to export SHELL.  The
original code, as released by Paul in the last pretest, failed to run
Makefiles that say SHELL = /bin/sh and rely on a Unixy shell to
perform some of their commands.  That includes the entire test suite.

reply via email to

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