Date: Mon, 18 Aug 1997 16:00:36 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: "Peter J. Farley III" <pjfarley AT dorsai DOT org>
cc: djgpp AT delorie DOT com
Subject: Re: Is this error due to make, bash, or me?
In-Reply-To: <33f23fd7.1836189@news.dorsai.org>
Message-ID: <Pine.SUN.3.91.970818160012.17172E-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Precedence: bulk


On Wed, 13 Aug 1997, Peter J. Farley III wrote:

> all:
> 	-(cd 1; make CCC=$(CCC))
> 
> and it was not working at all.  (As it turns out, it was the "cd" that
> was failing, probably because $COMSPEC was being used instead of
> $SHELL.)

You didn't tell enough for me to understand this example, but anyway,
it's not `cd' that was probably failing.  The ported Make emulates
`cd' internally (unless $SHELL is set to a unixy shell), and so
supports forward slashes etc.

The problem is probably in the parenthesized command: the internal
shell emulator used by the `system' library function 9which Make calls
when $SHELL or $COMSPEC points to a DOS shell) doesn't know about the
parentheses, so it tries to inoke a command named "(cd", which fails.
 
> MAKESHELL, according to the README.dos file, takes precedence over
> both $SHELL and $COMSPEC.  So I can put the MAKESHELL setting into
> DJGPP.ENV and solve my make problem without changing the value of
> $SHELL at all.  My subshell syntax makefile also now works as
> intended.

Yep, that's what $MAKESHELL is for.

> But even makefiles that do *not* set the SHELL variable can be
> affected, as I have seen with my subshell-syntax example.

That's correct: Makefiles which use the parens like above, or commands
like "cd src && make CCC=$(CCC)" need $SHELL to point to a unixy
shell.  It is good practice to include "SHELL = /bin/sh" in such
Makefiles; apparently the examples from the ORA book haven't done so
(and so might also fail on Unix if the user uses csh).