[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: interactive shell is incorrect
From: |
Paul D. Smith |
Subject: |
RE: interactive shell is incorrect |
Date: |
Thu, 5 Jun 2003 12:30:33 -0400 |
%% David Thompson <address@hidden> 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 <address@hidden> 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