%% David Thompson <[EMAIL PROTECTED]> writes: dt> BASH_ENV is no, but ENV is yes.
dt> $ echo $BASE_ENV dt> $ echo $ENV dt> /home/davidt/.kshrc dt> My login shell is ksh93, so naturally I'm using ENV dt> with ksh, not bash. Doesn't matter. ENV handling is a requirement of the POSIX Bourne shell, not only ksh, and when bash is invoked as "sh" it behaves like a POSIX Bourne shell, which means it reads ENV. dt> I still think there is a bug. From my original email, note dt> how this command, dt> 50 $ make -s -f Makefile.b dt> 51 TOPDIR = /home/davidt/tmp/foo dt> is correct, but this recursive make shows incorrect output, dt> 47 $ make -s -f Makefile.a dt> 48 Hello bashrc dt> 49 TOPDIR = Hello bashrc /home/davidt/tmp/foo dt> I don't understand what explains *that* difference. Well, one difference is that when you invoke make on Makefile.b, SHELL is set to /bin/sh (the default). When you invoke it recursively from Makefile.a, you set it to /usr/local/bin/bash, which is not the same thing at all (even if /bin/sh is really bash, bash behaves differently when invoked as "sh"--see the bash man pages). What is /bin/sh on your system? dt> Can you reproduce that behavior? No. I added a line to my ~/.bashrc file: echo "in bashrc" Now I run make -f Makefile.a: $ make -s -f /tmp/Makefile.a TOPDIR = /home/psmith $ make -s -f /tmp/Makefile.b TOPDIR = /home/psmith $ ENV=$HOME/.bashrc make -s -f /tmp/Makefile.a TOPDIR = /home/psmith $ ENV=$HOME/.bashrc make -s -f /tmp/Makefile.b TOPDIR = /home/psmith All identical. But if I set BASH_ENV I see behavior similar to yours: $ BASH_ENV=$HOME/.bashrc make -s -f /tmp/Makefile.a in bashrc TOPDIR = in bashrc /home/psmith $ BASH_ENV=$HOME/.bashrc make -s -f /tmp/Makefile.b TOPDIR = /home/psmith Note that on my system, /bin/sh is really bash in disguise. dt> But I contend that a bug exists (somewhere) because bash thinks it dt> is invoked as an interactive shell, even with BASH_ENV and ENV dt> unset, so bash sources ~/.bashrc. Clearly bash is not supposed to dt> be doing that. There's definitely a problem somewhere but I suspect it's with your environment rather than make. Make very simply invokes "$(SHELL) -c '<command>'", there's nothing at all fancy about what it does. It does not force interactive shells or anything else. dt> I also contend the bug is with make since the behavior is only dt> seen in recursive invocations of make. I don't agree with this, necessarily, since you are changing the value of SHELL on the recursion. That could very likely cause the different behavior. If you use identical values of SHELL in both the top-level and recursive invocations of make and you still see different behavior, _then_ we might have something to talk about here. -- ------------------------------------------------------------------------------- Paul D. Smith <[EMAIL PROTECTED]> Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org "Please remain calm...I may be mad, but I am a professional." --Mad Scientist _______________________________________________ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make