> From: Paul D. Smith [mailto:[EMAIL PROTECTED]
Thanks for your quick response!
> dt> Could someone explain this behavior?
> Maybe. Do you have either the $ENV or $BASH_ENV variables
> set? If so that probably explains the behavior. See the
> bash man page for more information.
BASH_ENV is no, but ENV is yes.
$ echo $BASE_ENV
$ echo $ENV
/home/davidt/.kshrc
My login shell is ksh93, so naturally I'm using ENV
with ksh, not bash.
I still think there is a bug. From my original email, note
how this command,
50 $ make -s -f Makefile.b
51 TOPDIR = /home/davidt/tmp/foo
is correct, but this recursive make shows incorrect output,
47 $ make -s -f Makefile.a
48 Hello bashrc
49 TOPDIR = Hello bashrc /home/davidt/tmp/foo
I don't understand what explains *that* difference.
Can you reproduce that behavior? Here are the Makefiles
from the original email,
12 $ cat Makefile.a
13 all:
14 gmake -f Makefile.b SHELL=/usr/local/bin/bash
Line 14 should say 'make' not 'gmake', but that's not the
problem.
15 $ cat Makefile.b
16 TOPDIR := $(shell /bin/pwd)
17 all:
18 echo TOPDIR = $(TOPDIR)
Btw, even when I unset ENV, I still get incorrect behavior
from the recursive make invocation. The obvious workaround
is to gag the ~/.bashrc into silence, since its output is
what seems to pollute everything. But I contend that a bug
exists (somewhere) because bash thinks it is invoked as an
interactive shell, even with BASH_ENV and ENV unset, so bash
sources ~/.bashrc. Clearly bash is not supposed to be doing
that. I also contend the bug is with make since the behavior
is only seen in recursive invocations of make.
Can you agree?
Regards,
--
David Thompson
Foster City, CA
_______________________________________________
Bug-make mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-make
