[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: interactive shell is incorrect
From: |
David Thompson |
Subject: |
RE: interactive shell is incorrect |
Date: |
Thu, 5 Jun 2003 10:27:23 -0700 |
> From: Paul D. Smith [mailto:address@hidden
> %% 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.
In this case, Makefile.a invokes make recursively using Makefile.b,
inside Makefile.a I have SHELL=/usr/local/bin/bash on the resursive
make command line, so it is not /bin/sh, it is bash here, I don't
understand why bash reads the ENV in my case.
> 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?
On my system, /bin/sh is a symbolic link to bash.
$ /bin/sh --version
GNU bash, version 2.05.8(1)-release (i386-redhat-linux-gnu)
Copyright 2000 Free Software Foundation, Inc.
$ witch -l bash
-rwxr-xr-x 1 root root 1690546 Dec 7 2001 /usr/local/bin/bash
-rwxr-xr-x 1 root root 519964 Jul 9 2001 /bin/bash
$ which bash
bash is a tracked alias for /usr/local/bin/bash
$ /usr/local/bin/bash --version
GNU bash, version 2.05.0(1)-release (i686-pc-linux-gnu)
Copyright 2000 Free Software Foundation, Inc.
$ /bin/bash --version
GNU bash, version 2.05.8(1)-release (i386-redhat-linux-gnu)
Copyright 2000 Free Software Foundation, Inc.
$ ls -l /bin/sh
lrwxrwxrwx 1 root root 4 Aug 29 2002 /bin/sh -> bash
> 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
Interesting, what is your login shell?
> 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.
Yes, my system, too.
> dt> But I contend that a bug exists (somewhere) because
> dt> bash thinks it is invoked as an interactive shell,
> dt> even with BASH_ENV and ENV unset, so bash sources
> dt> ~/.bashrc. Clearly bash is not supposed to be doing
> dt> that.
> There's definitely a problem somewhere but I suspect it's with your
> environment rather than make.
It seems that if ~/.bashrc exists and produces output, it is the
problem. I'm not convinced it should be a problem. I will have to
investigate more to discover why.
> 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.
Good to know, thanks.
> 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.
Start talking! ;)
$ make -s -f Makefile.a SHELL=/usr/local/bin/bash
Hello bashrc
TOPDIR = /home/davidt/tmp/foo
Isn't that wrong?
I'm not a bash user, and this makefile I'm invoking recursively
is not under my control. I only discovered this because I had
an echo in my ~/.bashrc file. Forgive me, Paul, but this still
looks like a problem. Perhaps the problem is bash?
I will look harder at why my results are not identical to yours.
Can you help suggest experiments?
--
David Thompson
Foster City, CA